From nobody Mon Aug 1 01:15: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 CCBBD12D0B1 for ; Mon, 1 Aug 2016 01:15:25 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 Ssy54C28tEHF for ; Mon, 1 Aug 2016 01:15:24 -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 4E71812B014 for ; Mon, 1 Aug 2016 01:15:24 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 770141E5D80; Mon, 1 Aug 2016 01:12:33 -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 B5a-OaLN4XUo; Mon, 1 Aug 2016 01:12:33 -0700 (PDT) Received: from [192.168.1.127] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id 6EAF61E5D7B; Mon, 1 Aug 2016 01:12:32 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_26A29D24-D893-4822-885F-886CC2F31CA8" From: William Lupton In-Reply-To: Date: Mon, 1 Aug 2016 09:15:23 +0100 Message-Id: <57FC9BC0-DAC4-4671-AB6D-D45B6D1E7710@broadband-forum.org> References: <87shupjlog.fsf@hobgoblin.ariadne.com> To: "netmod@ietf.org" X-Mailer: Apple Mail (2.3124) Archived-At: Subject: Re: [netmod] YANG 1.1: XML naming restriction X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2016 08:15:26 -0000 --Apple-Mail=_26A29D24-D893-4822-885F-886CC2F31CA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii But the errata at https://www.w3.org/XML/xml-V10-5e-errata = say the following. There are = also related changes to Section 2.6 (processing instructions) and = Section 3 (logical structures). W. Section 2.3 Common Syntactic Constructs = Delete the following paragraph: Names beginning with the string "xml", or with any string which would = match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization = in this or future versions of this specification. > On 1 Aug 2016, at 04:22, Andy Bierman wrote: >=20 >=20 > OK -- sorry -- must have read it wrong >=20 >=20 > Andy >=20 >=20 >=20 > On Sun, Jul 31, 2016 at 6:57 PM, Dale R. Worley > wrote: > Andy Bierman > writes: > > The YANG 1.1 ABNF says: > > > > ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') = ('L'|'l')) > > identifier =3D (ALPHA / "_") > > *(ALPHA / DIGIT / "_" / "-" / ".") > > > > > > There is no explanation given why. > > The same restriction was copied to RESTCONF, also without = explanation. > > Supposedly, XML does not allow identifiers to start with XML. > > > > Looks like this restriction only applies to the PITarget [17], not = Name [5] > > https://www.w3.org/TR/REC-xml/#sec-pi = > > > > We have been applying this restriction to element names > > but it only applies to processing instructions. > > > > IMO it should be removed. > > It confuses people when they get an error for naming a data node > > with a string that matches. >=20 > Eh? Looking at "Extensible Markup Lanuage (XML) 1.0 (Fifth Edition)", > section 3.1 (http://www.w3.org/TR/xml/#sec-starttags = ) says that the > element name of a start in end tag is a "Name". Looking at section = 2.3 > (http://www.w3.org/TR/xml/#sec-common-syn = ), I see >=20 > Names beginning with the string "xml", or with any string which > would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for > standardization in this or future versions of this specification. >=20 > And since Yang data node names can appear as XML element names, Yang = has > to forbid node names that start with "XML". >=20 > Dale >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail=_26A29D24-D893-4822-885F-886CC2F31CA8 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii But the errata at https://www.w3.org/XML/xml-V10-5e-errata say the = following. There are also related changes to Section 2.6 (processing = instructions) and Section 3 (logical structures). W.
Section 2.3 = Common Syntactic Constructs

Delete = the following paragraph:

Names beginning with the string "xml", or with any = string which would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved = for standardization in this or future versions of this = specification.

On 1 Aug 2016, at 04:22, Andy = Bierman <andy@yumaworks.com> wrote:


OK -- sorry -- must have = read it wrong


Andy



On Sun, = Jul 31, 2016 at 6:57 PM, Dale R. Worley <worley@ariadne.com> wrote:
Andy Bierman <andy@yumaworks.com> = writes:
> The YANG 1.1 ABNF says:
>
>    ;; An identifier MUST NOT start with (('X'|'x') = ('M'|'m') ('L'|'l'))
>    identifier          =3D = (ALPHA / "_")
>                  =         *(ALPHA / DIGIT / "_" / "-" / ".")
>
>
> There is no explanation given why.
> The same restriction was copied to RESTCONF, also without = explanation.
> Supposedly, XML does not allow identifiers to start with XML.
>
> Looks like this restriction only applies to the PITarget [17], not = Name [5]
> https://www.w3.org/TR/REC-xml/#sec-pi
>
> We have been applying this restriction to element names
> but it only applies to processing instructions.
>
> IMO it should be removed.
> It confuses people when they get an error for naming a data node
> with a string that matches.

Eh?  Looking at "Extensible Markup Lanuage (XML) 1.0 (Fifth = Edition)",
section 3.1 (http://www.w3.org/TR/xml/#sec-starttags) says that the
element name of a start in end tag is a "Name".  Looking at section = 2.3
(http://www.w3.org/TR/xml/#sec-common-syn), I see

    Names beginning with the string "xml", or with any string = which
    would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved = for
    standardization in this or future versions of this = specification.

And since Yang data node names can appear as XML element names, Yang = has
to forbid node names that start with "XML".

Dale

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

= --Apple-Mail=_26A29D24-D893-4822-885F-886CC2F31CA8-- From nobody Mon Aug 1 01:38: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 C821C12B014 for ; Mon, 1 Aug 2016 01:38:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.287 X-Spam-Level: X-Spam-Status: No, score=-8.287 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=-1.287] 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 848QBPxXraeZ for ; Mon, 1 Aug 2016 01:38:36 -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 A9E7D12B00C for ; Mon, 1 Aug 2016 01:38:35 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:79c5:7fa1:2e8:dedb] (unknown [IPv6:2001:718:1a02:1:79c5:7fa1:2e8:dedb]) by mail.nic.cz (Postfix) with ESMTPSA id 7A779607E0; Mon, 1 Aug 2016 10:38:33 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470040713; bh=wtpFpSlzhVQoDAIEtYSGGYwmKd5oSmBMoGzZKawTRN4=; h=From:Date:To; b=Msu+51irKoFw6oxY0esyzvRkFjUrAtY5LrAo1JaSI3r4CMCalg6ZV3+IHjtwsuX4l rxh6FDmoEwWYeJG8fv4pbsuWswDBEPfhdyty22bZVR216XSxcX7P2O/ZjenuzSFndm iU9UaSARmF6oFXDezubFbc3LUe/jrjqDIqQtrbgU= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: <57FC9BC0-DAC4-4671-AB6D-D45B6D1E7710@broadband-forum.org> Date: Mon, 1 Aug 2016 10:38:40 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: <04F63698-5EA2-4A75-81EF-62BB5DCC2DC6@nic.cz> References: <87shupjlog.fsf@hobgoblin.ariadne.com> <57FC9BC0-DAC4-4671-AB6D-D45B6D1E7710@broadband-forum.org> To: William Lupton 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] YANG 1.1: XML naming restriction X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2016 08:38:38 -0000 > On 01 Aug 2016, at 10:15, William Lupton = wrote: >=20 > But the errata at https://www.w3.org/XML/xml-V10-5e-errata say the = following. There are also related changes to Section 2.6 (processing = instructions) and Section 3 (logical structures). W. > Section 2.3 Common Syntactic Constructs > Delete the following paragraph: >=20 > Names beginning with the string "xml", or with any string which would = match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for standardization = in this or future versions of this specification. Good catch! What this erratum means for YANG is that only "xml" prefix = needs to be forbidden. If it is still possible, it would IMO make a good sense to remove that = comment from the ABNF in 6020bis, and make this change in sec. 7.1.4: OLD A prefix is an identifier (see Section 6.2). NEW A prefix is an identifier (see Section 6.2), and it MUST NOT be the = string "xml". Lada=20 >=20 >> On 1 Aug 2016, at 04:22, Andy Bierman wrote: >>=20 >>=20 >> OK -- sorry -- must have read it wrong >>=20 >>=20 >> Andy >>=20 >>=20 >>=20 >> On Sun, Jul 31, 2016 at 6:57 PM, Dale R. Worley = wrote: >> Andy Bierman writes: >> > The YANG 1.1 ABNF says: >> > >> > ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') = ('L'|'l')) >> > identifier =3D (ALPHA / "_") >> > *(ALPHA / DIGIT / "_" / "-" / ".") >> > >> > >> > There is no explanation given why. >> > The same restriction was copied to RESTCONF, also without = explanation. >> > Supposedly, XML does not allow identifiers to start with XML. >> > >> > Looks like this restriction only applies to the PITarget [17], not = Name [5] >> > https://www.w3.org/TR/REC-xml/#sec-pi >> > >> > We have been applying this restriction to element names >> > but it only applies to processing instructions. >> > >> > IMO it should be removed. >> > It confuses people when they get an error for naming a data node >> > with a string that matches. >>=20 >> Eh? Looking at "Extensible Markup Lanuage (XML) 1.0 (Fifth = Edition)", >> section 3.1 (http://www.w3.org/TR/xml/#sec-starttags) says that the >> element name of a start in end tag is a "Name". Looking at section = 2.3 >> (http://www.w3.org/TR/xml/#sec-common-syn), I see >>=20 >> Names beginning with the string "xml", or with any string which >> would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for >> standardization in this or future versions of this specification. >>=20 >> And since Yang data node names can appear as XML element names, Yang = has >> to forbid node names that start with "XML". >>=20 >> Dale >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 1 02:13: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 4561312D5BD for ; Mon, 1 Aug 2016 02:13:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, 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 hJMl3fg38qqW for ; Mon, 1 Aug 2016 02:13:43 -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 BB93812D53D for ; Mon, 1 Aug 2016 02:13:41 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id C40101E5D80; Mon, 1 Aug 2016 02:10:50 -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 TImbQcYjRALQ; Mon, 1 Aug 2016 02:10:50 -0700 (PDT) Received: from [192.168.1.127] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id BF03D1E5D7B; Mon, 1 Aug 2016 02:10:49 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_28A53F53-CCD2-4D43-B45C-78EB5E079F6A" From: William Lupton In-Reply-To: Date: Mon, 1 Aug 2016 10:13:38 +0100 Message-Id: References: To: "Bogaert, Bart (Nokia - BE)" X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] BBF extensions to ietf-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: Mon, 01 Aug 2016 09:13:45 -0000 --Apple-Mail=_28A53F53-CCD2-4D43-B45C-78EB5E079F6A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 Maybe configuration of the entity tree for pluggable items should be = handled via augmentations that are specific to pluggable items? There seems to be an analogy with interfaces here. The ietf-interfaces = module provides only a read-only view of the interface stack, and = interface type-specific modules are expected to provide a means of = configuring the stack for interfaces of that type (where necessary). William > On 29 Jul 2016, at 15:04, Bogaert, Bart (Nokia - BE) = wrote: >=20 > I would like to bring this to the ietf-entity group. Currently BBF is = proposing to add new RW leafs to the entity object. This is done in the = context of plugable entities and hence it means that when an operator = (via a NC client) configures a plugable item it is required to define = the entity type. For this reason additional RW attributes are needed. = Two of the new leafs are class and contained-in (same as the RO class = leaf).=20 > - class: we think that the class leaf needs to be mandatory = but adding this via an augment is not possible as we can=E2=80=99t add a = mandatory leaf via an augment. Making class implicit for the client = based on =E2=80=9Csome information=E2=80=9D exchanged between device = vendors and management applications is maybe not such a sound approach. > - contained-in: for plugable items contained-in requires to = be mandatory too as a plugable item can=E2=80=99t be =E2=80=9Cfloating=E2=80= =9D in the device. But we then hit a problem for the =E2=80=98top-level=E2= =80=99 entity which not contained in anything (and =E2=80=98fooling=E2=80=99= the model by having it pointing to itself is not allowed). = Contained-in can=E2=80=99t be derived by the NC server: what to do if 2 = entities of the same class are preprovisioned (together with ports and = interfaces related to subscribers)? We need to be sure that the = subscribers are on the intended ports. > =20 > This would mean that the ietf-entity model would require a revision to = add leafs for these plugable items. What is the best way to address = this? > =20 > Best regards - Vriendelijke groeten, > Bart Bogaert > Broadband-Access System Architect Data > Contact number +32 3 2408310 (+32 477 673952) > =20 > NOKIA > Copernicuslaan 50, 2018 Antwerp, Belgium > Fortis 220-0002334-42 > VAT BE 0404 621 642 Register of Legal Entities Antwerp >=20 > << > This message (including any attachments) contains confidential = information intended for a specific individual and purpose, and is = protected by law. If you are not the intended recipient, you should = delete this message. Any disclosure, copying, or distribution of this = message, or the taking of any action based on it, is strictly prohibited = without the prior consent of its author. > >> > =20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod = --Apple-Mail=_28A53F53-CCD2-4D43-B45C-78EB5E079F6A Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 Maybe configuration of the entity tree for pluggable items = should be handled via augmentations that are specific to pluggable = items?

There seems = to be an analogy with interfaces here. The ietf-interfaces module = provides only a read-only view of the interface stack, and interface = type-specific modules are expected to provide a means of configuring the = stack for interfaces of that type (where necessary).

William

On 29 Jul 2016, at 15:04, Bogaert, Bart (Nokia - BE) <bart.bogaert@nokia.com> wrote:

I would like to bring this = to the ietf-entity group.  Currently BBF is proposing to add new RW = leafs to the entity object.  This is done in the context of = plugable entities and hence it means that when an operator (via a NC = client) configures a plugable item it is required to define the entity = type.  For this reason additional RW attributes are needed.  = Two of the new leafs are class and contained-in (same as the RO class = leaf). 
-          class: we = think that the class leaf needs to be mandatory but adding this via an = augment is not possible as we can=E2=80=99t add a mandatory leaf via an = augment.  Making class implicit for the client based on =E2=80=9Csome= information=E2=80=9D exchanged between device vendors and management = applications is maybe not such a sound approach.
-          contained-in: = for plugable items contained-in requires to be mandatory too as a = plugable item can=E2=80=99t be =E2=80=9Cfloating=E2=80=9D in the = device.  But we then hit a problem for the =E2=80=98top-level=E2=80=99= entity which not contained in anything (and =E2=80=98fooling=E2=80=99 = the model by having it pointing to itself is not allowed). =  Contained-in can=E2=80=99t be derived by the NC server: what to do = if 2 entities of the same class are preprovisioned (together with ports = and interfaces related to subscribers)?  We need to be sure that = the subscribers are on the intended ports.
 
This would mean that the ietf-entity = model would require a revision to add leafs for these plugable items. =  What is the best way to address this?
 
Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)
 
NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis = 220-0002334-42
VAT BE 0404 621 642 Register of Legal = Entities Antwerp

<<
This message (including any attachments) contains = confidential information intended for a specific individual and purpose, = and is protected by law. If you are not the intended recipient, you = should delete this message. Any disclosure, copying, or distribution of = this message, or the taking of any action based on it, is strictly = prohibited without the prior consent of its author.
>>
 
_______________________________________________
netmod mailing = list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

= --Apple-Mail=_28A53F53-CCD2-4D43-B45C-78EB5E079F6A-- From nobody Mon Aug 1 02:30: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 DC8EF12D5BF for ; Mon, 1 Aug 2016 02:30:56 -0700 (PDT) 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 autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AJ6PgKDjmHfG for ; Mon, 1 Aug 2016 02:30:54 -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 C1FAC12B049 for ; Mon, 1 Aug 2016 02:30:53 -0700 (PDT) Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id D7511A930FB80; Mon, 1 Aug 2016 09:30:49 +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 u719Uown018834 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 1 Aug 2016 09:30:51 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 u719Uf8S028624 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 1 Aug 2016 11:30:48 +0200 Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.95]) by FR712WXCHHUB03.zeu.alcatel-lucent.com ([135.239.2.74]) with mapi id 14.03.0195.001; Mon, 1 Aug 2016 11:30:37 +0200 From: "Bogaert, Bart (Nokia - BE)" To: William Lupton Thread-Topic: [netmod] BBF extensions to ietf-entity Thread-Index: AdHpoi/h3dfqTKzQR3WYPaIL6IHWCgCIgmIAAARf67A= Date: Mon, 1 Aug 2016 09:30:37 +0000 Message-ID: References: In-Reply-To: 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_001C_01D1EBE8.1F7A64F0" MIME-Version: 1.0 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] BBF extensions to ietf-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: Mon, 01 Aug 2016 09:30:57 -0000 ------=_NextPart_000_001C_01D1EBE8.1F7A64F0 Content-Type: multipart/alternative; boundary="----=_NextPart_001_001D_01D1EBE8.1F7A64F0" ------=_NextPart_001_001D_01D1EBE8.1F7A64F0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable William, =20 Not sure how this can be done in all cases. Assume we have a box that = allows =E2=80=98n=E2=80=99 boards to be plugged in slots 1..n. During = pre-provisioning we configure 2 boards of the same type, one in slot 1 = and another in slot 2. We also pre-provision the ports and allocate = subscriber interfaces and assign data specific to these subscribers (so = in a way this will be related to e.g. how the ports are wired via an = MDF). The device is not really able to determine by itself which board = is contained in slot 1 (supporting the subscribers that are wired via = MDF to terminate on this board) and the other to the board in slot 2. = The only way the device would be able to do so autonomously would be = when e.g. a serial number related to the boards is provided by the = operator when pre-provisioning the board. The serial number is = retrievable from the inventory information present in the board and = hence the device could relate a board to a specific slot. = However=E2=80=A6 when the board gets broken it is temporarily (or even = permanently in case the board is really broken) replaced by another = board of the same type but with a different serial number. This would = then mean that the operator also needs to modify that serial number = since the serial number in the inventory no longer matches the one = entered by the operator when configuring the board (it is not really = expected/allowed that the NC server would modify the RW data for that = board). =20 Not really sure this is an elegant way of exposing this serial number = management to a network operator. So don=E2=80=99t we need a mechanism = via configuration (i.e. R/W leafs) to configure this = =E2=80=9Ccontainment=E2=80=9D ? =20 Best regards - Vriendelijke groeten, Bart Bogaert Broadband-Access System Architect Data Contact number +32 3 2408310 (+32 477 673952) =20 NOKIA Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 0404 621 642 Register of Legal Entities Antwerp << This message (including any attachments) contains confidential = information intended for a specific individual and purpose, and is = protected by law. If you are not the intended recipient, you should = delete this message. Any disclosure, copying, or distribution of this = message, or the taking of any action based on it, is strictly prohibited = without the prior consent of its author. >>=20 =20 From: William Lupton [mailto:wlupton@broadband-forum.org]=20 Sent: 01 August 2016 11:14 To: Bogaert, Bart (Nokia - BE) Cc: netmod@ietf.org Subject: Re: [netmod] BBF extensions to ietf-entity =20 Maybe configuration of the entity tree for pluggable items should be = handled via augmentations that are specific to pluggable items? =20 There seems to be an analogy with interfaces here. The ietf-interfaces = module provides only a read-only view of the interface stack, and = interface type-specific modules are expected to provide a means of = configuring the stack for interfaces of that type (where necessary). =20 William =20 On 29 Jul 2016, at 15:04, Bogaert, Bart (Nokia - BE) = wrote: =20 I would like to bring this to the ietf-entity group. Currently BBF is = proposing to add new RW leafs to the entity object. This is done in the = context of plugable entities and hence it means that when an operator = (via a NC client) configures a plugable item it is required to define = the entity type. For this reason additional RW attributes are needed. = Two of the new leafs are class and contained-in (same as the RO class = leaf).=20 - class: we think that the class leaf needs to be mandatory but = adding this via an augment is not possible as we can=E2=80=99t add a = mandatory leaf via an augment. Making class implicit for the client = based on =E2=80=9Csome information=E2=80=9D exchanged between device = vendors and management applications is maybe not such a sound approach. - contained-in: for plugable items contained-in requires to be = mandatory too as a plugable item can=E2=80=99t be = =E2=80=9Cfloating=E2=80=9D in the device. But we then hit a problem for = the =E2=80=98top-level=E2=80=99 entity which not contained in anything = (and =E2=80=98fooling=E2=80=99 the model by having it pointing to itself = is not allowed). Contained-in can=E2=80=99t be derived by the NC = server: what to do if 2 entities of the same class are preprovisioned = (together with ports and interfaces related to subscribers)? We need to = be sure that the subscribers are on the intended ports. =20 This would mean that the ietf-entity model would require a revision to = add leafs for these plugable items. What is the best way to address = this? =20 Best regards - Vriendelijke groeten, Bart Bogaert Broadband-Access System Architect Data Contact number +32 3 2408310 (+32 477 673952) =20 NOKIA Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 0404 621 642 Register of Legal Entities Antwerp << This message (including any attachments) contains confidential = information intended for a specific individual and purpose, and is = protected by law. If you are not the intended recipient, you should = delete this message. Any disclosure, copying, or distribution of this = message, or the taking of any action based on it, is strictly prohibited = without the prior consent of its author. >> =20 _______________________________________________ netmod mailing list netmod@ietf.org = https://www.ietf.org/mailman/listinfo/netmod =20 ------=_NextPart_001_001D_01D1EBE8.1F7A64F0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

William,

 

Not sure how this can be done in all cases.=C2=A0 Assume we have a = box that allows =E2=80=98n=E2=80=99 boards to be plugged in slots = 1..n.=C2=A0 During pre-provisioning we configure 2 boards of the same = type, one in slot 1 and another in slot 2.=C2=A0 We also pre-provision = the ports and allocate subscriber interfaces and assign data specific to = these subscribers (so in a way this will be related to e.g. how the = ports are wired via an MDF). =C2=A0The device is not really able to = determine by itself which board is contained in slot 1 (supporting the = subscribers that are wired via MDF to terminate on this board) and the = other to the board in slot 2.=C2=A0 The only way the device would be = able to do so autonomously would be when e.g. a serial number related to = the boards is provided by the operator when pre-provisioning the = board.=C2=A0 The serial number is retrievable from the inventory = information present in the board and hence the device could relate a = board to a specific slot. =C2=A0However=E2=80=A6 when the board gets = broken it is temporarily (or even permanently in case the board is = really broken) replaced by another board of the same type but with a = different serial number.=C2=A0 This would then mean that the operator = also needs to modify that serial number since the serial number in the = inventory no longer matches the one entered by the operator when = configuring the board (it is not really expected/allowed that the NC = server would modify the RW data for that board).

 

Not really sure this is an elegant way of exposing this serial number = management to a network operator.=C2=A0 So don=E2=80=99t we need a = mechanism via configuration (i.e. R/W leafs) to configure this = =E2=80=9Ccontainment=E2=80=9D ?

 

Best regards - Vriendelijke groeten,

Bart Bogaert

Broadband-Access System Architect Data

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

 

NOKIA

Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis = 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities = Antwerp

&= lt;<
This message (including any attachments) contains = confidential information intended for a specific individual and purpose, = and is protected by law. If you are not the intended recipient, you = should delete this message. Any disclosure, copying, or distribution of = this message, or the taking of any action based on it, is strictly = prohibited without the prior consent of its = author.
>>

 

From:= = William Lupton [mailto:wlupton@broadband-forum.org]
Sent: 01 = August 2016 11:14
To: Bogaert, Bart (Nokia - BE)
Cc: = netmod@ietf.org
Subject: Re: [netmod] BBF extensions to = ietf-entity

 

Maybe = configuration of the entity tree for pluggable items should be handled = via augmentations that are specific to pluggable = items?

 

There seems to be an analogy with interfaces here. The = ietf-interfaces module provides only a read-only view of the interface = stack, and interface type-specific modules are expected to provide a = means of configuring the stack for interfaces of that type (where = necessary).

 

William

 

On 29 Jul 2016, at 15:04, Bogaert, Bart (Nokia - BE) = <bart.bogaert@nokia.com> = wrote:

 

I would = like to bring this to the ietf-entity group.  Currently BBF is = proposing to add new RW leafs to the entity object.  This is done = in the context of plugable entities and hence it means that when an = operator (via a NC client) configures a plugable item it is required to = define the entity type.  For this reason additional RW attributes = are needed.  Two of the new leafs are class and contained-in (same = as the RO class leaf). 

-        = ;  class: we = think that the class leaf needs to be mandatory but adding this via an = augment is not possible as we can=E2=80=99t add a mandatory leaf via an = augment.  Making class implicit for the client based on = =E2=80=9Csome information=E2=80=9D exchanged between device vendors and = management applications is maybe not such a sound = approach.

-        = ;  contained-i= n: for plugable items contained-in requires to be mandatory too as a = plugable item can=E2=80=99t be =E2=80=9Cfloating=E2=80=9D in the = device.  But we then hit a problem for the = =E2=80=98top-level=E2=80=99 entity which not contained in anything (and = =E2=80=98fooling=E2=80=99 the model by having it pointing to itself is = not allowed).  Contained-in can=E2=80=99t be derived by the NC = server: what to do if 2 entities of the same class are preprovisioned = (together with ports and interfaces related to subscribers)?  We = need to be sure that the subscribers are on the intended = ports.

 =

This would = mean that the ietf-entity model would require a revision to add leafs = for these plugable items.  What is the best way to address = this?

 =

Best regards - Vriendelijke groeten,=

Bart Bogaert=

Broadband-Access System Architect Data=

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

 =

NOKIA=

Copernicusl= aan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 = 621 642 Register of Legal Entities = Antwerp


&= lt;<
This message (including any attachments) contains = confidential information intended for a specific individual and purpose, = and is protected by law. If you are not the intended recipient, you = should delete this message. Any disclosure, copying, or distribution of = this message, or the taking of any action based on it, is strictly = prohibited without the prior consent of its = author.
>>=

 =

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

=

 

------=_NextPart_001_001D_01D1EBE8.1F7A64F0-- ------=_NextPart_000_001C_01D1EBE8.1F7A64F0 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 AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODAxMDkzMDM2WjAjBgkqhkiG9w0B CQQxFgQUABCadXDnzxkAzirr/LtMRMjZXJAwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQBD m8ApeJzoFSJgBBnVgoEtCNdlo9yKshfPCbLMLt5GPLd83b+1M8qrD6bEN9gy3ONAsog7HMcoAIIR Uqqqy1OLXI0YIS2ttQm7GZR9jDPF5fu+YZACGJl3xO47dJx7yJPuQaqoBXtU6UC4rNIocO9ukeFS 5B3rDH9VkVIp3lv1jNDoXQBq99rGYJd3bMcKLd6NgIYK54gdDPrYXTNw1TPxMjZfW/PRMk2uQFOi G5aYjoPUg3h732v/asklDQa9zTVhIvmJL6K9ef8mE1y0yUU4czIR8m/8hA12eXS9iRWpd8TSqgRg xYff8GhK4m2W7TTe8EC8VrrHkXj1ojm7v1DuAAAAAAAA ------=_NextPart_000_001C_01D1EBE8.1F7A64F0-- From nobody Mon Aug 1 02:42: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 1A4D412B063 for ; Mon, 1 Aug 2016 02:42:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 6MaM4UvuWhyd for ; Mon, 1 Aug 2016 02:42: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 0549612B041 for ; Mon, 1 Aug 2016 02:42: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 4398C8D0; Mon, 1 Aug 2016 11:42:20 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EDVIz7mWjW4a; Mon, 1 Aug 2016 11:42:18 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Aug 2016 11:42:19 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4C01120077; Mon, 1 Aug 2016 11:42:19 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id hPSMHWIMvky6; Mon, 1 Aug 2016 11:42:18 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E2E7420075; Mon, 1 Aug 2016 11:42:17 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id CF4003BFDA8D; Mon, 1 Aug 2016 11:42:12 +0200 (CEST) Date: Mon, 1 Aug 2016 11:42:12 +0200 From: Juergen Schoenwaelder To: William Lupton Message-ID: <20160801094212.GA7335@elstar.local> Mail-Followup-To: William Lupton , "Bogaert, Bart (Nokia - BE)" , "netmod@ietf.org" References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] BBF extensions to ietf-entity 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, 01 Aug 2016 09:42:24 -0000 On Mon, Aug 01, 2016 at 10:13:38AM +0100, William Lupton wrote: > > There seems to be an analogy with interfaces here. The ietf-interfaces module provides only a read-only view of the interface stack, and interface type-specific modules are expected to provide a means of configuring the stack for interfaces of that type (where necessary). > This is not correct. The ietf-interfaces modules allows you to configure/create interfaces, including interfaces that are not currently present. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Mon Aug 1 02:48:06 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 48C0C12D581 for ; Mon, 1 Aug 2016 02:48:05 -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_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 PD-S5ofnbE-G for ; Mon, 1 Aug 2016 02:48:04 -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 7519112D0BE for ; Mon, 1 Aug 2016 02:48:04 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 6C1991E5D80; Mon, 1 Aug 2016 02:45:13 -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 OR5l8XX72_JY; Mon, 1 Aug 2016 02:45:13 -0700 (PDT) Received: from [192.168.1.127] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id 8A20B1E5D7B; Mon, 1 Aug 2016 02:45:12 -0700 (PDT) Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) Content-Type: text/plain; charset=utf-8 From: William Lupton In-Reply-To: <20160801094212.GA7335@elstar.local> Date: Mon, 1 Aug 2016 10:48:01 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <271ADDB6-2F43-47D0-BB4F-F2C9DCAFAAA2@broadband-forum.org> References: <20160801094212.GA7335@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] BBF extensions to ietf-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: Mon, 01 Aug 2016 09:48:05 -0000 Sorry, I was talking only about the interface _stack_ configuration. Ref = RFC 7223 Section 3.3: While the interface layering is configured in interface-type-specific = models, two generic state data leaf-lists, "higher-layer-if=E2=80=9D and = "lower-layer-if", represent a read-only view of the interface layering = hierarchy. I was just wondering whether configuration of entity relationships might = be analogous. > On 1 Aug 2016, at 10:42, Juergen Schoenwaelder = wrote: >=20 > On Mon, Aug 01, 2016 at 10:13:38AM +0100, William Lupton wrote: >>=20 >> There seems to be an analogy with interfaces here. The = ietf-interfaces module provides only a read-only view of the interface = stack, and interface type-specific modules are expected to provide a = means of configuring the stack for interfaces of that type (where = necessary). >=20 > This is not correct. The ietf-interfaces modules allows you to > configure/create interfaces, including interfaces that are not > currently present. From nobody Mon Aug 1 02:52: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 63CA712D5BF for ; Mon, 1 Aug 2016 02:52:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -5.487 X-Spam-Level: X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 4prAutMrUQYh for ; Mon, 1 Aug 2016 02:52:40 -0700 (PDT) Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2619212D595 for ; Mon, 1 Aug 2016 02:52: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 D7121CDE; Mon, 1 Aug 2016 11:52:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id Xl2tLgB9Izsn; Mon, 1 Aug 2016 11:52:37 +0200 (CEST) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 1 Aug 2016 11:52:38 +0200 (CEST) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4474320075; Mon, 1 Aug 2016 11:52:38 +0200 (CEST) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id T88I48U_LoeR; Mon, 1 Aug 2016 11:52:37 +0200 (CEST) Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 594C820077; Mon, 1 Aug 2016 11:52:37 +0200 (CEST) Received: by elstar.local (Postfix, from userid 501) id AD9723BFDC70; Mon, 1 Aug 2016 11:52:31 +0200 (CEST) Date: Mon, 1 Aug 2016 11:52:31 +0200 From: Juergen Schoenwaelder To: William Lupton Message-ID: <20160801095231.GB7335@elstar.local> Mail-Followup-To: William Lupton , "Bogaert, Bart (Nokia - BE)" , "netmod@ietf.org" References: <20160801094212.GA7335@elstar.local> <271ADDB6-2F43-47D0-BB4F-F2C9DCAFAAA2@broadband-forum.org> 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: <271ADDB6-2F43-47D0-BB4F-F2C9DCAFAAA2@broadband-forum.org> User-Agent: Mutt/1.6.0 (2016-04-01) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] BBF extensions to ietf-entity 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, 01 Aug 2016 09:52:41 -0000 On Mon, Aug 01, 2016 at 10:48:01AM +0100, William Lupton wrote: > Sorry, I was talking only about the interface _stack_ configuration. Ref RFC 7223 Section 3.3: > > While the interface layering is configured in interface-type-specific models, two generic state data leaf-lists, "higher-layer-if” and "lower-layer-if", represent a read-only view of the interface layering hierarchy. > > I was just wondering whether configuration of entity relationships might be analogous. > Once question is what does it means to configure hardware entities. Or to ask the question differently, perhaps BBF really intents to configure interfaces instead of phsyical ports. /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 Aug 1 06:52: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 1854D12D9AB for ; Mon, 1 Aug 2016 06:52:50 -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 M3m0IKRiRs6a for ; Mon, 1 Aug 2016 06:52:45 -0700 (PDT) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 5986012D9C4 for ; Mon, 1 Aug 2016 06:45:38 -0700 (PDT) Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 95A901CC00A1; Mon, 1 Aug 2016 15:45:45 +0200 (CEST) From: Ladislav Lhotka To: Balazs Lengyel , Juergen Schoenwaelder In-Reply-To: <1f3c1297-da13-9fdb-fa8e-b9b8141d82a0@ericsson.com> References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com> <6C7B9426-DB44-40B0-9AEE-1A7A0D51D1D0@nic.cz> <20160728145153.GC1752@elstar.local> <1f3c1297-da13-9fdb-fa8e-b9b8141d82a0@ericsson.com> User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0) Date: Mon, 01 Aug 2016 15:45:43 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Design-Time 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, 01 Aug 2016 13:52:50 -0000 Balazs Lengyel writes: > Hello, > > As I understood Andy, it was already agreed that if you advertise > support for a model that defines extensions you MUST support those > extensions. So you effectively advertise support for those extensions. OK, so let's say a server advertises "ietf-system" (that imports "ietf-netconf-acm") with conformance-type "implement" and "ietf-netconf-acm" with conformance-type "import". Does the server support "nacm:default-deny-*" extensions or not? Moreover, clients don't advertise any modules. > As an example if you claim support for nacm, you MUST support its > extensions. NACM is different in that the nacm:default-deny-* extensions just give auxiliary information - they help NACM-aware clients avoid sending requests that result in access-denied errors. In contrast, a client that doesn't support schema mount cannot be used with a server that does. Lada > > Balazs > > > On 2016-07-29 15:31, Ladislav Lhotka wrote: >> For this approach to work, we would need to change the character of >> extensions, in particular: >> >> - an implementation should be able to signal which extensions are >> supported, >> >> - extensions that change the data model need to be labelled as mandatory >> to support. > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > -- Ladislav Lhotka, CZ.NIC Labs PGP Key ID: E74E8C0C From nobody Mon Aug 1 07:10: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 0371012D145 for ; Mon, 1 Aug 2016 07:10:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 kVHIf8L8H87T for ; Mon, 1 Aug 2016 07:10:28 -0700 (PDT) Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 A162B12D691 for ; Mon, 1 Aug 2016 07:09:10 -0700 (PDT) Received: by mail-ua0-x22e.google.com with SMTP id 35so106916188uap.1 for ; Mon, 01 Aug 2016 07:09:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=+YIxhLE1Tw0BxMLAvv6zSQeTlMWQof16EfbIdQhckA4=; b=fG4cNqFnSUB3zb0BujVnVzD9Au2gktMy0XZu7ggFvQnUHBs0mEMoxM+lYZgX3kGtGu 4XNIHQE33OS5fcewzMq7NwK/WGiSJlOBp4tlsRAp96BbupVD4HFwm05ZF8OAiYtqk5T+ 97Tdu6hYiiZVqETc6N2kRdCLGQWHZlO0neM8YI17dGigPJEynk9EFXZUiO+VuoH9JsGA UbcUqHfsnuVvP1gEwNjkq8a3mxaoowowG1koEtuU54PEjqkxzBJPIWYXAe1jXiksE3zs vyc9TW2kHRS8QapGVLcZWJH9npjquLNXk1Q5VKKIRmUc8u0fpzGQzD58B3uF9dVW2Kcx zpAA== 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:from:date :message-id:subject:to:cc; bh=+YIxhLE1Tw0BxMLAvv6zSQeTlMWQof16EfbIdQhckA4=; b=O/lTIEIP/5Oo8EXELMgHt1o9ddqlMhr080WusLTAH9y3oTMHyxqT4gnAlAhCP0f8q6 F3spQ/n5DDEZEMeqAqG9ieSFKwFL7tnq0+1AMrKZRrmkCnaXox16FsdSAXUFYYxzIxkf WpXBsm0n6uMdWv2QYC0oYh76hQXQq0nR/6t0Muw6y4WNF1lgwyOOrTV0F/gH6jmsz0/Q MbvoDRikKVEqnmxcIrw/8BgNloMZQ3Ca9S6Sw/i6BCkBpMMYYWAvXWE9mmSXx3yBwx5N +7DtaxDzHT0OPq1f4GVNcKGipDiqk2yZ79eU9LG3WjL+kVkgV7tqbM5J1q2ujhWA+R3k 0zqA== X-Gm-Message-State: AEkooutf7lRnTwRF7qWyXXDKRmIt/e/P0j5qGvhgMeXUvFn+kiFhqdPQvyTh9uH8lmg8ER4ZXFYU3DTDg82Mpg== X-Received: by 10.176.69.210 with SMTP id u76mr22297355uau.16.1470060549669; Mon, 01 Aug 2016 07:09:09 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.4.198 with HTTP; Mon, 1 Aug 2016 07:09:08 -0700 (PDT) In-Reply-To: References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com> <6C7B9426-DB44-40B0-9AEE-1A7A0D51D1D0@nic.cz> <20160728145153.GC1752@elstar.local> <1f3c1297-da13-9fdb-fa8e-b9b8141d82a0@ericsson.com> From: Andy Bierman Date: Mon, 1 Aug 2016 07:09:08 -0700 Message-ID: To: Ladislav Lhotka Content-Type: multipart/alternative; boundary=94eb2c11c304dca37d05390324d5 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Design-Time 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, 01 Aug 2016 14:10:32 -0000 --94eb2c11c304dca37d05390324d5 Content-Type: text/plain; charset=UTF-8 On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka wrote: > Balazs Lengyel writes: > > > Hello, > > > > As I understood Andy, it was already agreed that if you advertise > > support for a model that defines extensions you MUST support those > > extensions. So you effectively advertise support for those extensions. > > OK, so let's say a server advertises "ietf-system" (that imports > "ietf-netconf-acm") with conformance-type "implement" and > "ietf-netconf-acm" with conformance-type "import". Does the server > support "nacm:default-deny-*" extensions or not? > > The server is only claiming conformance on the modules that it implements. The YANG conformance model has issues. This is not news. > Moreover, clients don't advertise any modules. > > not sure why this matters > > As an example if you claim support for nacm, you MUST support its > > extensions. > > NACM is different in that the nacm:default-deny-* extensions just give > auxiliary information - they help NACM-aware clients avoid sending > requests that result in access-denied errors. > > they are quite clear wrt/ how a NACM implementation must treat the extensions. > In contrast, a client that doesn't support schema mount cannot be used > with a server that does. > > why not? anydata mount-point { mount:extension1; mount:extension2; } A regular client will see an anydata node with schema-less child nodes. A mount-aware client will see a mount-point and know how to determine the schema for the child nodes of the mount-point. Lada > Andy > > > > > Balazs > > > > > > On 2016-07-29 15:31, Ladislav Lhotka wrote: > >> For this approach to work, we would need to change the character of > >> extensions, in particular: > >> > >> - an implementation should be able to signal which extensions are > >> supported, > >> > >> - extensions that change the data model need to be labelled as mandatory > >> to support. > > > > -- > > Balazs Lengyel Ericsson Hungary Ltd. > > Senior Specialist > > Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com > > > > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --94eb2c11c304dca37d05390324d5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka <<= a href=3D"mailto:lhotka@nic.cz" target=3D"_blank">lhotka@nic.cz> wrote:
Balazs Lengyel <balazs.lengyel@ericsson.com> writes:

> Hello,
>
> As I understood Andy, it was already agreed that if you advertise
> support for a model that defines extensions you MUST support those
> extensions. So you effectively advertise support for those extensions.=

OK, so let's say a server advertises "ietf-system" (that impo= rts
"ietf-netconf-acm") with conformance-type "implement" a= nd
"ietf-netconf-acm" with conformance-type "import". Does= the server
support "nacm:default-deny-*" extensions or not?


The server is only claiming conformanc= e on the modules that it implements.
The YANG conformance model h= as issues.=C2=A0 This is not news.

=C2=A0
Moreover, clients don't advertise any modules.


not sure why this matters
=C2=A0
> As an example if you claim support for nacm, you MUST support its
> extensions.

NACM is different in that the nacm:default-deny-* extensions just give
auxiliary information - they help NACM-aware clients avoid sending
requests that result in access-denied errors.


they are quite clear wrt/ how a NACM i= mplementation must treat the extensions.

=C2=A0
In contrast, a client that doesn't support schema mount cannot be used<= br> with a server that does.


why not?

=C2= =A0 =C2=A0anydata mount-point {
=C2=A0 =C2=A0 =C2=A0 mount:extens= ion1;
=C2=A0 =C2=A0 =C2=A0 mount:extension2;
=C2=A0 =C2= =A0}

A regular client will see an anydata node wit= h schema-less child nodes.
A mount-aware client will see a mount-= point and know how to determine
the schema for the child nodes of= the mount-point.


Lada

Andy
=C2=A0

>
> Balazs
>
>
> On 2016-07-29 15:31, Ladislav Lhotka wrote:
>> For this approach to work, we would need to change the character o= f
>> extensions, in particular:
>>
>> - an implementation should be able to signal which extensions are<= br> >>=C2=A0 =C2=A0 supported,
>>
>> - extensions that change the data model need to be labelled as man= datory
>>=C2=A0 =C2=A0 to support.
>
> --
> Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 email: Balazs.Lengyel@er= icsson.com
>

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

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

--94eb2c11c304dca37d05390324d5-- From nobody Mon Aug 1 07:52: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 6972012DA78 for ; Mon, 1 Aug 2016 07:52:01 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.934 X-Spam-Level: X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KScZwnmws0o0 for ; Mon, 1 Aug 2016 07:51:57 -0700 (PDT) Received: from resqmta-po-07v.sys.comcast.net (resqmta-po-07v.sys.comcast.net [IPv6:2001:558:fe16:19:96:114:154:166]) (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 B9B5312D9C4 for ; Mon, 1 Aug 2016 07:51:52 -0700 (PDT) Received: from resomta-po-09v.sys.comcast.net ([96.114.154.233]) by resqmta-po-07v.sys.comcast.net with SMTP id UEYbb4fk9qbrLUEZMbxbsg; Mon, 01 Aug 2016 14:51:52 +0000 Received: from hobgoblin.ariadne.com ([73.100.16.189]) by comcast with SMTP id UEZKb6pL1frcyUEZLb2JvC; Mon, 01 Aug 2016 14:51:52 +0000 Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u71EpnuV028427; Mon, 1 Aug 2016 10:51:49 -0400 Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u71Epn0O028420; Mon, 1 Aug 2016 10:51:49 -0400 X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f From: worley@ariadne.com (Dale R. Worley) To: William Lupton In-Reply-To: <57FC9BC0-DAC4-4671-AB6D-D45B6D1E7710@broadband-forum.org> (wlupton@broadband-forum.org) Sender: worley@ariadne.com (Dale R. Worley) Date: Mon, 01 Aug 2016 10:51:49 -0400 Message-ID: <8737mok0e2.fsf@hobgoblin.ariadne.com> X-CMAE-Envelope: MS4wfHAde38P+TyfJojZ9ASw3wneAt4yRpHBtQDL3dHMKfz45x7VTVMAV+yYzZDr052Y0y9kOIpTUzDocMiD3f1hg6pNEJc4v1WN6I6cRZWoNJuFDw5PFh/j D912U2yj99t+6aC9jGZRnKJojEGjkTiK7x7EbOCFtFgcZWGrpIcav95Bbj9HPVymjgWdcBeIdmsCzKFBGfk3XElfnLVV2s+TiVPw1b2JxGbFgTmaywhKM4q/ xbCbZZnnZQs+7hIyRTz86g== Archived-At: Cc: netmod@ietf.org Subject: Re: [netmod] YANG 1.1: XML naming restriction X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2016 14:52:01 -0000 William Lupton writes: > But the errata at https://www.w3.org/XML/xml-V10-5e-errata > say the following. There > are also related changes to Section 2.6 (processing instructions) and > Section 3 (logical structures). >> Section 2.3 Common Syntactic Constructs >> Delete the following paragraph: >> >> Names beginning with the string "xml", or with any string which would >> match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for >> standardization in this or future versions of this specification. Hmmm, I'd not heard of that. But let me also quote this part of the same errata, which is the new version of section 3: >> This specification does not constrain the application semantics, use, >> or (beyond syntax) names of the element types and attributes, except >> that names beginning with "xml:" are reserved for standardization in >> this or future specifications from the XML Core Working Group or its >> successors. If I read everything correctly, the only reserved names are now: - beginning with "xml:" (the revised XML spec) - the attribute "xmlns" (XML Namespaces spec) - attributes beginning "xmlns:" (XML Namespaces spec) - the attributres "xml:base" and "xml:id" (other XML specs, per Wikipedia) And it seems that the only way to use Yang to cause the creation of an XML name that violates those rules is to define a prefix "xml", which will appear on element names. But maybe even that one exclusion isn't true, since the use of a Yang prefix as an XML namespace name is not mandatory; the processor is allowed to use a different prefix if there is a "conflict". (6020bis, section 7.1.4) Dale From nobody Mon Aug 1 08: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 9250412DC66 for ; Mon, 1 Aug 2016 08:11:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.287 X-Spam-Level: X-Spam-Status: No, score=-8.287 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=-1.287] 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 GUxVKJM-eqPQ for ; Mon, 1 Aug 2016 08:11:03 -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 B6F9812DC30 for ; Mon, 1 Aug 2016 08:10:59 -0700 (PDT) Received: from [IPv6:2001:718:1a02:1:79c5:7fa1:2e8:dedb] (unknown [IPv6:2001:718:1a02:1:79c5:7fa1:2e8:dedb]) by mail.nic.cz (Postfix) with ESMTPSA id 4A6DF61EB6; Mon, 1 Aug 2016 17:10:58 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470064258; bh=Dk2Xn6H2kEdzwQCvEvFvpUIOh9i00/SliE6Mq198o6o=; h=From:Date:To; b=eN6/zFw05tYD4AJ6U2PZTX/e7i3cRxiZk4Xo4npIq6Yod9tszTNoToPcMJC3vgeY3 qvelq9HUm0wAFYr0+60U7MRgzPuWaIC0cuukhYPvXunw73xJogIPDWhfk/Rc+Z0n4I Nnvhz42/teWdrLE4zjpaHFbu5hXKGpnLrB2k71CE= Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Ladislav Lhotka In-Reply-To: Date: Mon, 1 Aug 2016 17:11:05 +0200 Content-Transfer-Encoding: quoted-printable Message-Id: References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com> <6C7B9426-DB44-40B0-9AEE-1A7A0D51D1D0@nic.cz> <20160728145153.GC1752@elstar.local> <1f3c1297-da13-9fdb-fa8e-b9b8141d82a0@ericsson.com> To: Andy Bierman 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] Design-Time 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, 01 Aug 2016 15:11:05 -0000 > On 01 Aug 2016, at 16:09, Andy Bierman wrote: >=20 >=20 >=20 > On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka wrote: > Balazs Lengyel writes: >=20 > > Hello, > > > > As I understood Andy, it was already agreed that if you advertise > > support for a model that defines extensions you MUST support those > > extensions. So you effectively advertise support for those = extensions. >=20 > OK, so let's say a server advertises "ietf-system" (that imports > "ietf-netconf-acm") with conformance-type "implement" and > "ietf-netconf-acm" with conformance-type "import". Does the server > support "nacm:default-deny-*" extensions or not? >=20 >=20 > The server is only claiming conformance on the modules that it = implements. > The YANG conformance model has issues. This is not news. My point was that "advertise" isn't sufficient. >=20 > =20 > Moreover, clients don't advertise any modules. >=20 >=20 > not sure why this matters If the server can learn what extensions this client supports, it could = adjust its behaviour (probably impossible for something like schema = mount though). >=20 > =20 > > As an example if you claim support for nacm, you MUST support its > > extensions. >=20 > NACM is different in that the nacm:default-deny-* extensions just give > auxiliary information - they help NACM-aware clients avoid sending > requests that result in access-denied errors. >=20 >=20 > they are quite clear wrt/ how a NACM implementation must treat the = extensions. Yes, but a client that doesn't understand them can still safely work = with an NACM-aware server. >=20 > =20 > In contrast, a client that doesn't support schema mount cannot be used > with a server that does. >=20 >=20 > why not? >=20 > anydata mount-point { > mount:extension1; > mount:extension2; > } >=20 > A regular client will see an anydata node with schema-less child = nodes. > A mount-aware client will see a mount-point and know how to determine > the schema for the child nodes of the mount-point. The regular client doesn't know the mounted parts of the data model, so = no automation is possible for this data. Lada=20 >=20 >=20 > Lada >=20 > Andy > =20 >=20 > > > > Balazs > > > > > > On 2016-07-29 15:31, Ladislav Lhotka wrote: > >> For this approach to work, we would need to change the character of > >> extensions, in particular: > >> > >> - an implementation should be able to signal which extensions are > >> supported, > >> > >> - extensions that change the data model need to be labelled as = mandatory > >> to support. > > > > -- > > Balazs Lengyel Ericsson Hungary Ltd. > > Senior Specialist > > Mobile: +36-70-330-7909 email: = Balazs.Lengyel@ericsson.com > > >=20 > -- > Ladislav Lhotka, CZ.NIC Labs > PGP Key ID: E74E8C0C >=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 Mon Aug 1 08:20: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 586CF12DC2E; Mon, 1 Aug 2016 08:20:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -8.206 X-Spam-Level: X-Spam-Status: No, score=-8.206 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, RP_MATCHES_RCVD=-1.287] 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 WYzDy-S_ZJFr; Mon, 1 Aug 2016 08:20:07 -0700 (PDT) Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) (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 9022412DC3E; Mon, 1 Aug 2016 08:20:07 -0700 (PDT) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A2EfAgBrZ59X/xUHmMZdHAEBglkhLVZ8B?= =?us-ascii?q?o0lqVmCD4F9JoUtSgKBLTgUAQEBAQEBAQNaJ4JTSQEBAQEBAQEBAUwCE1wDEht?= =?us-ascii?q?eAQwJFVYmAQQBGhqIDwENphaaPgEBCAEBAQEjhiuGBYJqAQEdgyqCLwWZMwGYa?= =?us-ascii?q?IVVkCceNoN6bgGGXjcBfgEBAQ?= X-IPAS-Result: =?us-ascii?q?A2EfAgBrZ59X/xUHmMZdHAEBglkhLVZ8Bo0lqVmCD4F9JoU?= =?us-ascii?q?tSgKBLTgUAQEBAQEBAQNaJ4JTSQEBAQEBAQEBAUwCE1wDEhteAQwJFVYmAQQBG?= =?us-ascii?q?hqIDwENphaaPgEBCAEBAQEjhiuGBYJqAQEdgyqCLwWZMwGYaIVVkCceNoN6bgG?= =?us-ascii?q?GXjcBfgEBAQ?= X-IronPort-AV: E=Sophos;i="5.28,455,1464667200"; d="scan'208,217";a="185994812" Received: from unknown (HELO co300216-co-erhwest-exch.avaya.com) ([198.152.7.21]) by co300216-co-outbound.net.avaya.com with ESMTP; 01 Aug 2016 11:20:06 -0400 X-OutboundMail_SMTP: 1 Received: from unknown (HELO AZ-FFEXHC03.global.avaya.com) ([135.64.58.13]) by co300216-co-erhwest-out.avaya.com with ESMTP/TLS/AES256-SHA; 01 Aug 2016 11:20:06 -0400 Received: from AZ-FFEXMB04.global.avaya.com ([fe80::6db7:b0af:8480:c126]) by AZ-FFEXHC03.global.avaya.com ([135.64.58.13]) with mapi id 14.03.0294.000; Mon, 1 Aug 2016 11:20:03 -0400 From: "Romascanu, Dan (Dan)" To: "ieee-ietf-coord@ietf.org" , "NETMOD Working Group" Thread-Topic: exchange of messages between the OPS Area and IEEE 802.1 on VLAN YANG models Thread-Index: AdHsCCxm4CMVSWSJS5K328UHlhhkzg== Date: Mon, 1 Aug 2016 15:20:01 +0000 Message-ID: <9904FB1B0159DA42B0B887B7FA8119CA75258544@AZ-FFEXMB04.global.avaya.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.64.58.48] Content-Type: multipart/alternative; boundary="_000_9904FB1B0159DA42B0B887B7FA8119CA75258544AZFFEXMB04globa_" MIME-Version: 1.0 Archived-At: Subject: [netmod] exchange of messages between the OPS Area and IEEE 802.1 on VLAN YANG models X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2016 15:20:10 -0000 --_000_9904FB1B0159DA42B0B887B7FA8119CA75258544AZFFEXMB04globa_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, On 7/21 Benoit Claise (OPS AD) sent a message to the IEEE 802.1 WG concerni= ng the VLAN YANG models work in the IETF METMOD WG. The IEEE 802.1 WG which= met in a plenary meeting last week discussed and responded. The response a= nd the initial mail are posted at http://www.ieee802.org/1/files/public/doc= s2016/liaison-ietf-intf-vlan-yang-0716-v01.txt. Regards, Dan --_000_9904FB1B0159DA42B0B887B7FA8119CA75258544AZFFEXMB04globa_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

On 7/21 Benoit Claise (OPS AD) sent a message to the= IEEE 802.1 WG concerning the VLAN YANG models work in the IETF METMOD WG. = The IEEE 802.1 WG which met in a plenary meeting last week discussed and re= sponded. The response and the initial mail are posted at http://www.ieee802.org/1/files/public/docs2016/liaison-ietf-intf-vlan-yang-= 0716-v01.txt.

 

Regards,

 

Dan

 

--_000_9904FB1B0159DA42B0B887B7FA8119CA75258544AZFFEXMB04globa_-- From nobody Mon Aug 1 14:24: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 E084612D92A for ; Mon, 1 Aug 2016 14:24:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.922 X-Spam-Level: X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCdv5csrJs3u for ; Mon, 1 Aug 2016 14:24:46 -0700 (PDT) Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0099.outbound.protection.outlook.com [104.47.40.99]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E625612D8D3 for ; Mon, 1 Aug 2016 14:24:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=N2nlt+BcsjWjhfSDgigXkpsuRzhb8exfON2mujMMezU=; b=DZzSEnDM4IBcXklZUbuC1gxVPT7hCBmXKczFKM+rJ1AF48BpcnszlH3oFnTkoUrDnc/tXMfVz+UDS3wGULXY+V//Ab1Du7VV0Ah97XYMLDan9K6+XO0bJu7iUR5SgcuoXKRP7A2VbM1ZBo6rT0FjAFzKBi18Q4iKYW48wpHhwI8= Received: from BLUPR05CA0042.namprd05.prod.outlook.com (10.141.20.12) by CY1PR05MB1961.namprd05.prod.outlook.com (10.162.216.19) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Mon, 1 Aug 2016 21:24:43 +0000 Received: from BL2FFO11OLC011.protection.gbl (2a01:111:f400:7c09::171) by BLUPR05CA0042.outlook.office365.com (2a01:111:e400:855::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.557.15 via Frontend Transport; Mon, 1 Aug 2016 21:24:43 +0000 Authentication-Results: spf=softfail (sender IP is 66.129.239.19) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net; Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.19 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.19) by BL2FFO11OLC011.mail.protection.outlook.com (10.173.160.157) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.549.5 via Frontend Transport; Mon, 1 Aug 2016 21:24:44 +0000 Received: from magenta.juniper.net (172.17.27.123) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Mon, 1 Aug 2016 14:24:42 -0700 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id u71LOfx31407; Mon, 1 Aug 2016 14:24:41 -0700 (PDT) (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.14.4/8.14.3) with ESMTP id u71LLKlu020123; Mon, 1 Aug 2016 17:21:20 -0400 (EDT) (envelope-from phil@idle.juniper.net) Message-ID: <201608012121.u71LLKlu020123@idle.juniper.net> To: Ladislav Lhotka In-Reply-To: <04F63698-5EA2-4A75-81EF-62BB5DCC2DC6@nic.cz> Date: Mon, 1 Aug 2016 17:21:19 -0400 From: Phil Shafer MIME-Version: 1.0 Content-Type: text/plain X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.19; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(189002)(199003)(81156014)(81166006)(86362001)(8676002)(15975445007)(2950100001)(110136002)(68736007)(586003)(77096005)(8936002)(1076002)(87936001)(4326007)(5003940100001)(97736004)(106466001)(11100500001)(54356999)(53416004)(76506005)(92566002)(50986999)(47776003)(69596002)(8276002)(7696003)(50466002)(19580395003)(105596002)(189998001)(48376002)(7846002)(356003)(2810700001)(2906002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR05MB1961; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC011; 1:qu+DpZynifr6x+QBpbwpIAnjQIl3VcXSD/bcX0rSxQWtSm8zlKPGHFoCjn8S0j3kMwAHStegUcfRDOWSclAZ22LTzpCA25l825PGfD1tvBPoPhby/CfuYgwKaUZnjll0l8NQALgY6s/HeT4tDW79w1FcKKcqMkPB9bMLF27aoLSO7rNy6/yf2X1tCyT2r6PnPBtOLjpqObi2A6bLiT7MsczwHGZeakV8Gp+2n9m1gHZxcTanAsY1z16yIpkRe1YQHLCsbgG3vkZoM17G1k1J2v9NsNXu+72a+doyAZjUBp35CQO572EjmdMeTZUbsE9HSnXTlfXe8oLKCYycy6BznH/HQBnM/cVrsGiH+OwHHSny8ZG2Vdg6fDCzb2XOIRkQi0B+4kYJ7WupJlCsxr3nBG6+m4ZdRXFJqQVvbDz8MYRBc2U6y4WnCxBJBRtM5FiZ5idGqSBlIVqgR663j7AINFICw6f0dkR4eLN4wvYnLSnbOJ+gDaio3u4MSLpsUhig3D/AsTNezNUtfBsmYzWkSK6oXXjiZw10WtlzHZBhkuLVNbLrDRdI4uWQaqUc9U+1 X-MS-Office365-Filtering-Correlation-Id: 0f247910-87e6-40a6-dc2f-08d3ba524204 X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1961; 2:ND2Z3kj3VA2B072cUzu/Sx+D6AdAcj7PufoHeKr2nDQe2Zpy12QxZMJ1GYfI6DI8is4CND+DBGg8ZU4dBKiQRLZJZ/P03xCVKvXhU3+YT7u4wJRkPJkyQXqM3P8qBOEfFJfnT7FhHgU3/o8Y8GbDQegtkWtqXKNGyADE6D5rqa2DTP47akQVDXtfhyTo4Re8; 3:PksTpRhAv5XIWMCTmcxKLG00gqE47JCFnSSUtKX3Ih6Ux4hMA/5iQRVdTZDVRsxOikwgCgvm1YRmlq/NSut/CswXJxovXvHVvYCucgEQPJePK9f0LkSaLjOlNFGmeWeWpKg4bg3r70WbjQ1Q03v9hNop+TAKmF+1/m20Im/6hb0HHuAPOgSQmX4mCjK0QmV2Ja+ScDIuMN7HD52nir8pZdJpyo2sb1SzhezOsQpSWVI= X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR05MB1961; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1961; 25:GIB+/eb1cjDSL+A7+dPFDxjCDorhiyggqAhe2nr07l7j3Dyf9/fKi27mR0ZHrCz2M7FkpPwk7CDLYENrqQ2x+gSPpeACwR7YnMEhcBaZCxB9cnXiDvU0gpDHV481DkSCawZh1/lC9+4o+JUthMwsdWiPy5ahi0ERDhyVoFe5LyvLKl9Q3GsQmZqGUJSi09BzX94WRBlhgsLge10VrXyuz1NgIRRntSaa+WF7pACeY37Wb9OrhMwqU0EeZ9UBfQtrFo0hkcnETLkY71rFSjn2kcchYcUjT+FeJVLlpPbuwgmYFCp61KlBQw9PQBgNBTJrgyCIsoerOzSKQjdpQSohme6Qahmzc3wIWuMv6nFx1VryEtSdZi6pSj7BoLZdDM3KWoclNWMIZTobpEsSCLc/I7jMXiOCsDU2+CMRh1Mr9tUfk8xYT2xaPBrclvhEfHrF65iY/jv16oLetr3KPg8ny/RtX7tG6++AsJD0rcusLHUN4P86Ckki7B9fed6i2YaTzr4oO9GsSkSzgejWYS6lYM4JMWrU+Yo+QAxZ1ZJlZ8LyiRmLs/ZNz9tONOz7tNu3Tu8DduUAiYqSLkja1/n8/HSKEvxiN2bQpEzcqXsGgvSDUQrQZepz+tlMtc2FiGGo4KyE7FFY03GNyy4U3eL390ZVVzjBnUzSEIdI7LbLNgYLdF+upRvA/zoXQHh6ufIIzcGtmPzkLTDh3jvhIBmw4ubw9ZcVQpyUjzUOEfPxtAjeT3Md2wNXBunM0WH1c19fIX08zbIP0RtDPmk/pt23A0EmBXaQH8e45Qp1LeawiM/TywTfpDhYzuu91jOH77b0ashHoYuoLEBCYUwSyXi2fg== X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1961; 31:l/n4MDARPXd/1+h8u+wPFPzzrDxlgPBsuUp+IQxS1DpeZH5GUlCe4s3ifW7HLt881yUGbYxr7qtxAE0XzghI5ojlT+p6RA6l71oXY74XoGr8S//nEZxk7EXLJCNpcPLgnu1+JyVFBeqVQ3A+p6SStC7ryn6u7vO8Y4UfJh540sDPgZSKZ4TXWVfgqsB/JDmleLZslWQm9aC009ygPTpjSbdA5gIcu9ggEZAPCJUfBDE=; 20:Gwu5G7dS6ph7UQt7Wrljk50gg0d0Kq6lFdUvcAb+zjXQTDJCj8XhsuHYECKS5xzQ0kbPVZxQ4lpiT0+BSA15Fdam1Gju5Y4kMJvtSnYdLX+LtgeHzrQ9fbjuiah83GWL8A2IQ9hJgKo0jF4vGaH80Xj4w6TExYIGZUDtl0q4oPriow31mod7jd6rLOwcU/+vFOY2zed6WgTlK+7d5joGLwskEbhnMPC4XMFAysjhLuK8NDf7nkzLGgXHo+RFEzS6D3mfCqlybUsyRubRCP+1wukMPE1Ifs/oFfPl0nLiRHI8Pt7OL/PjY5whEym/9YHdcSnV2EwwpDTYIoGEvEiMxC7WR/XpJMpl9hD1HwtgBW6WNvk7KP5xRQF8Wc+LvIHxr3rQGTqNHtrAui0N4c2VqyOJaYGlPCKI1lfCp09umGrXdfA1Suz3i9juh58lO69qkVcvIbVRQiPbWGi/doCYjP8fjgHmzmDMomXHVknmboFdtcCGnLzGtZmhsDi0HMSF X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(119710715008430)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(13017025)(8121501046)(5005006)(13018025)(13023025)(13015025)(13024025)(3002001)(10201501046)(6055026); SRVR:CY1PR05MB1961; BCL:0; PCL:0; RULEID:(304825044); SRVR:CY1PR05MB1961; X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1961; 4:jZW/2nxjIRMj7brj1o8d2L3tvQ3+56Bh4QhwNUSkL/SqXNu2vNHspjs2alvngUnseLS7waoBkPdblOXvBK3S26fHMPf/EN80spGka0HQEb4kYN4h8AegTfQZQxItu1sXaXn3jLkd6qNDMzzHzVVQsnTZxGdcdLsD/SoG/SJMNyAo9QBieizXJGxfXSNMC29sefK2rsrontx6/Yq+lO2O+uIZ/QvvYAAnfExnB7Bitmj7cYfbJjKr6x6QQ8TDV7rIMxA5fI4jLz+nTL4zYb5tcIT6n5fGsu7N8gdzQJJxq+wWhpnSe6iE346uygQVNcvchTZDDEY7FV0X2+rU8qVfM2/FDaIeKiwjexEycbVnY6msqTdU4Z74TDRuM97yEdrLFZMGURd/OKQSaxShC5defh/gOKhnxSIA+M49cJmiBYYwPYptWCNxrynj64th+fcU3UR8gBZVz78akIjvTGRRRa5u9XUzAphZJMlgeWWptzfm9j6pfDKQByGXE2gNSJ2hKvW1vg3dGA05152TtMiWHtVMtGN2DUACCYUTY10eU5Ky2CIYb4dDwYgr7UPl3My4 X-Forefront-PRVS: 0021920B5A X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY1PR05MB1961; 23:LIEgn1lAmMlBu+mWuZoc6CK6s+gV2azfmOOj/yFko?= =?us-ascii?Q?9mpuP/aURTi4KZP+eTk1w5xhblV5odAcD5E0cQhT+lqjMNqbPoN7680qmUom?= =?us-ascii?Q?yMo9oRhM3cvgmvoO01wm1qIwNV8LKY7qaR2Tke049wUWRJVgc1YtoYLA6Nnr?= =?us-ascii?Q?rscH20Exq9duvEUxKst9fpaqWAG6JXkktcuLf7yUK7bf6ki03hOf0Qe8/n/F?= =?us-ascii?Q?8OTiH4ekvNMWK+DtPf6sIzQ2q+5IBvxR7iphFmTIUsEGQCW0TNgVyHBtvHhU?= =?us-ascii?Q?5ypMEgTUsfmHJ333alRVHVGTb6vAsfDhBOS4Ye/d77WN5tnmZMklge4YoOxT?= =?us-ascii?Q?nA7oYQMfh8PKtckP1n4zU4EKqJxqVBWVyywcwpzJ6vAsfbYG825XVlnYvwLl?= =?us-ascii?Q?EfIMk8sG+dkKNB2+/yspJS5wGMPD0+KHcmCFE5Uo/xCZCed3BAJd7kI9J55Y?= =?us-ascii?Q?Wl2h9VddmnBcM6MP2RMlDtOD+kKX8xLZ7YH3hxARZhEuC0Imco2/xmutXH2L?= =?us-ascii?Q?iPlALp2OYXJ4nNc1BpcK4uHXhwwlFiSArNlnPT41uVBJoUkjkLxSkLXyQpZK?= =?us-ascii?Q?DiNhwmbRLlx028K20KSV8ZybPmdWoikYnYgEMdmUwrW4g97lpjQO51jsHst6?= =?us-ascii?Q?6OCnj0/rcKkzcJaDX76gb25rzjTEPF00PoBCeFCGhGY24CktTM9KThynUROU?= =?us-ascii?Q?RZ49Cwt0iF4fV4zyf2O/H+4hfmkB1JL+kH6TuihBVd80ajDC1kGKOoTtHJX7?= =?us-ascii?Q?jU7xTJewWA36i+Nmtr/tCjbFEfWNI/wU1jGuUkHHly6JrvU9URXgUL5vQ9RN?= =?us-ascii?Q?gPSoUMeVYPxt4E+nuEl51oYuQxvHpITcd6aQSmtQ1frxCREwIezHGvS+5M4u?= =?us-ascii?Q?M9S5HiNxaP8PkJrNK23J/UHW3flXqJy2trALhVuz45MuDP2nPDb4Hx2XGwBW?= =?us-ascii?Q?HbmOHulRaFIgHtX+RsfXtCV+CVt9VqGwGekr0/CUHsi6zwzr/n+EwFnQJTlW?= =?us-ascii?Q?HUafK0OhgjEtE36DN9RWa+d0Rb+cLP16Mte8C8ldpiEQbVSRqkT79V7RUh6H?= =?us-ascii?Q?Lh3nXnwvSRbp5p5Ok2wZozWdh0T?= X-Microsoft-Exchange-Diagnostics: 1; CY1PR05MB1961; 6:8JIVaD0kQhUVKfJ5Nr8Fj8iR25rmrQS7dGuO965n4eYAMsokyKj4Q9OyYSomgdLlnKZENb/vDIALSFIZ+CeMRFu+bOyqIXyehSxjkKfXlG+tiEcOffllEVg0FzK7xqBVxhDJ9IVLljthl4zBb9KtnNrrzl7CurESL1eOVHceb+bPDgZZdo9WT5AC7GHFDOVVE6uMRgF2OFXahv7II3HKVWNr0ADlcbQArCdf7kCu3uRBdF/rxwRVYFRQWkyR8FgygnYop/muCK+4HdGbNGvOVVZs/qhczTZe37wJaQ4gWYkNYJlMu1wQArbnAKTCIAX822OVLwmmYZpsbHo5FOQcWw==; 5:sXknDbyX4vxWHfHnmXEO/XAaxkeDhDxcc2T0tSOYjXjjM1tGtr7UE5kva4PdpaBEQmKMCemPSeN+72vzWgD/iEJgvUNDS14YY8LyRr9KQJqU3Q33bizgrzfj0iqSmkMuun6lAbx0qpuKFSdUq0RqvGNMG+q+MjZ9TT+41smIk9s=; 24:pYQW0z0ESbNNiJ5GHleg0jibO48hNHNUC2U7Y0sYtfLRUKafua32tj6hkAJGUT4QhGylWjS54nFSOSuOBmapa0StNH0+71BQ3ijWnX3/n/Y=; 7:MsKQ7Pvo2HQnBe2BwEQlm+RzyWJp7VfR0qAc2KNSmczLmGyEf9r15/k9jtj+RbmDHmGWhQ3lx7h+1Hg0SVW0GeBEIrrhiTwabysDmTAe3a4aiR0J72i0OzW7DF3NqR1mW/xj+22GLTi3X4rNSqzqzks7SS19HVnn3AM6Swuq/fA0u2McZO+AymX2Lk/n/R1+MTJ8mt9UToVWML2vS18cfHyJPAZLh4C0+9bezbM7qC0MVF5wgiQYW6m+A7CSS15c SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 01 Aug 2016 21:24:44.3327 (UTC) X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.19]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR05MB1961 Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] YANG 1.1: XML naming restriction X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 01 Aug 2016 21:24:48 -0000 Ladislav Lhotka writes: >If it is still possible, it would IMO make a good sense to remove that comment from the >ABNF in 6020bis, and make this change in sec. 7.1.4: > >OLD > > A prefix is an identifier (see Section 6.2). > >NEW > > A prefix is an identifier (see Section 6.2), and it MUST NOT be the string "xml". Should it call out "xmlns" also? The original "xml" prohibition likely dates from JUNOS, where we encoded insert requests using the identifier name as the attribute (not yang:key), so element names followed the same rules as attributes. http://www.juniper.net/techpubs/en_US/junos14.2/topics/task/configuration/junos-xml-protocol-configuration-data-elements-reordering.html value-for-moving-object value-for-moving-object Thanks, Phil From nobody Mon Aug 1 18:10: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 BF1A312D0BC; Mon, 1 Aug 2016 18:10:09 -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 1TDRXX2dsCMJ; Mon, 1 Aug 2016 18:10:07 -0700 (PDT) Received: from NAM02-CY1-obe.outbound.protection.outlook.com (mail-cys01nam02hn0222.outbound.protection.outlook.com [104.47.37.222]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D94112B012; Mon, 1 Aug 2016 18:10:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Q4INrs59tyt/USPcQnySORKWQwRWSf7S7SQ5k4SLo+8=; b=WaSJtUyvr5KFA3zjIaSq1/zHocz/eOZ3vPPY5iDIV85oydQDmeHP3OG4blZT03REHijttv9VJVCtW1zO4RtH5F2HL6LkwfDlhIH8bNJO/HdAXVGHAUzckjexZMa6WikRWbjzQ934GOmnkcU8XVJjdBAHS/0q+wB62Q6ar8LhKD0= Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Tue, 2 Aug 2016 01:10:04 +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.0557.009; Tue, 2 Aug 2016 01:10:05 +0000 From: Kent Watsen To: Lou Berger , "netmod@ietf.org" Thread-Topic: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure Thread-Index: AQHR426Bbp8QhQYR/0+rHOW0oBTwuqAjJxmAgADv8QCABT5TAIABj1SAgAAMLoCAAZpIAIABXKyAgAABWwCAAAZtAIAABi8AgAGKvYCAAAaEAIAAD6aAgAAKXwCABQo5gA== Date: Tue, 2 Aug 2016 01:10:05 +0000 Message-ID: <125693B9-D275-495E-90BE-514803A75C0D@juniper.net> References: <20160721174033.GB54646@elstar.local> <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com> <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.18.0.160709 authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; x-ms-exchange-messagesentrepresentingtype: 1 x-originating-ip: [66.129.241.12] x-ms-office365-filtering-correlation-id: ecc60f6c-0151-453e-b5ea-08d3ba71bcda x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:4gGGXyJnOhKJesZEKnvKFS9PY+Jhmhxo+OEJbP+F/oXkEDt+uTw0+3MKxriDKqGlr3M6yyOyI4D572E630ZLjjKuxbOSupzODLZvDGNaE+YujRL81KMZbJYrcM5kT8BdlZOjioZGQ3ociJc9oFncuEFU+7Qi8BLv87MKSkL2c+VjwKa5Roh16cm1Z6Sk+AqDm/hyRsefzQZm3UsJeEEgrlOztAbExiJH4bN/TRM22cqA4R9fn9qLbYgakTyXtEZYlr+wTJg5KxHtEUnsazVPIElQxEsmxEAobpgFkfOUxSPrJSPWkZfVEM1G/SBbcUX0XEjuDWaGfDBpKpzYcv0WKw==; 5:V6rB7EG/T/CiUvc9DrRNpALgivZTK4InvgF2YegvRP/f8KryCFaO3a0Wk9W049tTE6V7sIekwZDuTiCp0003kd8YnqZD5HrD7gIYUqTyPMNAqOFxQK3n+aPM7FHIfmE1F30uDVXFczZ2fJlKOipJSESBLNiYP5PF5/guNntWyqg=; 24:UEba8DeRMFyUM/OcVHjypfvLZ3qGEv/ho2Mq/fIJMmUznN0JeRisP7aBFv7uwTmcucSK7aCPQ1IngIZgpPBYXA==; 7:bqitlWoSKpeHBUg+T4smVyBSD5UTRq8Ma4vNi5sq8prRug/kDtYJNNSn1lzrWYMgOTRDY5ZQ4UNOLzndcHvcwtMcxx8qjuowHPDSmtXBJCcwaif+j8ibTaCkSgn4rQ3TLPr6ayjZzOmGndnfbdy1m3qHjtxKOnmfFsGBGL1cGXJqt8NfdZdoUvNq6+inMEkoJrRnIs5sbtKuGFaI0N3ECXWJFeoegGwOMc/uPawzVPipB5jOq5jIR2TWliGT6APl x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451; x-fingerprintheader: 1 x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(158342451672863)(20558992708506)(278428928389397)(35073007944872); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:(304825044); SRVR:CY1PR0501MB1451; x-forefront-prvs: 0022134A87 x-forefront-antispam-report: SFV:SPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(92566002)(4001350100001)(189998001)(105586002)(87936001)(5001770100001)(97736004)(99286002)(93886004)(122556002)(305945005)(10400500002)(106356001)(36756003)(586003)(106116001)(2501003)(50986999)(86362001)(76176999)(3846002)(6116002)(102836003)(54356999)(101416001)(2906002)(83716003)(83506001)(81156014)(3660700001)(68736007)(8936002)(66066001)(81166006)(5002640100001)(7736002)(82746002)(77096005)(4326007)(7846002)(8676002)(3280700002)(2900100001)(33656002)(2950100001)(180318011); DIR:OUT; SFP:1501; SCL:9; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts) spamdiagnosticoutput: 1:22 Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Aug 2016 01:10:05.0781 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451 Archived-At: Cc: "draft-ietf-netmod-rfc6087bis@ietf.org" Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Aug 2016 01:10:10 -0000 PGFzIGEgY29udHJpYnV0b3I+DQoNCkZvbGxvd2luZyBMb3XigJlzIHJlY29tbWVuZGF0aW9uLCBt eSBwcm9wb3NlZCBjaGFuZ2VzIGZvciByZmM2MDg3YmlzIFNlY3Rpb24gNS4yMyBmb2xsb3c6DQoN Cg0KNS4yMy4gIE9wZXJhdGlvbmFsIERhdGENCg0KICAgSW4gWUFORywgYW55IGRhdGEgdGhhdCBo YXMgYSAiY29uZmlnIiBzdGF0ZW1lbnQgdmFsdWUgb2YgImZhbHNlIg0KICAgY291bGQgYmUgY29u c2lkZXJlZCBvcGVyYXRpb25hbCBkYXRhLiAgVGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuDQogICBj b25maWd1cmF0aW9uIChpLmUuLCAiY29uZmlnIiBzdGF0ZW1lbnQgaGFzIGEgdmFsdWUgb2YgInRy dWUiKSBhbmQNCiAgIG9wZXJhdGlvbmFsIGRhdGEgY2FuIGJlIGNvbXBsZXguDQoNCi0gICBPbmUg Y2hhbGxlbmdlIGZvciBjbGllbnQgZGV2ZWxvcGVycyBpcyBkZXRlcm1pbmluZyBpZiB0aGUgY29u ZmlndXJlZA0KLSAgIHZhbHVlIGlzIGJlaW5nIHVzZWQsIHdoaWNoIHJlcXVpcmVzIHRoZSBkZXZl bG9wZXIgdG8ga25vdyB3aGljaA0KLSAgIG9wZXJhdGlvbmFsIGRhdGEgcGFyYW1ldGVycyBhcmUg YXNzb2NpYXRlZCB3aXRoIHRoZSBwYXJ0aWN1bGFyDQorICBPbmUgY2hhbGxlbmdlIGZvciBjbGll bnQgYXBwbGljYXRpb25zIGlzIGRldGVybWluaW5nIGlmIGEgY29uZmlndXJlZA0KKyAgdmFsdWUg aXMgYmVpbmcgdXNlZCwgd2hpY2ggcmVxdWlyZXMgdGhlIGFwcGxpY2F0aW9uIHRvIGtub3cgd2hp Y2gNCisgIG9wZXJhdGlvbmFsIGRhdGEgcGFyYW1ldGVycyBhcmUgYXNzb2NpYXRlZCB3aXRoIGEg cGFydGljdWxhcg0KICAgY29uZmlndXJhdGlvbiBvYmplY3QgKG9yIGdyb3VwIG9mIG9iamVjdHMp Lg0KDQogICBJbiB0aGUgc2ltcGxlc3QgdXNlLWNhc2VzLCB0aGVyZSBpcyBubyBpbnRlcmFjdGlv biBiZXR3ZWVuDQogICBjb25maWd1cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBkYXRhLiAgRm9yIGV4 YW1wbGUsIHRoZSBhcmJpdHJhcnkNCiAgIGFkbWluaXN0cmF0aXZlIG5hbWUgb3Igc2VxdWVuY2Ug bnVtYmVyIGFzc2lnbmVkIHRvIGFuIGFjY2VzcyBjb250cm9sDQogICBydWxlLiAgVGhlIGNvbmZp Z3VyZWQgdmFsdWUgaXMgYWx3YXlzIHRoZSB2YWx1ZSB0aGF0IGlzIGJlaW5nIHVzZWQgYnkNCiAg IHRoZSBzeXN0ZW0uDQoNCiAgIEhvd2V2ZXIsIHNvbWUgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJz IGludGVyYWN0IHdpdGggcm91dGluZyBhbmQNCi0gICBvdGhlciBzaWduYWxsaW5nIHByb3RvY29s cywgc3VjaCB0aGF0IHRoZSBvcGVyYXRpb25hbCB2YWx1ZSBpbiB1c2UgYnkNCisgIG90aGVyIHNp Z25hbGluZyBwcm90b2NvbHMsIHN1Y2ggdGhhdCB0aGUgb3BlcmF0aW9uYWwgdmFsdWUgaW4gdXNl IGJ5DQogICB0aGUgc3lzdGVtIG1heSBub3QgYmUgdGhlIHNhbWUgYXMgdGhlIGNvbmZpZ3VyZWQg dmFsdWUuICBPdGhlcg0KICAgcGFyYW1ldGVycyBzcGVjaWZ5IHRoZSBkZXNpcmVkIHN0YXRlLCBi dXQgZW52aXJvbm1lbnRhbCBhbmQgb3RoZXINCiAgIGZhY3RvcnMgY2FuIGNhdXNlIHRoZSBhY3R1 YWwgc3RhdGUgdG8gYmUgZGlmZmVyZW50Lg0KDQotICAgRm9yIGV4YW1wbGUgYSAidGVtcGVyYXR1 cmUiIGNvbmZpZ3VyYXRpb24gc2V0dGluZyBvbmx5IHJlcHJlc2VudHMgdGhlDQorICAgRm9yIGV4 YW1wbGUsIGEgInRlbXBlcmF0dXJlIiBjb25maWd1cmF0aW9uIHNldHRpbmcgb25seSByZXByZXNl bnRzIHRoZQ0KICAgZGVzaXJlZCB0ZW1wZXJhdHVyZS4gIEFuIG9wZXJhdGlvbmFsIGRhdGEgcGFy YW1ldGVyIGlzIG5lZWRlZCB0aGF0DQogICByZXBvcnRzIHRoZSBhY3R1YWwgdGVtcGVyYXR1cmUg aW4gb3JkZXIgdG8gZGV0ZXJtaW5lIGlmIHRoZSBjb29saW5nDQogICBzeXN0ZW0gaXMgb3BlcmF0 aW5nIGNvcnJlY3RseS4gIFlBTkcgaGFzIG5vIG1lY2hhbmlzbSBvdGhlciB0aGFuIHRoZQ0KICAg ImRlc2NyaXB0aW9uIiBzdGF0ZW1lbnQgdG8gYXNzb2NpYXRlIHRoZSBkZXNpcmVkIHRlbXBlcmF0 dXJlIGFuZCB0aGUNCiAgIGFjdHVhbCB0ZW1wZXJhdHVyZS4NCg0KICBbRWRpdG9y4oCZcyBOb3Rl OiB3ZSBzaG91bGQgZGVmaW5lIGEg4oCYcmVsYXRlZC1jb25maWfigJkgc3RhdGVtZW50IEFTQVAh XQ0KDQogICBDYXJlZnVsIGNvbnNpZGVyYXRpb24gbmVlZHMgdG8gYmUgZ2l2ZW4gdG8gdGhlIGxv Y2F0aW9uIG9mDQogICBvcGVyYXRpb25hbCBkYXRhLiAgSXQgY2FuIGVpdGhlciBiZSBsb2NhdGVk IHdpdGhpbiB0aGUgY29uZmlndXJhdGlvbg0KICAgc3VidHJlZSBmb3Igd2hpY2ggaXQgYXBwbGll cywgb3IgaXQgY2FuIGJlIGxvY2F0ZWQgb3V0c2lkZSB0aGUNCiAgIHBhcnRpY3VsYXIgY29uZmln dXJhdGlvbiBzdWJ0cmVlLiAgUGxhY2luZyBvcGVyYXRpb25hbCBkYXRhIHdpdGhpbg0KLSAgIHRo ZSBjb25maWd1cmF0aW9uIHN1YnRyZWUgaXMgYXBwcm9wcmlhdGUgaWYgdGhlIG9wZXJhdGlvbmFs IHZhbHVlcw0KLSAgIGNhbiBvbmx5IGV4aXN0IGlmIHRoZSBjb25maWd1cmF0aW9uIGV4aXN0cy4N CisgICB0aGUgY29uZmlndXJhdGlvbiBzdWJ0cmVlIGlzIGlkZWFsLCBhcyB0aGUgYXNzb2NpYXRp b24gYmV0d2VlbiB0aGUNCisgICBjb25maWd1cmF0aW9uIGFuZCBvcGVyYXRpb25hbCBzdGF0ZSBp cyBjbGVhci4gIEhvd2V2ZXIsIGRvaW5nIHNvIG11c3QNCisgICBiZSBkb25lIHdpdGggdGhlIGtu b3dsZWRnZSB0aGF0IE5FVENPTkYgYW5kIFJFU1RDT05GIGNhbiANCisgICBjdXJyZW50bHkgb25s eSByZXR1cm4gdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGZvciBjb25maWd1cmVkIHZhbHVlcywNCisg ICBub3Qgc3lzdGVtIGdlbmVyYXRlZCB2YWx1ZXMgc3VjaCBhcyBzeXN0ZW0gY3JlYXRlZCBpbnRl cmZhY2VzIG9yDQorICAgcm91dGluZyB0YWJsZSBlbnRyaWVzLiAgIFRoaXMgaXMgYmVjYXVzZSB0 aGUgY29uZmlnIGZhbHNlIG5vZGVzIGFyZSANCisgICBkZXNjZW5kYW50cyBvZiBjb25maWcgdHJ1 ZSBub2RlcyBhbmQgaGVuY2UgY2Fubm90IGJlIHJldHVybmVkDQorICAgZm9yIG5vZGVzIHRoYXQg aGF2ZW7igJl0IGJlZW4gY29uZmlndXJlZC4gICBBdCBsZWFzdCwgdGhpcyBpcyB0aGUgY2FzZQ0K KyAgIGZvciBob3cgTkVUQ09ORiBhbmQgUkVTVENPTkYgY3VycmVudGx5IHN1cHBvcnQgcmV0dXJu aW5nDQorICAgbWl4ZWQgY29uZmlnIHRydWUgYW5kIGNvbmZpZyBmYWxzZSBjb250ZW50Lg0KDQoN Ci0gICBUaGUgImludGVyZmFjZXMiIGFuZCAiaW50ZXJmYWNlcy1zdGF0ZSIgc3VidHJlZXMgZGVm aW5lZCBpbiBbUkZDNzIyM10NCi0gICBhcmUgYW4gZXhhbXBsZSBvZiBhIGNvbXBsZXggcmVsYXRp b25zaGlwIGJldHdlZW4gY29uZmlndXJhdGlvbiBhbmQNCi0gICBvcGVyYXRpb25hbCBkYXRhLiAg VGhlIG9wZXJhdGlvbmFsIHZhbHVlcyBjYW4gaW5jbHVkZSBpbnRlcmZhY2UNCi0gICBlbnRyaWVz IHRoYXQgaGF2ZSBiZWVuIGRpc2NvdmVyZWQgb3IgaW5pdGlhbGl6ZWQgYnkgdGhlIHN5c3RlbS4g IEFuDQotICAgaW50ZXJmYWNlIG1heSBiZSBpbiB1c2UgdGhhdCBoYXMgbm90IGJlZW4gY29uZmln dXJlZCBhdCBhbGwuDQotICAgVGhlcmVmb3JlLCB0aGUgb3BlcmF0aW9uYWwgZGF0YSBmb3IgYW4g aW50ZXJmYWNlIGNhbm5vdCBiZSBsb2NhdGVkDQotICAgd2l0aGluIHRoZSBjb25maWd1cmF0aW9u IGZvciB0aGF0IHNhbWUgaW50ZXJmYWNlLg0KKyAgIEluIG9yZGVyIHRvIHN1cHBvcnQgcmV0dXJu aW5nIG9wZXJhdGlvbmFsIHN0YXRlIGZvciBzeXN0ZW0gZ2VuZXJhdGVkDQorICAgdmFsdWVzLCBz b21lIFlBTkcgbW9kdWxlIGRlc2lnbmVycyBoYXZlIGNyZWF0ZWQgYSBwYXJhbGxlbCB0b3AtbGV2 ZWwNCisgICBjb25maWcgZmFsc2UgaGllcmFyY2h5IHRoYXQgbWlycm9ycyB0aGUgc3RydWN0dXJl IG9mIHRoZSBjb25maWcgdHJ1ZSANCisgICBoaWVyYXJjaHkuICBGb3IgaW5zdGFuY2UsIHRoaXMg aXMgc2VlbiBpbiB0aGUg4oCYaW50ZXJmYWNlcy1zdGF0ZeKAmSBub2RlIGluIA0KKyAgIFtSRkM3 MjIzXS4gIEJ5IGRvaW5nIHRoaXMsIGl0IGVuYWJsZXMgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGZv ciBzeXN0ZW0NCisgICBnZW5lcmF0ZWQgdmFsdWVzIHRvIGJlIHJldHVybmVkLCBzaW5jZSB0aGVu IGFsbCB0aGUgYW5jZXN0b3Igbm9kZXMgYXJlDQorICAgY29uZmlnIGZhbHNlIGFzIHdlbGwuICBI b3dldmVyLCB0aGlzIGFwcHJvYWNoIGlzIG5vdCBpZGVhbCBhcyBpdCBsZWFkcyB0byANCisgICBu ZWVkaW5nIHRvIG1haW50YWluIGR1cGxpY2F0ZSBzdHJ1Y3R1cmVzIGFuZCBhbHNvIHJlcXVpcmVz IHRoZSB1c2Ugb2YNCisgICBkZXNjcmlwdGlvbiBzdGF0ZW1lbnRzIHRvIGRlc2NyaWJlIHRoZSBh c3NvY2lhdGlvbiBiZXR3ZWVuIHRoZSB0d28NCisgICBzdHJ1Y3R1cmVzLg0KDQorICAgVG8gYWRk cmVzcyB0aGlzIHNpdHVhdGlvbiwgdGhlIE5FVE1PRCBhbmQgTkVUQ09ORiB3b3JraW5nIGdyb3Vw cw0KKyAgIGFyZSBhdCB0aGlzIHRpbWUgaW4gdGhlIHByb2Nlc3Mgb2YgZGVmaW5pbmcgYSBob2xp c3RpYyBvcGVyYXRpb25hbCBzdGF0ZQ0KKyAgIHNvbHV0aW9uIHRoYXQgZW50YWlscyBib3RoIGEg cmV2aXNlZCBjb25jZXB0dWFsIGRhdGFzdG9yZSBtb2RlbCBhbmQNCisgICB0aGUgbmVjZXNzYXJ5 IHByb3RvY29sIGV4dGVuc2lvbnMgdG8gZW5hYmxlLCBpbiBwYXJ0LCBib3RoIE5FVENPTkYNCisg ICBhbmQgUkVTVENPTkYgdG8gYmUgYWJsZSB0byByZXR1cm4gb3BlcmF0aW9uYWwgc3RhdGUgZm9y IHN5c3RlbQ0KKyAgIGdlbmVyYXRlZCB2YWx1ZXMgdXNpbmcgdGhlIHNhbWUgY29uZmlnIHRydWUg aGllcmFyY2h5IHVzZWQgdG8gcmV0dXJuDQorICAgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGZvciBj b25maWd1cmVkIHZhbHVlcy4NCg0KKyAgIFRoaXMgYmVpbmcgdGhlIGNhc2UsIGl0IGlzIFJFQ09N TUVOREVEIHRoYXQgWUFORyBtb2R1bGUgZGVzaWduZXJzDQorICAgYWx3YXlzIG1peCBjb25maWcg dHJ1ZSBhbmQgY29uZmlnIGZhbHNlIG5vZGVzIGludG8gYSBzaW5nbGUgaGllcmFyY2h5Lg0KKyAg IFRoaXMgaXMgc28gdGhlIFlBTkcgbW9kdWxlcyB3aWxsIGJlIGluIHByb3BlciBmb3JtIGZvciB3 aGVuIHRoZQ0KKyAgIGhvbGlzdGljIG9wZXJhdGlvbmFsIHN0YXRlIHNvbHV0aW9uIGlzIGF2YWls YWJsZS4gICBUbyBhZGRyZXNzIGFueSANCisgICBpbW1lZGlhdGUgbmVlZHMgdG8gYWxzbyByZXBv cnQgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGZvciBzeXN0ZW0NCisgICBnZW5lcmF0ZWQgdmFsdWVz LCBpdCBpcyBSRUNPTU1FTkRFRCB0byBkZWZpbmUgYSBzZWNvbmQgbW9kdWxlDQorICAgdGhhdCBp bXBvcnRzIHRoZSBmaXJzdCBtb2R1bGUgYW5kIGRlZmluZXMgYSBwYXJhbGxlbCB0b3AtbGV2ZWwN CisgICBjb25maWcgZmFsc2UgaGllcmFyY2h5IHRoYXQgbWlycm9ycyB0aGUgc3RydWN0dXJlIG9m IHRoZSBjb25maWcgdHJ1ZSANCisgICBoaWVyYXJjaHkgaW4gdGhlIGZpcnN0IG1vZHVsZS4gICBU aGlzIHJlY29tbWVuZGF0aW9uIGlzIG1hZGUgdG8NCisgICBlbmFibGUgTkVUQ09ORi9SRVNUQ09O RiBzZXJ2ZXJzIHN1cHBvcnRpbmcgdGhlIGZpbmFsaXplZA0KKyAgIG9wc3RhdGUgc29sdXRpb24g dG8gY2hvb3NlIHdoZW4gdG8gc3RvcCBzdXBwb3J0aW5nIHRoZSBzZWNvbmQgDQorICAgbW9kdWxl LCBhcyBpdCB3b3VsZCB0aGVuIG9ubHkgYmUgbmVlZGVkIHRvIHN1cHBvcnQgbGVnYWN5IA0KKyAg IG9wc3RhdGUtdW5hd2FyZSBjbGllbnRzLg0KDQoNCkZPVVIgU0NFTkFSSU9TOg0KDQoxKSBhbiBv cHN0YXRlLXVuYXdhcmUgc2VydmVyIG1pZ2h0IG9ubHkgc3VwcG9ydCDigJxpZXRmLWZvb+KAnSwg YXMgaXQgaXMgZGVlbWVkIHVubmVjZXNzYXJ5IHRvIHByb3ZpZGUgdGhlIG9wZXJhdGlvbmFsIHN0 YXRlIGZvciBzeXN0ZW0tZ2VuZXJhdGVkIGJhcnMuICBBIGNsaWVudCBjYW4gZ2V0IHRoZSBvcGVy YXRpb25hbCBzdGF0ZSBmb3IganVzdCB0aGUgY29uZmlndXJlZCBiYXJzIHVzaW5nIE5FVENPTkbi gJlzIDxnZXQ+IG9yIFJFU1RDT05G4oCZcyBjb250ZW50IOKAmGFsbOKAmSBxdWVyeSBwYXJhbWV0 ZXIuDQogDQoyKSBhbiBvcHN0YXRlLXVuYXdhcmUgc2VydmVyIG1pZ2h0IHN1cHBvcnQgYm90aCDi gJxpZXRmLWZvb+KAnSBhbmQg4oCcaWV0Zi1mb28tc3RhdGXigJ0sIGFzIGl0IGlzIGRlZW1lZCBp bXBvcnRhbnQgdG8gcHJvdmlkZSB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZm9yIHN5c3RlbS1nZW5l cmF0ZWQgYmFycy4gICBTYW1lIGFzIGFib3ZlLCBhIGNsaWVudCBjYW4gZ2V0IHRoZSBvcGVyYXRp b25hbCBzdGF0ZSBmb3IganVzdCB0aGUgY29uZmlndXJlZCBiYXJzLCB3aGVuIHRhcmdldGluZyB0 aGUg4oCcaWV0Zi1mb2/igJ0gbW9kdWxlLiAgQmV0dGVyIHRob3VnaCwgYSBjbGllbnQgY2FuIGdl dCB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZm9yIGJvdGggY29uZmlndXJlZCBhbmQgc3lzdGVtLWdl bmVyYXRlZCBiYXJzIHRvZ2V0aGVyIHdoZW4gdGFyZ2V0aW5nIHRoZSDigJxpZXRmLWZvby1zdGF0 ZeKAnSBtb2R1bGUuICBBIGNsaWVudCB0aGF0IGlzIHNhdnZ5IGVub3VnaCB0byBkbyB0aGlzIHdv dWxkIG9mIGNvdXJzZSBub3Qgd2FudCB0aGUgcmVkdW5kYW50IG9wZXJhdGlvbmFsIHN0YXRlIGRh dGEgZnJvbSB0aGUgaWV0Zi1mb28gbW9kdWxlIGFuZCB0aGVyZWZvcmUgd291bGQgbGlrZWx5IG9u bHkgdXNlIE5FVENPTkbigJlzIDxnZXQtY29uZmlnPiBhbmQvb3IgUkVTVENPTkbigJlzIGNvbnRl bnQg4oCYY29uZmln4oCZIHF1ZXJ5IHBhcmFtZXRlciB3aGVuIHRhcmdldGluZyB0aGUg4oCcaWV0 Zi1mb2/igJ0gbW9kdWxlLg0KDQozKSBhbiBvcHN0YXRlLWF3YXJlIHNlcnZlciBtaWdodCBvbmx5 IHN1cHBvcnQg4oCcaWV0Zi1mb2/igJ0sIGFzIGl0IGNhbiBwcm92aWRlIHRoZSBvcGVyYXRpb25h bCBzdGF0ZSBmb3IgYm90aCBjb25maWd1cmVkIGFuZCBzeXN0ZW0tZ2VuZXJhdGVkIGJhcnMgdXNp bmcgcHJvdG9jb2wgbWVjaGFuaXNtcyBkZWZpbmVkIGJ5IHRoZSBob2xpc3RpYyBvcHN0YXRlIHNv bHV0aW9uIChlLmcuLCB2aWEgYW4g4oCcb3BlcmF0aW9uYWzigJ0gZGF0YXN0b3JlKSwgYW5kIGl0 IGRvZXNu4oCZdCBjYXJlIGFib3V0IGVuYWJsaW5nIGxlZ2FjeSBvcHN0YXRlLXVuYXdhcmUgY2xp ZW50cyB0byBiZSBhYmxlIHRvIG9idGFpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUgZm9yIHRoZSBz eXN0ZW0gZ2VuZXJhdGVkIGJhcnMuDQoNCjQpIGFuIG9wc3RhdGUtYXdhcmUgc2VydmVyIG1pZ2h0 IHN1cHBvcnQgYm90aCDigJxpZXRmLWZvb+KAnSBhbmQg4oCcaWV0Zi1mb28tc3RhdGXigJ0sIHNv IHRoYXQgaXQgY2FuIHByb3ZpZGUgdGhlIG9wZXJhdGlvbmFsIHN0YXRlIGZvciBib3RoIGNvbmZp Z3VyZWQgYW5kIHN5c3RlbS1nZW5lcmF0ZWQgYmFycyB0byBib3RoIG9wc3RhdGUtYXdhcmUgYW5k IG9wc3RhdGUtdW5hd2FyZSBjbGllbnRzLiAgVGhpcyBpcyBob3BlZnVsbHkgYSB0ZW1wb3Jhcnkg Y29uZGl0aW9uIGFzIGV2ZW50dWFsbHkgdGhlIGNsaWVudHMgd2lsbCBiZSB1cGdyYWRlZCB0byBi ZSBvcHN0YXRlLWF3YXJlIGFuZCB0aGVuIHRoZSB2ZW5kb3IgY2FuIGRlcHJlY2F0ZSBzdXBwb3J0 IGZvciB0aGUgaWV0Zi1mb28tc3RhdGUgbW9kdWxlLg0KDQoNCg0KV0hZIElNUE9SVD8gICBUaGUg dGV4dCBhYm92ZSBpbmNsdWRlcyB0aGUgc3RhdGVtZW50IOKAnGl0IGlzIFJFQ09NTUVOREVEIHRv IGRlZmluZSBhIHNlY29uZCBtb2R1bGUgdGhhdCBpbXBvcnRzIHRoZSBmaXJzdCBtb2R1bGXigJ0u ICBUZWNobmljYWxseSwgdGhlcmUgaXNu4oCZdCBhIG5lZWQgZm9yIHRoZSBpbXBvcnQgYXMgb2Yg eWV0LCBidXQgSeKAmW0gdmVyeSBtdWNoIHRoaW5raW5nIHRoYXQgd2Ugc2hvdWxkICpxdWlja2x5 KiBkZWZpbmUgYSBZQU5HIHN0YXRlbWVudCBjYWxsZWQg4oCccmVsYXRlZC1jb25maWfigJ0gdGhh dCBhbGxvd3MgdGhlIGNsaWVudCB0byBwcm9ncmFtbWF0aWNhbGx5IHJlbGF0ZWQgd2hpY2ggY29u ZmlnIHRydWUgbm9kZXMgaW4gdGhlIGZpcnN0IG1vZHVsZSBtaWdodCBhcmUgYXNzb2NpYXRlZCB0 byB0aGUgY29uZmlnIGZhbHNlIG5vZGVzIGluIHRoZSBzZWNvbmQgbW9kdWxlLiAgT2J2aW91c2x5 LCB0aGlzIHdvdWxkIG9ubHkgbWFrZSB0aGUgYXNzb2NpYXRpb24gZm9yIGNvbmZpZ3VyZWQgdmFs dWVzLCBhbmQgdGhlIGNsaWVudCBjb3VsZCBhc3N1bWUgdGhhdCBhbnkga2V5LW1pc3NlcyBhcmUg dGhlIHJlc3VsdCBvZiB0aGUgdGhhdCBvcGVyYXRpb25hbCBzdGF0ZSBiZWluZyBmb3IgYSBzeXN0 ZW0tZ2VuZXJhdGVkIHZhbHVlLiAgVGhlIGFzc29jaWF0aW9uIGhhcyB0byBiZSBpbiB0aGF0IGRp cmVjdGlvbiBiZWNhdXNlIGNvbmZpZyBmYWxzZSBub2RlcyBjYW4gcG9pbnQgdG8gY29uZmlnIHRy dWUgbm9kZXMsIGJ1dCBub3QgdmlzYSB2ZXJzYS4NCg0KDQoNCg0KPEVYQU1QTEU+DQoNCkFzc3Vt ZSB3ZSBoYXZlIG1vZHVsZSDigJxpZXRmLWZvb+KAnSBhcyBmb2xsb3dzOg0KIA0KbW9kdWxlIGll dGYtZm9vIHsNCiAgbmFtZXNwYWNlIOKAnGZvby1uYW1lc3BhY2XigJ07DQogIGNvbnRhaW5lciBm b28gew0KICAgIGxpc3QgYmFyIHsNCiAgICAgIGtleSBhOw0KICAgICAgbGVhZiBhIHsNCiAgICAg ICAgdHlwZSBzdHJpbmc7DQogICAgICB9DQogICAgICBsZWFmIGIgew0KICAgICAgICAgdHlwZSBp bnQ4Ow0KICAgICAgICAgY29uZmlnIGZhbHNlOw0KICAgICAgfQ0KICAgfQ0KICB9DQp9DQogDQp3 aGVyZWJ5IGl04oCZcyBwb3NzaWJsZSB0aGF0IHRoZSBzeXN0ZW0gbWF5IGdlbmVyYXRlIHNvbWUg YmFycyBhcyB3ZWxsLiAgVG8gYWRkcmVzcyB0aGlzLCB3ZSBjcmVhdGUgYSBzZWNvbmQgbW9kdWxl IOKAnGlldGYtZm9vLXN0YXRl4oCdIChpZGVhbGx5IHVzaW5nIHRvb2wpIHRoYXQgZGlzY2FyZHMg YXJlIHRoZSBjb25maWcgdHJ1ZSBsZWFmcyBhbmQgc2V0cyB0aGUgZW50aXJlIHRyZWUgdG8gY29u ZmlnIGZhbHNlLiAgVGhlIHJlc3VsdGluZyBtb2R1bGUgZm9sbG93czoNCiANCm1vZHVsZSBpZXRm LWZvby1zdGF0ZSB7DQogIG5hbWVzcGFjZSDigJxmb28tc3RhdGUtbmFtZXNwYWNl4oCdOw0KICBp bXBvcnQgaWV0Zi1mb28geyBwcmVmaXgg4oCcZuKAnTsgfQ0KICBjb250YWluZXIgZm9vLXN0YXRl IHsNCiAgICBjb25maWcgZmFsc2U7ICAgIDwtLSBldmVyeXRoaW5nIGJlbG93IGlzIGNvbmZpZyBm YWxzZQ0KICAgIGxpc3QgYmFyIHsNCiAgICAgIGtleSBhOw0KICAgICAgcmVsYXRlZC1jb25maWcg eyAgICAgIDwtLSBjb25maWcgZmFsc2UgcG9pbnQgdG8gY29uZmlnIHRydWUgKG9ubHkgcHJlc2Vu dCBmb3IgKmNvbmZpZ3VyZWQqIGJhcnMpDQogICAgICAgICAgcGF0aCDigJwvZjpmb28vZjpiYXIv Zjph4oCdDQogICAgICB9DQogICAgICBsZWFmIGEgeyAgICA8LS0gdGhpcyDigJxjb25maWcgdHJ1 ZeKAnSBsZWFmIGlzIGtlcHQgb25seSBiZWNhdXNlIGl04oCZcyB0aGUga2V5IChidXQgbm93IGl0 4oCZcyBjb25maWcgZmFsc2UpDQogICAgICAgIHR5cGUgc3RyaW5nOw0KICAgICAgfQ0KICAgICAg bGVhZiBiIHsNCiAgICAgICAgIHR5cGUgaW50ODsNCiAgICAgICAgIGNvbmZpZyBmYWxzZTsNCiAg ICAgIH0NCiAgIH0NCiAgfQ0KfQ0KPC9FWEFNUExFPg0KDQoNCg0KDQoNCjxTTklQIC0gSSBkaWRu 4oCZdCB0cnkgdG8gcmV3cml0ZSBhbnkgb2YgdGhlIGJlbG93IHN0dWZmIGZyb20gU2VjdGlvbiA1 LjIzLiBTb21lIG9mIGl0IHdvdWxkIGJlIG9ic29sZXRlIGZyb20gdGhlIHRleHQgYWJvdmUsIGJ1 dCBvdGhlciBwYXJ0cyBtYXkgc3RpbGwgYmUgdXNlZnVsLi4uPg0KDQogICBTb21ldGltZXMgdGhl IGNvbmZpZ3VyZWQgdmFsdWUgcmVwcmVzZW50cyBzb21lIHNvcnQgb2YgcHJvY2VkdXJlIHRvDQog ICBiZSBmb2xsb3dlZCwgaW4gd2hpY2ggdGhlIHN5c3RlbSB3aWxsIHNlbGVjdCBhbiBhY3R1YWwg dmFsdWUsIGJhc2VkDQogICBvbiBwcm90b2NvbCBuZWdvdGlhdGlvbi4NCg0KICAgICAgbGVhZiBk dXBsZXgtYWRtaW4tbW9kZSB7DQogICAgICAgIHR5cGUgZW51bWVyYXRpb24gew0KICAgICAgICAg IGVudW0gYXV0bzsNCiAgICAgICAgICBlbnVtIGhhbGY7DQogICAgICAgICAgZW51bSBmdWxsOw0K ICAgICAgICB9DQogICAgICB9DQoNCiAgICAgIGxlYWYgZHVwbGV4LW9wZXItbW9kZSB7DQogICAg ICAgIGNvbmZpZyBmYWxzZTsNCiAgICAgICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICAgICAg ZW51bSBoYWxmOw0KICAgICAgICAgIGVudW0gZnVsbDsNCiAgICAgICAgfQ0KICAgICAgfQ0KDQog ICBGb3IgZXhhbXBsZSBhICJkdXBsZXgiIG1vZGUgY29uZmlndXJhdGlvbiBtYXkgYmUgImF1dG8i IHRvIGF1dG8tDQogICBuZWdvdGlhdGUgdGhlIGFjdHVhbCB2YWx1ZSB0byBiZSB1c2VkLiAgVGhl IG9wZXJhdGlvbmFsIHBhcmFtZXRlcg0KICAgd2lsbCBuZXZlciBjb250YWluIHRoZSB2YWx1ZSAi YXV0byIuICBJdCB3aWxsIGFsd2F5cyBjb250YWluIHRoZQ0KICAgcmVzdWx0IG9mIHRoZSBhdXRv LW5lZ290aWF0aW9uLCBzdWNoIGFzICJoYWxmIiBvciAiZnVsbCIuICBUaGlzIGlzDQogICBqdXN0 IG9uZSB3YXkgaW4gd2hpY2ggdGhlIGNvbmZpZ3VyYXRpb24gZGF0YSBtb2RlbCBpcyBub3QgZXhh Y3RseSB0aGUNCiAgIHNhbWUgYXMgdGhlIG9wZXJhdGlvbmFsIGRhdGEgbW9kZWwuICBBbm90aGVy IGlzIGlmIHRoZSBkZXRhaWxlZA0KICAgcHJvcGVydGllcyBvZiB0aGUgZGF0YSBhcmUgZGlmZmVy ZW50IGZvciBjb25maWd1cmVkIHZzLiBsZWFybmVkDQogICBlbnRyaWVzLg0KDQogICBJZiBhbGwg dGhlIGRhdGEgbW9kZWwgcHJvcGVydGllcyBhcmUgYWxpZ25lZCBiZXR3ZWVuIGNvbmZpZ3VyYXRp b24NCiAgIGFuZCBvcGVyYXRpb25hbCBkYXRhLCB0aGVuIGl0IGNhbiBiZSB1c2VmdWwgdG8gZGVm aW5lIHRoZQ0KICAgY29uZmlndXJhdGlvbiBwYXJhbWV0ZXJzIHdpdGhpbiBhIGdyb3VwaW5nLCBh bmQgdGhlbiByZXBsaWNhdGUgdGhhdA0KICAgZ3JvdXBpbmcgd2l0aGluIHRoZSBvcGVyYXRpb25h bCBkYXRhIHBvcnRpb24gb2YgdGhlIGRhdGEgbW9kZWwuDQoNCiAgICAgICBncm91cGluZyBwYXJt cyB7DQogICAgICAgICAgLy8gZG8gbm90IHVzZSBjb25maWctc3RtdCBpbiBhbnkgb2YgdGhlIG5v ZGVzDQogICAgICAgICAgLy8gcGxhY2VkIGluIHRoaXMgZ3JvdXBpbmcNCiAgICAgICB9DQoNCiAg ICAgICBjb250YWluZXIgZm9vIHsNCiAgICAgICAgIHVzZXMgcGFybXM7ICAvLyB0aGVzZSBhcmUg YWxsIGNvbmZpZz10cnVlIGJ5IGRlZmF1bHQNCiAgICAgICAgIHN0YXRlIHsNCiAgICAgICAgICAg Y29uZmlnIGZhbHNlOyAgLy8gb25seSBleGlzdHMgaWYgZm9vIGNvbmZpZyBleGlzdHMNCiAgICAg ICAgICAgdXNlcyBwYXJtczsNCiAgICAgICAgIH0NCiAgICAgICB9DQoNCiAgIE5vdGUgdGhhdCB0 aGlzIG1lY2hhbmlzbSBjYW4gYWxzbyBiZSB1c2VkIGlmIHRoZSBjb25maWd1cmF0aW9uIGFuZA0K ICAgb3BlcmF0aW9uYWwgZGF0YSBhcmUgaW4gc2VwYXJhdGUgc3ViLXRyZWVzOg0KDQogICAgICAg Y29udGFpbmVyIGJhciB7IC8vIGJhciBjb25maWcgY2FuIGV4aXN0IHdpdGhvdXQgYmFyLXN0YXRl DQogICAgICAgICBjb25maWcgdHJ1ZTsNCiAgICAgICAgIHVzZXMgcGFybXM7DQogICAgICAgfQ0K DQogICAgICAgY29udGFpbmVyIGJhci1zdGF0ZSB7ICAvLyBiYXItc3RhdGUgY2FuIGV4aXN0IHdp dGhvdXQgYmFyDQogICAgICAgICBjb25maWcgZmFsc2U7DQogICAgICAgICB1c2VzIHBhcm1zOw0K ICAgICAgIH0NCg0KICAgVGhlIG5lZWQgdG8gcmVwbGljYXRlIG9iamVjdHMgb3IgZGVmaW5lIGRp ZmZlcmVudCBvcGVyYXRpb25hbCBkYXRhDQogICBvYmplY3RzIGRlcGVuZHMgb24gdGhlIGRhdGEg bW9kZWwuICBJdCBpcyBub3QgcG9zc2libGUgdG8gZGVmaW5lIG9uZQ0KICAgYXBwcm9hY2ggdGhh dCB3aWxsIGJlIG9wdGltYWwgZm9yIGFsbCBkYXRhIG1vZGVscy4gIERlc2lnbmVycyBTSE9VTEQN CiAgIGRlc2NyaWJlIHRoZSByZWxhdGlvbnNoaXAgaW4gZGV0YWlsIGJldHdlZW4gY29uZmlndXJh dGlvbiBvYmplY3RzIGFuZA0KICAgYW55IGFzc29jaWF0ZWQgb3BlcmF0aW9uYWwgZGF0YSBvYmpl Y3RzLiAgVGhlICJkZXNjcmlwdGlvbiINCiAgIHN0YXRlbWVudHMgZm9yIGJvdGggdGhlIGNvbmZp Z3VyYXRpb24gYW5kIHRoZSBvcGVyYXRpb25hbCBkYXRhIFNIT1VMRA0KICAgYmUgdXNlZCBmb3Ig dGhpcyBwdXJwb3NlLg0KDQo8L1NOSVA+DQoNCg0KVGhhbmtzLA0KS2VudA0KDQoNCg== From nobody Mon Aug 1 21:27: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 C8A7B12D0C2 for ; Mon, 1 Aug 2016 21:27:02 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.186 X-Spam-Level: X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] 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 aciTiQ1bTpXs for ; Mon, 1 Aug 2016 21:27:01 -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 D62F712D090 for ; Mon, 1 Aug 2016 21:26:59 -0700 (PDT) Received: from [2602:4b:a27f:3000:9154:2d9b:2571:83ec] by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bURHq-0005Zo-0i; Tue, 02 Aug 2016 05:26:38 +0100 Content-Type: multipart/alternative; boundary="Apple-Mail=_A968F6F0-46B4-45C1-B628-DC5FC9E7250D" Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) From: Rob Shakir In-Reply-To: <20160729133257.GA3317@elstar.local> Date: Mon, 1 Aug 2016 22:26:22 -0600 Message-Id: <6060785D-B819-4E73-8ABB-B0246754BE35@rob.sh> References: <20160729133257.GA3317@elstar.local> To: Juergen Schoenwaelder X-Mailer: Apple Mail (2.3124) Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] derived-from-or-self leads to circular import X-BeenThere: netmod@ietf.org X-Mailman-Version: 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, 02 Aug 2016 04:27:03 -0000 --Apple-Mail=_A968F6F0-46B4-45C1-B628-DC5FC9E7250D Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii > On Jul 29, 2016, at 07:32, Juergen Schoenwaelder = wrote: >=20 > I think moving the definition of entity-physical-class into > iana-entity makes sense. Perhaps this is generally a good pattern to > follow for base identities for which IANA maintains derived > identities. The required import should not be a problem; the > ENTITY-MIB also imports from IANA-ENTITY-MIB. I would be supportive of changes that make IANA maintained registries = self-contained. It seems to me that this would reduce overall overlap = between modules. For example, right now, iana-if-type uses ietf-interfaces to define = interface-type. This means that third-party modules cannot exploit the = IANA registry without also including the IETF module. This does not seem = ideal if one simply wants to ensure that the registry can be used. r.= --Apple-Mail=_A968F6F0-46B4-45C1-B628-DC5FC9E7250D Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii
On Jul 29, 2016, at 07:32, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

I think moving the definition = of entity-physical-class into
iana-entity makes sense. = Perhaps this is generally a good pattern to
follow for = base identities for which IANA maintains derived
identities.=  The required import should not be a problem; the
ENTITY-MIB also imports from IANA-ENTITY-MIB.

I= would be supportive of changes that make IANA maintained registries = self-contained. It seems to me that this would reduce overall overlap = between modules.

For example, right now, iana-if-type uses = ietf-interfaces to define interface-type. This means that third-party = modules cannot exploit the IANA registry without also including the IETF = module. This does not seem ideal if one simply wants to ensure that the = registry can be used.

r.
= --Apple-Mail=_A968F6F0-46B4-45C1-B628-DC5FC9E7250D-- From nobody Tue Aug 2 01:26: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 3102812B035 for ; Tue, 2 Aug 2016 01:26:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.497 X-Spam-Level: X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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 6BMV0dq6zu75 for ; Tue, 2 Aug 2016 01:26:27 -0700 (PDT) Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0313312B004 for ; Tue, 2 Aug 2016 01:26:26 -0700 (PDT) X-AuditID: c1b4fb25-8bfff70000001071-f0-57a05930e0a7 Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by (Symantec Mail Security) with SMTP id 84.CC.04209.03950A75; Tue, 2 Aug 2016 10:26:24 +0200 (CEST) Received: from [159.107.198.46] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.301.0; Tue, 2 Aug 2016 10:26:23 +0200 To: Ladislav Lhotka , Andy Bierman References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com> <6C7B9426-DB44-40B0-9AEE-1A7A0D51D1D0@nic.cz> <20160728145153.GC1752@elstar.local> <1f3c1297-da13-9fdb-fa8e-b9b8141d82a0@ericsson.com> From: Balazs Lengyel Message-ID: Date: Tue, 2 Aug 2016 10:26:23 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/html; charset="windows-1252" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrGLMWRmVeSWpSXmKPExsUyM2K7q65B5IJwg/XbrS0eHJnFbnF1409G iwur5rJZzL/YyOrA4rFkyU8mjw0HPD02Xb7D6NHSf5ElgCWKyyYlNSezLLVI3y6BK+NU/3zW ggt6FS+3ujYw3lLuYuTkkBAwkXh9+AJjFyMXh5DAekaJ6U+2skE4qxklVnfdYQOpEhbQk7j3 ZR8TiC0i4CbRvfMKE0TRS2aJZTdXMncxcnAwC1RJbL6pAlLDJmAkMbX/PAuIzStgL3F56UGw OSwCKhJXfmxhBSkXFYiRWN+XAFEiKHFy5hOwck4BK4m3k+ezg9jMAvoS1+/cZ4Ww5SWat85m BrGFBDQkHl74yzqBUWAWkvZZSFpmIWlZwMi8ilG0OLU4KTfdyFgvtSgzubg4P08vL7VkEyMw dA9u+a26g/HyG8dDjAIcjEo8vAp988OFWBPLiitzDzFKcDArifB+Cl0QLsSbklhZlVqUH19U mpNafIhRmoNFSZzX/6ViuJBAemJJanZqakFqEUyWiYNTqoHRYhuP8d4SXb27d383cD/uuPmx aJrdkrl/Dqze8C7i4wElyWP9MsG2/RM4VLJ1nx7J2L50pXSidkCSdu3Erd05MjtXe7Bc7D06 RS5cdlOvcK40l4o/U+PcrHVCtd52hyzc5orPyEwKv+5Ss6Y++tvTgBofC8fSOKWqhdM3TV2n 5ZqW7DvfvlqJpTgj0VCLuag4EQAvFY6tWQIAAA== Archived-At: Cc: "netmod@ietf.org" Subject: Re: [netmod] Design-Time 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, 02 Aug 2016 08:26:29 -0000

Hello Lada,

I see 2 statements in your mail:

"Yes, but a client that doesn't understand them can still safely work with an NACM-aware server."
IMHO simply ignoring security information is not acceptable in any way. So the nacm extensions are not "optional" either.

"The regular client doesn't know the mounted parts of the data model, so no automation is possible for this data."
That to me says: a client who doesn't support schema-mount will not really understand schema-mount. True, but that is valid for any schema-mount solution, so if we want schema mount we must live with it.

Do you have any better alternative than extensions? (For me run-time data or plain English text are worse.)

Balazs


On 2016-08-01 17:11, Ladislav Lhotka wrote:

      

        
On 01 Aug 2016, at 16:09, Andy Bierman <andy@yumaworks.com> wrote:



On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka <lhotka@nic.cz> wrote:
Balazs Lengyel <balazs.lengyel@ericsson.com> writes:



        

          
Hello,

As I understood Andy, it was already agreed that if you advertise
support for a model that defines extensions you MUST support those
extensions. So you effectively advertise support for those extensions.


        

        
OK, so let's say a server advertises "ietf-system" (that imports
"ietf-netconf-acm") with conformance-type "implement" and
"ietf-netconf-acm" with conformance-type "import". Does the server
support "nacm:default-deny-*" extensions or not?


The server is only claiming conformance on the modules that it implements.
The YANG conformance model has issues.  This is not news.


      

      
My point was that "advertise" isn't sufficient.



      

        
 
Moreover, clients don't advertise any modules.


not sure why this matters


      

      
If the server can learn what extensions this client supports, it could adjust its behaviour (probably impossible for something like schema mount though).



      

        
 


        

          
As an example if you claim support for nacm, you MUST support its
extensions.


        

        
NACM is different in that the nacm:default-deny-* extensions just give
auxiliary information - they help NACM-aware clients avoid sending
requests that result in access-denied errors.


they are quite clear wrt/ how a NACM implementation must treat the extensions.


      

      
Yes, but a client that doesn't understand them can still safely work with an NACM-aware server.



      

        
 
In contrast, a client that doesn't support schema mount cannot be used
with a server that does.


why not?

   anydata mount-point {
      mount:extension1;
      mount:extension2;
   }

A regular client will see an anydata node with schema-less child nodes.
A mount-aware client will see a mount-point and know how to determine
the schema for the child nodes of the mount-point.


      

      
The regular client doesn't know the mounted parts of the data model, so no automation is possible for this data.

Lada 



      

        

Lada

Andy
 



        

          
Balazs


On 2016-07-29 15:31, Ladislav Lhotka wrote:


          

            
For this approach to work, we would need to change the character of
extensions, in particular:

- an implementation should be able to signal which extensions are
   supported,

- extensions that change the data model need to be labelled as mandatory
   to support.


          

          
--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com



        

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







    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Tue Aug  2 04:12: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 2544912B049 for ; Tue,  2 Aug 2016 04:12:41 -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 iHfhWDqD__QU for ; Tue,  2 Aug 2016 04:12:38 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1DE1212D10F for ; Tue,  2 Aug 2016 04:12:37 -0700 (PDT)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id C2E2A1CC00A1; Tue,  2 Aug 2016 13:12:45 +0200 (CEST)
From: Ladislav Lhotka 
To: Balazs Lengyel , Andy Bierman 
In-Reply-To: 
References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com>   <6C7B9426-DB44-40B0-9AEE-1A7A0D51D1D0@nic.cz> <20160728145153.GC1752@elstar.local>  <1f3c1297-da13-9fdb-fa8e-b9b8141d82a0@ericsson.com>    
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 02 Aug 2016 13:12:34 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Design-Time 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, 02 Aug 2016 11:12:41 -0000

Balazs Lengyel  writes:

> Hello Lada,
>
> I see 2 statements in your mail:
>
> "Yes, but a client that doesn't understand them can still safely work
> with an NACM-aware server." 
> IMHO simply ignoring security information is not acceptable in any
> way. So the nacm extensions are not "optional" either.

Not really, there are no security implications because access control
policies are enforced at the server side. The client can use this
information for avoiding requests that result in access-denied error, or
perhaps reflect it in the user interface. 

>
> "The regular client doesn't know the mounted parts of the data model,
> so no automation is possible for this data."
> That to me says: a client who doesn't support schema-mount will not
> really understand schema-mount. True, but that is valid for any
> schema-mount solution, so if we want schema mount we must live with
> it.

Yes, but if the YANG version is bumped, the client can immediately see
that it is not compatible, and disconnect. In contrast, sec. 6.3.1 says
that an extension "MAY be ignored in its entirety". According to the
RFC 2119 semantics, doing so should not affect interoperability, which
is clearly not the case here.

>
> Do you have any better alternative than extensions? (For me run-time
> data or plain English text are worse.)

For me too. As I said, I would prefer some kind of meta-schema approach,
such as extending YANG library.

Lada

>
> Balazs
>
> On 2016-08-01 17:11, Ladislav Lhotka wrote:
>
>     
>     
>         On 01 Aug 2016, at 16:09, Andy Bierman  wrote:
>
>
>
> On Mon, Aug 1, 2016 at 6:45 AM, Ladislav Lhotka  wrote:
> Balazs Lengyel  writes:
>
>         
>             Hello,
>
> As I understood Andy, it was already agreed that if you advertise
> support for a model that defines extensions you MUST support those
> extensions. So you effectively advertise support for those extensions.
>
>         
> OK, so let's say a server advertises "ietf-system" (that imports
> "ietf-netconf-acm") with conformance-type "implement" and
> "ietf-netconf-acm" with conformance-type "import". Does the server
> support "nacm:default-deny-*" extensions or not?
>
>
> The server is only claiming conformance on the modules that it implements.
> The YANG conformance model has issues.  This is not news.
>
>     
> My point was that "advertise" isn't sufficient.
>
>     
>         
>  
> Moreover, clients don't advertise any modules.
>
>
> not sure why this matters
>
>     
> If the server can learn what extensions this client supports, it could adjust its behaviour (probably impossible for something like schema mount though).
>
>     
>         
>  
>         
>             As an example if you claim support for nacm, you MUST support its
> extensions.
>
>         
> NACM is different in that the nacm:default-deny-* extensions just give
> auxiliary information - they help NACM-aware clients avoid sending
> requests that result in access-denied errors.
>
>
> they are quite clear wrt/ how a NACM implementation must treat the extensions.
>
>     
> Yes, but a client that doesn't understand them can still safely work with an NACM-aware server.
>
>     
>         
>  
> In contrast, a client that doesn't support schema mount cannot be used
> with a server that does.
>
>
> why not?
>
>    anydata mount-point {
>       mount:extension1;
>       mount:extension2;
>    }
>
> A regular client will see an anydata node with schema-less child nodes.
> A mount-aware client will see a mount-point and know how to determine
> the schema for the child nodes of the mount-point.
>
>     
> The regular client doesn't know the mounted parts of the data model, so no automation is possible for this data.
>
> Lada 
>
>     
>         
>
> Lada
>
> Andy
>  
>
>         
>             
> Balazs
>
>
> On 2016-07-29 15:31, Ladislav Lhotka wrote:
>
>             
>                 For this approach to work, we would need to change the character of
> extensions, in particular:
>
> - an implementation should be able to signal which extensions are
>    supported,
>
> - extensions that change the data model need to be labelled as mandatory
>    to support.
>
>             
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
>         
> --
> 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
>
>
>
>
>
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 

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


From nobody Tue Aug  2 05:42: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 A1F3C12D5AB for ; Tue,  2 Aug 2016 05:42:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level: 
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 zRJV-5npKlD0 for ; Tue,  2 Aug 2016 05:42:50 -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 99C4912D591 for ; Tue,  2 Aug 2016 05:42:50 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 10B6093D; Tue,  2 Aug 2016 14:42:49 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id yzTKdliXT3oT; Tue,  2 Aug 2016 14:42:46 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue,  2 Aug 2016 14:42:48 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0A2EB20085; Tue,  2 Aug 2016 14:42:48 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BdklyLoDAMKd; Tue,  2 Aug 2016 14:42:46 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4861C20080; Tue,  2 Aug 2016 14:42:46 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7529C3C0AFEA; Tue,  2 Aug 2016 14:42:42 +0200 (CEST)
Date: Tue, 2 Aug 2016 14:42:42 +0200
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Message-ID: <20160802124242.GB27358@elstar.local>
Mail-Followup-To: Ladislav Lhotka , Balazs Lengyel , Andy Bierman , "netmod@ietf.org" 
References:  <6C7B9426-DB44-40B0-9AEE-1A7A0D51D1D0@nic.cz> <20160728145153.GC1752@elstar.local>  <1f3c1297-da13-9fdb-fa8e-b9b8141d82a0@ericsson.com>     
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Design-Time schema 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: Tue, 02 Aug 2016 12:42:52 -0000

On Tue, Aug 02, 2016 at 01:12:34PM +0200, Ladislav Lhotka wrote:
> 
> Yes, but if the YANG version is bumped, the client can immediately see
> that it is not compatible, and disconnect. In contrast, sec. 6.3.1 says
> that an extension "MAY be ignored in its entirety". According to the
> RFC 2119 semantics, doing so should not affect interoperability, which
> is clearly not the case here.
>

This is apparently where views substantially differ; I do not consider
it an interoperability failure if an old client does not understand a
part of a datamodel of an updated server that the old client is not
dealing with. For me, interoperability means that a server can upgrade
while old clients continue to function as they did before. For me,
interoperability does not mean that server and clients always have to
be updated at the same time and it does not mean that a client needs
to understand and support the entire set of datamodels exposed by a
server.

/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 Aug  2 09:29: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 B456812D7EE for ; Tue,  2 Aug 2016 09:29:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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 hh4kejKh5uht for ; Tue,  2 Aug 2016 09:29:50 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C30912D7B5 for ; Tue,  2 Aug 2016 09:29:49 -0700 (PDT)
X-AuditID: c1b4fb30-ad3ff700000009f9-ee-57a0ca7bcf01
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by  (Symantec Mail Security) with SMTP id 05.8B.02553.B7AC0A75; Tue,  2 Aug 2016 18:29:48 +0200 (CEST)
Received: from [159.107.198.46] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.77) with Microsoft SMTP Server id 14.3.301.0; Tue, 2 Aug 2016 18:29:46 +0200
To: Robert Wilton , Andy Bierman , Ladislav Lhotka , netmod WG 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local>
From: Balazs Lengyel 
Message-ID: <154e783b-9817-9d74-4af6-23f403db3fb2@ericsson.com>
Date: Tue, 2 Aug 2016 18:29:46 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160729163220.GA3579@elstar.local>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrHLMWRmVeSWpSXmKPExsUyM2K7t27NqQXhBnNuc1s8ODKL3eLCqrls FvMvNrJanDjXx+zA4jHl90ZWjyVLfjJ5bLp8h9Gjpf8iSwBLFJdNSmpOZllqkb5dAlfG+78n WQrWyVXMuXePvYHxo1gXIyeHhICJxOO+faxdjFwcQgLrGSXevVvHAuGsZpS43TePBaRKWCBK 4tq1V8wgCRGBDkaJQz+2MUNUTWGRWPp2OxNIFZuAkcTU/vNgHbwC9hJfn18Bs1kEVCSuTjjB 1sXIwSEqECOxvi8BokRQ4uTMJ2AlnAKGEnu73jCC2MwC+hLX79xnhbDlJZq3zmYGsYUENCQe XvjLOoGRfxaS9llIWmYhaVnAyLyKUbQ4tTgpN93ISC+1KDO5uDg/Ty8vtWQTIzBUD275bbCD 8eVzx0OMAhyMSjy8Cn3zw4VYE8uKK3MPMUpwMCuJ8EbtXRAuxJuSWFmVWpQfX1Sak1p8iFGa g0VJnNf/pWK4kEB6YklqdmpqQWoRTJaJg1OqgbFPR+oS+xutWXztl6oWv2pPO/jwgY+CzF2r vqQtWr/OFEVdCy67e/Omor9MstvFmOeah6Lva4gen9dxMfL5Vubo8Ms7l80VPit4Ru5ByQWH 7Wt0VzQXzRWLuec/mckgv40p99kv/pr5W6I+LGBvNO9O6pnuwcDGNMWyb+O/3NnKXPO7Xq28 1aDEUpyRaKjFXFScCABSsbHcUQIAAA==
Archived-At: 
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Aug 2016 16:29:52 -0000


  
    
  
  
    
Hello,

    
Later I will try to provide a text proposal as well, but some
      points:

    
    
      
  • I prefer a tight definition so even if we allow both 1) and
        2) we should state that other combinations e.g. trees spliting
        close to the leaves or a mix of 1) and 2) in the same module are
        not allowed (VERYYYY STRONGLY discouraged). 
    
      
    • 
      
  • In one of the earlier mails there was a a statement: if we
        have foo and foo-state trees, the containers/list/key-leafs
        SHOULD be the same in the two. The structures of the two trees
        SHOULD not just be si,i;ar, they should be the same.
    • 
    

    
This way you could look at the root objects of the module and
      immediately know what is the situation.

    
regards Balazs

    

    


    

    

    
On 2016-07-29 18:32, Juergen
      Schoenwaelder wrote:

    

    

      
On Fri, Jul 29, 2016 at 04:35:05PM +0100, Robert Wilton wrote:
 


      

        
I would like to know what should the common approach for IETF standard
models be?  E.g. is it one of the following:

1) All config false leaves for foo must go under /foo-state.


      

      
I think if you have /foo-state, then this is a logical consequence. Do
we have any data models that have a /foo-state tree and config false
nodes under the /foo tree?



      

        
2) All config false leaves for foo must go under /foo


      

      
This apparently does not make sense in certain circumstances until we
have a revised datastore solution defined and implemented that may
allow this to work in all situations.



      

        
3) All config false leaves go under /foo where possible, or /foo-state
otherwise (e.g. for restconf-monitoring).


      

      
I think it should be fairly easy for a tool to figure out whether a
/foo tree is a pure config true tree or whether there are any config
false leafs as well and /foo is a mixed tree. Things are fairly easy
as long as people split at the root if they split.



      

        
4) Config false leaves go wherever the model writer decides is appropriate.


      

      
I think we will have to live for a while with both the (i) /foo (pure
config true tree) and /foo-state (pure config false tree) split at the
root approach and the (ii) /foo (mixed config true and false tree)
approach. We need to document the trade-offs between the two so that
module writers can make an informed decision. Whether a module uses
(i) or (ii) should be possible to determine by inspecting the
properties of the schema tree, in particular if module writers follow
the guideline to use consistent names and structure in the /foo and
/foo-state approach wherever possible.

I think we also wanted to strongly discourage models where (iii) the
trees split at the leaves or very close to the leaves.

/js



    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Tue Aug  2 09:37:28 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 AB4CA12D803 for ; Tue,  2 Aug 2016 09:37:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 ghlTgX_Xnk1n for ; Tue,  2 Aug 2016 09:37:25 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4117212D7FD for ; Tue,  2 Aug 2016 09:37:25 -0700 (PDT)
X-AuditID: c1b4fb30-ea88e980000009f9-93-57a0cc43dcd2
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by  (Symantec Mail Security) with SMTP id 4E.6C.02553.34CC0A75; Tue,  2 Aug 2016 18:37:23 +0200 (CEST)
Received: from [159.107.198.46] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.301.0; Tue, 2 Aug 2016 18:35:54 +0200
To: Robert Wilton , Andy Bierman , Ladislav Lhotka , netmod WG 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local>
From: Balazs Lengyel 
Message-ID: <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com>
Date: Tue, 2 Aug 2016 18:35:54 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160729163220.GA3579@elstar.local>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM2K7q67zmQXhBq1H1S0eHJnFbnFh1Vw2 i/kXG1ktTpzrY3Zg8ZjyeyOrx5IlP5k8Nl2+w+jR0n+RJYAlissmJTUnsyy1SN8ugSvj543H TAVNrBWrLk9lbmD8yNzFyMkhIWAi8Wj7NSYQW0hgPaPE/w+OXYxcQPZqRomnG1awgySEBZQk +h7vZwdJiAh0MEoc+rGNGaJqCovE0rfbwdrZBIwkpvafZwGxeQXsJfZvOQlmswioSFxsvcvW xcjBISoQI7G+LwGiRFDi5MwnYCWcAoYSe7veMIKUMAO1PthaBhJmFpCX2P52DjPEcRoSDy/8 ZZ3AyD8LSfcshI5ZSDoWMDKvYhQtTi1Oyk03MtJLLcpMLi7Oz9PLSy3ZxAgM0oNbfhvsYHz5 3PEQowAHoxIPr0Lf/HAh1sSy4srcQ4wSHMxKIrw9pxeEC/GmJFZWpRblxxeV5qQWH2KU5mBR Euf1f6kYLiSQnliSmp2aWpBaBJNl4uCUamD0mL4iWm7mmj7nt48tT3jkJ8+QmsFobc93sXLp vKi5n9I4qxKzeqwlNeZzNFre9bdq+qBxK3nh/E6bjk8NaXGedis+9oj1TF98jPdchMGf/Pdm 39jll7/actJkn9JE4fUajc9WmhXF/g3cF2tXl/I26/CBfMHDTJ83svTmO8ywvs0ZrD3hw2ol luKMREMt5qLiRACLGrn7TgIAAA==
Archived-At: 
Subject: [netmod] OpsState and 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, 02 Aug 2016 16:37:27 -0000

Hello,
If we allow foo and foo-state for opstate, mounting models atop such a 
multi rooted yang module will be fun.
mount modB-config-part onto modA-config-part
mount modB-state-part onto modA-state-part
One mount becomes two and you have to maintain parallel mounts otherwise 
you are mounting half modules.

Actually the problem is not caused by opstate, but rather by 
multi-rooted models. but avoiding foo-state would make life easier once 
more.

regards Balazs

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Tue Aug  2 09: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 9589012D096 for ; Tue,  2 Aug 2016 09:41:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.487
X-Spam-Level: 
X-Spam-Status: No, score=-3.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQssaRfLdxTw for ; Tue,  2 Aug 2016 09:41:01 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 AA80F12D0D3 for ; Tue,  2 Aug 2016 09:41:00 -0700 (PDT)
X-AuditID: c1b4fb3a-0618b980000009bd-74-57a0cd1a1f22
Received: from ESESSHC009.ericsson.se (Unknown_Domain [153.88.183.45]) by  (Symantec Mail Security) with SMTP id FB.9A.02493.A1DC0A75; Tue,  2 Aug 2016 18:40:59 +0200 (CEST)
Received: from [159.107.198.46] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.47) with Microsoft SMTP Server id 14.3.301.0; Tue, 2 Aug 2016 18:39:57 +0200
To: Robert Wilton , "Acee Lindem (acee)" ,  Mahesh Jethanandani , Xufeng Liu 
References:   <20160721174033.GB54646@elstar.local>    <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com> <044701d1e833$d7ec0380$87c40a80$@gmail.com> <3E6E6E31-953D-4C6D-B3E8-45020A027A78@gmail.com>  <7950d76e-9b2a-7f7f-2c55-05fce26af6ba@cisco.com>
From: Balazs Lengyel 
Message-ID: 
Date: Tue, 2 Aug 2016 18:39:57 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <7950d76e-9b2a-7f7f-2c55-05fce26af6ba@cisco.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrNLMWRmVeSWpSXmKPExsUyM2K7rq702QXhBh9/MlpMfjuP2eL0m3Vs FvMvNrJanDjXx2xx5fgfJgdWjym/N7J67Jx1l91jyZKfTAHMUVw2Kak5mWWpRfp2CVwZx14/ YS/oP85UcWiTSANjwxLGLkZODgkBE4l1ix8zdTFycQgJrGeUmLtuAQuEs5pRov/CerAqYYEo iWvXXjGDJEQEljNKPOy9ANWyn0XiftNSZpAqZgF5iSMvlzGB2GwCRhJT+8+zgNi8AvYS7zb3 gNksAioSPd83snUxcnCICsRIrO9LgCgRlDg58wlYCaeArcTxzgYWiJH6Etfv3GeFGd+8dTbY KiEBDYmHF/6yTmAUmIWkfRaSlllIWhYwMq9iFC1OLS7OTTcy0kstykwuLs7P08tLLdnECAzi g1t+W+1gPPjc8RCjAAejEg+vQt/8cCHWxLLiytxDjBIczEoivD2nF4QL8aYkVlalFuXHF5Xm pBYfYpTmYFES5/V/qRguJJCeWJKanZpakFoEk2Xi4JRqYJzbltH3dMPJcMZLpg8WhSuJi1wo 3Ckwd392m7DpV+2XHjOdncvupX8/3W845UWi9z/Z6fc9/vsZq+turbuk8WvqU8tPMT39pp6t vuz+7uvUWflsVKNYvzKHuOXJWNgJT53dZD3FcFnyE32eoqsHvQ8qHpu+slz/l9TCXQ98Mv53 LDObn5yVo8RSnJFoqMVcVJwIAKoUGqJeAgAA
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Aug 2016 16:41:03 -0000


  
    
  
  
    
I don't know if we can make them a rule, but IMHO single-rooted
      modules are definitely easier to use. E.g. just as a single
      example: we only need one set of access control rules. Similar
      double handling is needed often. I don't like foo-state trees.

    

    
Balazs

    

    

    
On 2016-07-28 17:00, Robert Wilton
      wrote:

    

    

      
      


      

      

      
On 27/07/2016 20:44, Acee Lindem
        (acee) wrote:

      

      

        


        

        


        

        
          
 From: netmod <netmod-bounces@ietf.org>
            on behalf of Mahesh Jethanandani <mjethanandani@gmail.com>

            Date: Wednesday, July
            27, 2016 at 9:07 PM

            To: Xufeng Liu <xufeng.liu.ietf@gmail.com>

            Cc: netmod WG <netmod@ietf.org>

            Subject: Re: [netmod]
            OpsState Direction Impact on Recommended IETF YANG Model
            Structure

          

          


          

          

            

              

                Robert mentions IS-IS, and if I look at OSPF, I see a
                clear separation of rw and ro nodes.

            

          

        
        


        

        
Right - and this separation is based on the routing and
          routing-state split in the ietf-routing-cfg model. In general,
          ietf-routing-cfg specifies that all control plane protocol
          YANG models should adapt this structure. Anyone who thinks
          collapsing all the models one config/state tree is simply a
          matter of moving a few counters should taking a better look at
          the existing drafts. I outlined the options in the E-mail
          thread prior to IETF 96. Now, with the context of IETF 96
          behind us, I believe more NETMOD participants will understand
          the options. To review the options specified in the previous
          E-mail thread.

        


        

        

          

            
 1. Do nothing - allow them proceed as they are with
              multiple ways of

            
   representing the applied configuration. This
              would provide visibility to

            
   the data independent of whether or not the
              device supported the revised

            
   data-stores supporting implicit retrieval of the
              applied configuration.

            
 2. Prune out the redundant data nodes except those
              required as list

            
    keys, etc, since they can be obtained from the
              applied state data store.

            
 3. #2 plus collapse the config (read-write) and
              system-state

            
   (read-only) into common containers. No more
              branching of

            
   <model-name>-config and
              <model-name>-state at the top level of the model.

          

        

        


        

        
Prior to IETF 96, I dont believe we had selected a
          direction. However, I believe we agreed on option #1 in order
          to allow the publication of these models within the next year.
          Wed still be able to avail the benefits of applied vs
          intended configuration on network devices supporting these
          data stores. 

        

      

      My take is that I think that the leaning at IETF was towards 2.

      

      I.e. I think that we ruled out 1. I.e. the models must not have
      separate nodes to represent applied configuration because that
      will be solved by the datastore solution.

      

      But it feels a bit inconsistent that the models don't need to have
      explicit leaves for foo vs foo-applied (because it will be solved
      by datastores), but the models do still need explicit leaves for
      foo vs foo-state (even though this could/should also be solved by
      an operational state datastore - noting that both draft-schoenw
      and draft-wilton propose a solution to this problem).

      

      My preference, if we can get quick consensus would be to do 3, or
      if consensus is not possible for 3, then we should fallback to
      doing 2, as the next best option. But whatever the decision, I
      favour agreeing a direction quickly so that the other WGs know
      what to put in the RFCs.

      

      Thanks,

      Rob

      

      

        


        

        
Thanks,

        
Acee

        


        

        


        

        


        

        
          

            

              

                

                


                  

                    

                      
On Jul 27, 2016, at 11:22 AM, Xufeng
                        Liu <xufeng.liu.ietf@gmail.com>
                        wrote:

                      

                      

                        

                          
 The assumption of I
                            suspect that all the routing models will be
                            structured similarly is not correct. Very
                            few models in routing area structure this
                            way.

                          
 

                          
 Regards,

                          
 

                          
 - Xufeng

                          
 

                          

                            

                              

                                
 From:netmod
                                    [mailto:netmod-bounces@ietf.org]On Behalf OfRobert
                                    Wilton

                                    Sent:Wednesday,
                                    July 27, 2016 1:05 PM

                                    To:Kent
                                    Watsen <kwatsen@juniper.net>;
                                    netmod WG <netmod@ietf.org>

                                    Subject:Re:
                                    [netmod] OpsState Direction Impact
                                    on Recommended IETF YANG Model
                                    Structure

                              

                            

                            
 

                            
 

                            
 

                            

                              
 On 26/07/2016
                                21:36, Kent Watsen wrote:

                            

                            

                              
 

                              

                                

                                  
 <Rob
                                      Wilton writes>

                                  
 

                                    So my thinking is that if we can't
                                    merge "foo-state" into "foo" then
                                    instead we should have consistent
                                    rules that explicitly state that for
                                    all IETF models "foo" and
                                    "foo-state" are separate trees with
                                    a consistent naming convention and
                                    structure. That should hopefully
                                    allow tooling to programmatically
                                    relate the two separate trees
                                    together. It may give a path to
                                    allow "foo-state" to be merged into
                                    "foo" in future, but once IETF has
                                    standardized 600+ models with
                                    separate sub-trees, I cannot see
                                    that they would get merged back
                                    together again.

                                    

                                    What other alternatives are
                                    available? As a WG we need to tell
                                    the other WGs how the IETF YANG
                                    models should be structured.

                                    

                                    In short, unfortunately I think that
                                    we have probably already missed the
                                    opportunity to merge "foo" and
                                    "foo-state" subtrees together ...

                                    

                                    

                                    

                                  

                                    </Rob Wilton>

                                  
 

                                  
 

                                  

                                    Firstly, Im trying to get a sense
                                    of how big a problem this
                                    foo/foo-state thing is. [Note: by
                                    foo-state, Im only referring to
                                    counters, not opstate].

                                

                              

                            

                            
 RW:

                              By counters, I think that we also mean any
                              config false nodes that don't directly
                              represent "applied configuration", right?
                              E.g. is an interface operationally up or
                              down.

                              

                              

                              

                            

                              

                                

                                  
  I
                                    know about RFC 7223, which was done
                                    out of consideration for
                                    system-generated interfaces, but how
                                    many other such models are there
                                    envisioned to be?

                                

                              

                            

                            
 RW:

                              - Any models that augment RFC 7223 and
                              have config false nodes will be impacted.

                              - I thought that quite a lot of other IETF
                              models that are in the process of being
                              standardized have a top level split
                              between "foo" and "foo-state". E.g the
                              ISIS model
                              (draft-ietf-isis-yang-isis-cfg-08) has
                              this split. I suspect that all the
                              routing models will be structured
                              similarly.

                              - Although it is perhaps worth pointing
                              out that I think that the OpenConfig
                              modules effectively have exactly this same
                              issue (e.g. they have a combined
                              interfaces tree keyed by config true
                              leaves), and they pragmatically just
                              ignore the issue of system created
                              interface entries.

                              

                              

                              

                            

                              

                                

                                  
 Is
                                    this issue currently blocking models
                                    from progressing, or are we getting
                                    ourselves wrapped around a
                                    hypothetical?

                                

                              

                            

                            
 RW:

                              I think that it is blocking models from
                              progressing.

                              

                              The current guidance for "intended vs
                              applied" is clear. I.e. there must not be
                              "config false" leaves in the IETF YANG
                              data models to represent "applied config".

                              

                              But there is no clear guidance for the
                              rest of operational state that isn't
                              applied config. The other WGs need clear
                              guidance (effectively now) to ensure that
                              they can start publishing models as RFCs.

                              

                              

                              

                              

                            

                              

                                

                                  
  If
                                    RFC 7223 is an outlier, then we can
                                    address it as a special case
                                    (perhaps via the
                                    related-state/related-config YANG
                                    annotations). What do you think?

                                

                              

                            

                            
 RW:

                              Personally, I would like one common
                              convention that applies to all IETF YANG
                              models.

                              

                              Idealistically I would like foo and
                              foo-state to be merged because I think
                              that will make the models easier to use
                              and maintain in the long term, but I don't
                              know if we are just too late to go in that
                              direction. It seems to me that the NETMOD
                              WG really should try to come to a decision
                              quite quickly on this, but I don't know
                              how to encourage that. A virtual interim
                              on just this topic perhaps?

                              

                              

                              

                            

                              

                                

                                  
 

                                  
 Next,
                                    regarding paths forward (assuming
                                    7223 is not an outlier), Im
                                    thinking the opposite. Im quite
                                    sure that we would never merge the
                                    600+ models with separate subtrees
                                    back together again. So Im
                                    thinking we immediately merge foo
                                    and foo-state in all active YANG
                                    models (so that the YANG
                                    conceptual models are stable and
                                    good) *and* then we use your idea to
                                    programmatically generate the
                                    foo-state tree, presumably only
                                    when needed. This foo-state tree
                                    could be generated offline by tools
                                    and provided as a second YANG module
                                    in drafts. In this way, servers
                                    (opstate aware or not) can advertise
                                    if clients can access the foo-state
                                    tree (an opstate-aware server may
                                    still advertise it for business
                                    reasons, and it can deprecate the
                                    tree when no longer needed). We
                                    could do the same without tools
                                    today by just using a feature
                                    statement on, for instance, the
                                    interfaces-state container, but I
                                    like pushing for tooling upfront so
                                    that were guaranteed mergeability
                                    later. Thoughts?

                                

                              

                            

                            
 RW:

                              So the generated "foo-state" tree would
                              contain a copy of all config false nodes
                              in the YANG schema and a "config false
                              copy" of any config true nodes in the YANG
                              schema that are required to provide
                              parental structure for the descendant
                              config false nodes.

                              - The Xpath expressions would also need to
                              be adjusted, and possibly some of those
                              might break (or need to be fixed by hand).

                              - Groupings might be a problem, but
                              potentially they could be expanded.

                              

                              Technically this solution might work, but
                              is it possible to get everyone to agree
                              that this is the right direction to go in
                              before we spend time on this?

                              

                              Thanks,

                              Rob

                              

                              

                              

                              

                            

                              

                                

                                  
 

                                  
 Kent
                                    // as a contributor

                                    

                                    

                                    

                                  
 

                                  
 

                                

                              

                            

                            
 

                          

                        

                        _______________________________________________

                        netmod mailing list

                        netmod@ietf.org

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

                      

                    

                  

                  

                  

                    
Mahesh Jethanandani

                    
                    


                    

                    

                  

                  

                

              

            

          

         

        

        

        
_______________________________________________
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


    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Tue Aug  2 09:52: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 BEBB612B04F for ; Tue,  2 Aug 2016 09:52:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.186
X-Spam-Level: 
X-Spam-Status: No, score=-3.186 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-1.287] 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 n2N3gogwaPDs for ; Tue,  2 Aug 2016 09:52:21 -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 2C18C12D0E1 for ; Tue,  2 Aug 2016 09:52:20 -0700 (PDT)
Received: from [199.87.120.129] (helo=jivecommunications.com) by cappuccino.rob.sh with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:256) (Exim 4.80) (envelope-from ) id 1bUcv4-0006qM-Nd; Tue, 02 Aug 2016 17:51:54 +0100
Content-Type: multipart/alternative; boundary="Apple-Mail=_7991D393-9020-4ABC-A331-FE6BBEF3DE5F"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Rob Shakir 
In-Reply-To: <154e783b-9817-9d74-4af6-23f403db3fb2@ericsson.com>
Date: Tue, 2 Aug 2016 10:52:16 -0600
Message-Id: 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <154e783b-9817-9d74-4af6-23f403db3fb2@ericsson.com>
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 02 Aug 2016 16:52:24 -0000

--Apple-Mail=_7991D393-9020-4ABC-A331-FE6BBEF3DE5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=windows-1252

Balazs,

> On 2 Aug, 2016, at 10:29 AM, Balazs Lengyel =
 wrote:
> I prefer a tight definition so even if we allow both 1) and 2)  we =
should state that other combinations e.g. trees spliting close to the =
leaves or a mix of 1) and 2) in the same module are not allowed (VERYYYY =
STRONGLY discouraged).=20

What is the motivation for this very strongly discouraged statement? The =
problem I take with this is that you are not only getting zero =
consistency that will let a user determine how a model might look  =
(painful for those actually *using the models* rather than writing them =
- who are hugely under-represented in this discussion), but you=92re =
also throwing out a bunch of models (both inside and outside of the =
IETF) at the same time.

Apologies to pick specifically on this email, but I have still yet to =
see any justification why anything other than a solution that is already =
being implemented is preferable to this WG other than it seeming like =
the WG doesn=92t like the aesthetics of the modules in this case.

I am soon going to shut up on this topic, but it=92s quite frankly =
lamentable that such a division is being created with no reasonable =
justification.

Note that the statement that Benoit/Lou/Kent made in Berlin related to =
applied config - the structure that is being objected to can be =
trivially implemented without those leaves if one wanted to.

r.=

--Apple-Mail=_7991D393-9020-4ABC-A331-FE6BBEF3DE5F
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=windows-1252

Balazs,

On 2 Aug, 2016, at 10:29 AM, =
Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:
  • I prefer a tight =
definition so even if we allow both 1) and 2)  we should state that =
other combinations e.g. trees spliting close to the leaves or a mix of =
1) and 2) in the same module are not allowed (VERYYYY STRONGLY =
discouraged). 

What is the motivation for this very strongly =
discouraged statement? The problem I take with this is that you are not =
only getting zero consistency that will let a user determine how a model =
might look  (painful for those actually *using the models* rather =
than writing them - who are hugely under-represented in this =
discussion), but you=92re also throwing out a bunch of models (both =
inside and outside of the IETF) at the same time.

Apologies to pick specifically on this email, but =
I have still yet to see any justification why anything other than a =
solution that is already being implemented is preferable to this WG =
other than it seeming like the WG doesn=92t like the aesthetics of the =
modules in this case.

I am soon =
going to shut up on this topic, but it=92s quite frankly lamentable that =
such a division is being created with no reasonable =
justification.

Note that the =
statement that Benoit/Lou/Kent made in Berlin related to applied config =
- the structure that is being objected to can be trivially implemented =
without those leaves if one wanted to.

r.
=

--Apple-Mail=_7991D393-9020-4ABC-A331-FE6BBEF3DE5F--


From nobody Tue Aug  2 18:20: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 D119412D8B0 for ; Tue,  2 Aug 2016 18:20:30 -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 0Qk0ZWvfpZlt for ; Tue,  2 Aug 2016 18:20:29 -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 0F0FD12D5A5 for ; Tue,  2 Aug 2016 18:20:29 -0700 (PDT)
Received: (qmail 1966 invoked by uid 0); 3 Aug 2016 01:20:26 -0000
Received: from unknown (HELO cmgw4) (10.0.90.85) by gproxy7.mail.unifiedlayer.com with SMTP; 3 Aug 2016 01:20:26 -0000
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw4 with  id SRLP1t00G2SSUrH01RLSmb; Tue, 02 Aug 2016 19:20:26 -0600
X-Authority-Analysis: v=2.1 cv=TIHWFTVa c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=L9H7d07YOLsA:10 a=9cW_t1CCXrUA:10 a=s5jvgZ67dGcA:10 a=IkcTkHD0fZMA:10 a=-NfooI8aBGcA:10 a=oK_VWpv5GtAA:10 a=7z1cN_iqozsA:10 a=48vgC7mUAAAA:8 a=u07AKapRAAAA:8 a=ek1ZzK3JAAAA:8 a=OUXY8nFuAAAA:8 a=AUd_NHdVAAAA:8 a=nQaUV9sFGWsXzAb8ceEA:9 a=QEXdDO2ut3YA:10 a=q1VKPNYKicEA:10 a=NWVoK91CQySWRX1oVYDe:22 a=w1C3t2QeGrPiZgrLijVG:22 a=SkebfZ6J2Mmvk2rLHZle:22 a=xQ-UgBqouqXb-DtQvhst:22 a=cAcMbU7R10T-QSRYIcO_:22 a=TSZmLRzkpGLBZRr3r8m8:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: Message-ID:Date:To:From; bh=yL3rHXE9YckrZZrpQiptdBDRmi0owtaOq2DXxNxLcqU=; b=C JQOCxwZqtaj7cOxG2HoWiJadEyrGRgYJ/IihMkNtzWKMQkWpUpuXcLDGRj/qlZSU6jbh8i6sa194n kD5eU2SC3w1eOQMYUufq2ANrSbHP7ytKysRCcFv0KjhVZkA5fB;
Received: from [100.15.89.178] (port=41239 helo=[11.4.0.238]) by box313.bluehost.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.86_2) (envelope-from ) id 1bUkr9-0006oG-4p for netmod@ietf.org; Tue, 02 Aug 2016 19:20:23 -0600
From: Lou Berger 
To: NETMOD Working Group 
Date: Tue, 02 Aug 2016 21:20:16 -0400
Message-ID: <1564dfc9c80.2818.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
User-Agent: AquaMail/1.6.2.9 (build: 27000209)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Identified-User: {1038:box313.bluehost.com:labnmobi:labn.net} {sentby:smtp auth 100.15.89.178 authed with lberger@labn.net}
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Source-IP: 100.15.89.178
X-Exim-ID: 1bUkr9-0006oG-4p
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: ([11.4.0.238]) [100.15.89.178]:41239
X-Source-Auth: lberger@labn.net
X-Email-Count: 0
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
Archived-At: 
Subject: [netmod] Updated YANG Datastore Design Team
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 03 Aug 2016 01:20:31 -0000

All,

The NETMOD Working Group has formed the Updated YANG Datastore Design Team. 
The mandate for the DT is to build on the drafts [1] and [2] and 
discussions related to using a conceptual datastore-based approach to 
support  vs  configuration, and deliver a baseline 
individual draft for discussion by the Working Group prior to the next IETF 
(IETF 97, Seoul). The proposed solution should also take into consideration 
support for ephemeral state as documented by the I2RS Working Group. The 
published individual draft will be discussed and progressed per normal WG 
process.

The DT has limited membership and will choose how it works to produce its 
draft. For example, the DT may choose to publicize their calls/progress or 
not. We recognize that not all who have contributed to this discussion are 
identified as DT members. Those who are willing to provide input to the DT 
should contact them directly. The DT mailing list is netmod-ds-dt@ietf.org. 
Keep in mind that there will be plenty of opportunity for input, per normal 
WG process, once the DT's individual draft is published and once there is a 
WG draft accepted on this topic.

The members of the DT are:
Martin Bjorklund 
Christian Hopps 
Juergen Schoenwaelder 
Phil Shafer  -- Lead
Robert Wilton 

[1] https://tools.ietf.org/html/draft-schoenw-netmod-revised-datastores
[2] https://tools.ietf.org/html/draft-wilton-netmod-refined-datastores

Lou and Kent




From nobody Tue Aug  2 23:49: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 3AB1512B05C for ; Tue,  2 Aug 2016 23:49:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.287
X-Spam-Level: 
X-Spam-Status: No, score=-8.287 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=-1.287] 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 9p5_zsCe0JA3 for ; Tue,  2 Aug 2016 23:49: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 927BB12B020 for ; Tue,  2 Aug 2016 23:49:02 -0700 (PDT)
Received: from [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:d] (unknown [IPv6:2001:1488:fffe:6:ffff:ffff:ffff:d]) by mail.nic.cz (Postfix) with ESMTPSA id 1833561846; Wed,  3 Aug 2016 08:49:00 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470206940; bh=CbS3pjJBPU/e1sgbxyBIqP/ywPXM9ptKoH8ZJSqQaa4=; h=From:Date:To; b=S8G5FiPztIQqWwdiY9BTTUocZfWu5RuzV2Ywv4tB8i44Dfw4QKN1HUni7ryTATIgZ pRFXJUs737OmTdkbD4dFdcRHBRMtmHbXaO4c8s/zu2VG7AX+jpRZ1pG9+2Q6U5DEJH SMUCwApkOEQVRDZRJIgjU0B1zfDiJin1oWna7s9c=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com>
Date: Wed, 3 Aug 2016 08:49:02 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz>
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com>
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 03 Aug 2016 06:49:04 -0000

> On 02 Aug 2016, at 18:35, Balazs Lengyel  =
wrote:
>=20
> Hello,
> If we allow foo and foo-state for opstate, mounting models atop such a =
multi rooted yang module will be fun.
> mount modB-config-part onto modA-config-part
> mount modB-state-part onto modA-state-part
> One mount becomes two and you have to maintain parallel mounts =
otherwise you are mounting half modules.

This is already happenning with augments. It means some work but nothing =
terribly complex.

>=20
> Actually the problem is not caused by opstate, but rather by =
multi-rooted models. but avoiding foo-state would make life easier once =
more.

We already agreed that some items (such as RIBs) are "true" state which =
don't have direct counterparts in configuration. If we don't have =
foo-state, where are these supposed to be placed?

Lada=20

>=20
> regards Balazs
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: =
Balazs.Lengyel@ericsson.com
>=20

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





From nobody Wed Aug  3 01:46: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 DA8CF12D130 for ; Wed,  3 Aug 2016 01:46:43 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 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=-1.287, 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 rOw8PT5JPmxT for ; Wed,  3 Aug 2016 01:46:43 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D630A12D10E for ; Wed,  3 Aug 2016 01:46:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=865; q=dns/txt; s=iport; t=1470214002; x=1471423602; h=subject:to:references:from:cc:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=gCAkzXWzN5fmVHS+WGmpEwIKnKeUrvUeGyqyW+KBbws=; b=iXy6ToiYrzzfkggw5NwiB3tRja1359+j/6OrEemwt8uEXzZLwPJEGAIr mb3mNOeubrswn18kQnbbNjg8ZX8HHWKuHcLJGrpZZGRDr8eXfEMhptP0r g5w8Uw7ZOBB4LLxBpWIO7TZ9I4pbev3PWixiygDqUvDgE5Nk4Zq8QzBlI 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BqCgDtraFX/xbLJq1dhEW7fYYdAoISA?= =?us-ascii?q?QEBAQEBXieEXwEFOEEQCxguVwYBDAgBARWIGL8TAQEBAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BH4YqgXiCVYobAQSZNI5/iVOFbIhog0iDd1SDezuJDgEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,465,1464652800"; d="scan'208";a="639270997"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2016 08:46:39 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u738kdu7011926; Wed, 3 Aug 2016 08:46:39 GMT
To: Balazs Lengyel , netmod WG 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com>
From: Robert Wilton 
Message-ID: <905fc8c9-b4b8-1f1f-badd-0d1b0b229c9e@cisco.com>
Date: Wed, 3 Aug 2016 09:46:41 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] OpsState and 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, 03 Aug 2016 08:46:44 -0000

Hi Balazs,

Yes, it would be exactly as you describe: you end up having two parallel 
trees, with two parallel sets of mount points.

It feels like this would be an extra wart, but not the end of the world.

I also agree that avoiding the foo/foo-state split would help mitigate this.

Thanks,
Rob


On 02/08/2016 17:35, Balazs Lengyel wrote:
> Hello,
> If we allow foo and foo-state for opstate, mounting models atop such a 
> multi rooted yang module will be fun.
> mount modB-config-part onto modA-config-part
> mount modB-state-part onto modA-state-part
> One mount becomes two and you have to maintain parallel mounts 
> otherwise you are mounting half modules.
>
> Actually the problem is not caused by opstate, but rather by 
> multi-rooted models. but avoiding foo-state would make life easier 
> once more.
>
> regards Balazs
>


From nobody Wed Aug  3 02:02: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 3D81312D733 for ; Wed,  3 Aug 2016 02:02:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 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=-1.287, 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 ZvycgdTnVKJh for ; Wed,  3 Aug 2016 02:02: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 7FA6012D67B for ; Wed,  3 Aug 2016 02:02:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1290; q=dns/txt; s=iport; t=1470214935; x=1471424535; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=XJPV8iKrSCZ0N1Is7GTayJIB8WY9jRW1cvCl5zcOniQ=; b=DE2H+eOC6Hl3zSfongG+TeK+3Q2qLc7PLq/AqtnJwtY6kXiZ7SxahOZW 22qjScxFncpnKv/q1UFUXfAbwYJvTKbB9w6NtEl8lQnn2lg2h8bqYvC9+ RiBjJDWSWMIL0Hz+XtC43N7wDRV5uYZydVERdK5waPAp/kZyIx6Qn3DsO 4=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BxCgD3saFX/xbLJq1dhEVSuyuGHQKCA?= =?us-ascii?q?hABAQEBAQEBXSeEXgEBBAE4QRALGC5XBgEMBgIBARWIEAi/GQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAR+GKoF4glWEEhEBhXcBBJk0jn+JU4VsiGiDSIN3NR+DezsyhyaBN?= =?us-ascii?q?gEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,465,1464652800"; d="scan'208";a="638253311"
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; 03 Aug 2016 09:02:13 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u7392D09000302; Wed, 3 Aug 2016 09:02:13 GMT
To: Ladislav Lhotka , Balazs Lengyel 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz>
From: Robert Wilton 
Message-ID: <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>
Date: Wed, 3 Aug 2016 10:02:14 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 03 Aug 2016 09:02:17 -0000

On 03/08/2016 07:49, Ladislav Lhotka wrote:
>> On 02 Aug 2016, at 18:35, Balazs Lengyel  wrote:
>>
>> Hello,
>> If we allow foo and foo-state for opstate, mounting models atop such a multi rooted yang module will be fun.
>> mount modB-config-part onto modA-config-part
>> mount modB-state-part onto modA-state-part
>> One mount becomes two and you have to maintain parallel mounts otherwise you are mounting half modules.
> This is already happenning with augments. It means some work but nothing terribly complex.
>
>> Actually the problem is not caused by opstate, but rather by multi-rooted models. but avoiding foo-state would make life easier once more.
> We already agreed that some items (such as RIBs) are "true" state which don't have direct counterparts in configuration. If we don't have foo-state, where are these supposed to be placed?
One choice is that they could just be placed under foo, where foo is a 
config false leaf.

Rob


>
> Lada
>
>> regards Balazs
>>
>> -- 
>> Balazs Lengyel                       Ericsson Hungary Ltd.
>> Senior Specialist
>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
> .
>


From nobody Wed Aug  3 11:37: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 6D40F12D7C0 for ; Wed,  3 Aug 2016 11:37:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 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=-1.287, 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 JXlQvC37FVsY for ; Wed,  3 Aug 2016 11:37:55 -0700 (PDT)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7515E12D7AA for ; Wed,  3 Aug 2016 11:37:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2542; q=dns/txt; s=iport; t=1470249475; x=1471459075; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=cld9KVHE7XUfRQXkYAz8iIgJsfr9LY5of7uXOND2zXw=; b=LVBZNPzjwYHD2ju+4sY+anWdHq+EhDUDLVOtutkeyLsmaniD1SKLCdUK QOxi6fp5Imcn5Rr+VQTIRhOT+D1rGZoYf7UfQPIJvwu9Y6tYCB8quOReA 8TL2vsbiupAbVsvum7O7Qr2g/rIlRSzoIHkYwXp/Wl5TIHwTbXbVvUMVV o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A4AgCsOKJX/5BdJa1dg0VWfAe5KoF9J?= =?us-ascii?q?IUvSgIcgTA4FAEBAQEBAQFdJ4RfAQUBASEROgsQAgEIGAICJgICAiULFRACBAE?= =?us-ascii?q?NBRmIGA6vMY9/AQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYl2hBIKBwEcF4Jqg?= =?us-ascii?q?loFmTQBjn6PQIwwg3YBHjaDem6HFQ8XIH8BAQE?=
X-IronPort-AV: E=Sophos;i="5.28,466,1464652800"; d="scan'208";a="304928456"
Received: from rcdn-core-8.cisco.com ([173.37.93.144]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Aug 2016 18:37:54 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id u73IbsMn003285 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 3 Aug 2016 18:37:54 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 3 Aug 2016 14:37:53 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 3 Aug 2016 14:37:53 -0400
From: "Acee Lindem (acee)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  Ladislav Lhotka , Balazs Lengyel 
Thread-Topic: [netmod] OpsState and Schema-Mount
Thread-Index: AQHR7Nww0Wi3xAkXLk+F7Qwy4jNZ96A3D5IAgAAlNwCAAF3CAA==
Date: Wed, 3 Aug 2016 18:37:53 +0000
Message-ID: 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>
In-Reply-To: <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <3BAED854F6B9CF47AA605FF8A1FD46AD@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 03 Aug 2016 18:37:57 -0000

DQoNCk9uIDgvMy8xNiwgNTowMiBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgUm9iZXJ0IFdpbHRv
biAtWCAocndpbHRvbiAtDQpFTlNPRlQgTElNSVRFRCBhdCBDaXNjbykiIDxuZXRtb2QtYm91bmNl
c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YNCnJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCg0KPg0K
Pg0KPk9uIDAzLzA4LzIwMTYgMDc6NDksIExhZGlzbGF2IExob3RrYSB3cm90ZToNCj4+PiBPbiAw
MiBBdWcgMjAxNiwgYXQgMTg6MzUsIEJhbGF6cyBMZW5neWVsIDxiYWxhenMubGVuZ3llbEBlcmlj
c3Nvbi5jb20+DQo+Pj53cm90ZToNCj4+Pg0KPj4+IEhlbGxvLA0KPj4+IElmIHdlIGFsbG93IGZv
byBhbmQgZm9vLXN0YXRlIGZvciBvcHN0YXRlLCBtb3VudGluZyBtb2RlbHMgYXRvcCBzdWNoIGEN
Cj4+Pm11bHRpIHJvb3RlZCB5YW5nIG1vZHVsZSB3aWxsIGJlIGZ1bi4NCj4+PiBtb3VudCBtb2RC
LWNvbmZpZy1wYXJ0IG9udG8gbW9kQS1jb25maWctcGFydA0KPj4+IG1vdW50IG1vZEItc3RhdGUt
cGFydCBvbnRvIG1vZEEtc3RhdGUtcGFydA0KPj4+IE9uZSBtb3VudCBiZWNvbWVzIHR3byBhbmQg
eW91IGhhdmUgdG8gbWFpbnRhaW4gcGFyYWxsZWwgbW91bnRzDQo+Pj5vdGhlcndpc2UgeW91IGFy
ZSBtb3VudGluZyBoYWxmIG1vZHVsZXMuDQo+PiBUaGlzIGlzIGFscmVhZHkgaGFwcGVubmluZyB3
aXRoIGF1Z21lbnRzLiBJdCBtZWFucyBzb21lIHdvcmsgYnV0DQo+Pm5vdGhpbmcgdGVycmlibHkg
Y29tcGxleC4NCj4+DQo+Pj4gQWN0dWFsbHkgdGhlIHByb2JsZW0gaXMgbm90IGNhdXNlZCBieSBv
cHN0YXRlLCBidXQgcmF0aGVyIGJ5DQo+Pj5tdWx0aS1yb290ZWQgbW9kZWxzLiBidXQgYXZvaWRp
bmcgZm9vLXN0YXRlIHdvdWxkIG1ha2UgbGlmZSBlYXNpZXIgb25jZQ0KPj4+bW9yZS4NCj4+IFdl
IGFscmVhZHkgYWdyZWVkIHRoYXQgc29tZSBpdGVtcyAoc3VjaCBhcyBSSUJzKSBhcmUgInRydWUi
IHN0YXRlIHdoaWNoDQo+PmRvbid0IGhhdmUgZGlyZWN0IGNvdW50ZXJwYXJ0cyBpbiBjb25maWd1
cmF0aW9uLiBJZiB3ZSBkb24ndCBoYXZlDQo+PmZvby1zdGF0ZSwgd2hlcmUgYXJlIHRoZXNlIHN1
cHBvc2VkIHRvIGJlIHBsYWNlZD8NCj5PbmUgY2hvaWNlIGlzIHRoYXQgdGhleSBjb3VsZCBqdXN0
IGJlIHBsYWNlZCB1bmRlciBmb28sIHdoZXJlIGZvbyBpcyBhDQo+Y29uZmlnIGZhbHNlIGxlYWYu
DQoNCldoaWxlIHRoZXJlIGlzIGEgTkVUQ09ORi9SRVNUQ09ORiBpbmNvbXBhdGliaWxpdHkgd2l0
aCBjb25maWctZmFsc2UgZGF0YQ0Kbm9kZXMgdW5kZXIgY29uZmlnLXRydWUgZGF0YSBub2Rlcywg
dGhlcmUgaXMgbm8gcHJvYmxlbSB3aXRoIHRoZSByZXZlcnNlIC0NCmNvcnJlY3Q/IA0KDQpUaGFu
a3MsDQpBY2VlDQoNCg0KDQoNCj4NCj5Sb2INCj4NCj4NCj4+DQo+PiBMYWRhDQo+Pg0KPj4+IHJl
Z2FyZHMgQmFsYXpzDQo+Pj4NCj4+PiAtLSANCj4+PiBCYWxhenMgTGVuZ3llbCAgICAgICAgICAg
ICAgICAgICAgICAgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuDQo+Pj4gU2VuaW9yIFNwZWNpYWxpc3QN
Cj4+PiBNb2JpbGU6ICszNi03MC0zMzAtNzkwOSAgICAgICAgICAgICAgZW1haWw6IEJhbGF6cy5M
ZW5neWVsQGVyaWNzc29uLmNvbQ0KPj4+DQo+PiAtLQ0KPj4gTGFkaXNsYXYgTGhvdGthLCBDWi5O
SUMgTGFicw0KPj4gUEdQIEtleSBJRDogRTc0RThDMEMNCj4+DQo+Pg0KPj4NCj4+DQo+PiAuDQo+
Pg0KPg0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
bmV0bW9kIG1haWxpbmcgbGlzdA0KPm5ldG1vZEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==


From nobody Wed Aug  3 23:58: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 36548126FDC for ; Wed,  3 Aug 2016 23:58:23 -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 v3LG4i3G3Yk1 for ; Wed,  3 Aug 2016 23:58:20 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 92A0912D0E0 for ; Wed,  3 Aug 2016 23:58:20 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 194A71CC00A1; Thu,  4 Aug 2016 08:58:29 +0200 (CEST)
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
In-Reply-To: <20160802124242.GB27358@elstar.local>
References:  <6C7B9426-DB44-40B0-9AEE-1A7A0D51D1D0@nic.cz> <20160728145153.GC1752@elstar.local>  <1f3c1297-da13-9fdb-fa8e-b9b8141d82a0@ericsson.com>      <20160802124242.GB27358@elstar.local>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 04 Aug 2016 08:58:23 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Design-Time 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: Thu, 04 Aug 2016 06:58:23 -0000

Juergen Schoenwaelder  writes:

> On Tue, Aug 02, 2016 at 01:12:34PM +0200, Ladislav Lhotka wrote:
>> 
>> Yes, but if the YANG version is bumped, the client can immediately see
>> that it is not compatible, and disconnect. In contrast, sec. 6.3.1 says
>> that an extension "MAY be ignored in its entirety". According to the
>> RFC 2119 semantics, doing so should not affect interoperability, which
>> is clearly not the case here.
>>
>
> This is apparently where views substantially differ; I do not consider
> it an interoperability failure if an old client does not understand a
> part of a datamodel of an updated server that the old client is not
> dealing with. For me, interoperability means that a server can upgrade
> while old clients continue to function as they did before. For me,
> interoperability does not mean that server and clients always have to
> be updated at the same time and it does not mean that a client needs
> to understand and support the entire set of datamodels exposed by a
> server.

If this was the only aspect of interoperability, then the best data
model would perhaps be just anydata at the top and nothing else.

In my view, it is the information from the data model that reduces
entropy and thus increases interoperability. Of course, it depends on
the purpose of the client but, in general, a client that understands
only a part of the data model is less interoperable with the given
server than a client that understands it fully.

Notwithstanding terminology, I think it is rather important to keep YANG
extensions strictly optional because otherwise we will see vendor
extensions that effectively limit the choice of clients and management
systems.

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 Thu Aug  4 03:53: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 296AC12DD2A for ; Thu,  4 Aug 2016 03:53:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.809
X-Spam-Level: 
X-Spam-Status: No, score=-15.809 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=-1.287, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id CcTO97DWOc39 for ; Thu,  4 Aug 2016 03:53: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 2EE9212DD3F for ; Thu,  4 Aug 2016 03:52:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3041; q=dns/txt; s=iport; t=1470307976; x=1471517576; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ashpJuv5th+KQLtLotpPtgox5zHTL/yaTEWgprYglwY=; b=LiZTHpeYuOndSKMs8O9e616YtzkZNeR6RZ6lcJPgTig5zWrVBph6tUWJ YAkt+a967KvEqZmrBew4McwM0ejwsSccrEyjGNNN0qQLxpmEEeUiTjVyA LFFG69umGTLYsGgY2qZGOmF3eV7ry0Y4ok1J1wGLA+fXmY3Jd9Sf6s66N c=;
X-IronPort-AV: E=Sophos;i="5.28,470,1464652800"; d="scan'208";a="681089848"
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; 04 Aug 2016 10:52:54 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id u74Aqs55016903; Thu, 4 Aug 2016 10:52:54 GMT
To: "Acee Lindem (acee)" , Ladislav Lhotka , Balazs Lengyel 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com> 
From: Robert Wilton 
Message-ID: <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>
Date: Thu, 4 Aug 2016 11:52:53 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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: Thu, 04 Aug 2016 10:53:11 -0000

On 03/08/2016 19:37, Acee Lindem (acee) wrote:
>
> On 8/3/16, 5:02 AM, "netmod on behalf of Robert Wilton -X (rwilton -
> ENSOFT LIMITED at Cisco)"  rwilton@cisco.com> wrote:
>
>>
>> On 03/08/2016 07:49, Ladislav Lhotka wrote:
>>>> On 02 Aug 2016, at 18:35, Balazs Lengyel 
>>>> wrote:
>>>>
>>>> Hello,
>>>> If we allow foo and foo-state for opstate, mounting models atop such a
>>>> multi rooted yang module will be fun.
>>>> mount modB-config-part onto modA-config-part
>>>> mount modB-state-part onto modA-state-part
>>>> One mount becomes two and you have to maintain parallel mounts
>>>> otherwise you are mounting half modules.
>>> This is already happenning with augments. It means some work but
>>> nothing terribly complex.
>>>
>>>> Actually the problem is not caused by opstate, but rather by
>>>> multi-rooted models. but avoiding foo-state would make life easier once
>>>> more.
>>> We already agreed that some items (such as RIBs) are "true" state which
>>> don't have direct counterparts in configuration. If we don't have
>>> foo-state, where are these supposed to be placed?
>> One choice is that they could just be placed under foo, where foo is a
>> config false leaf.
> While there is a NETCONF/RESTCONF incompatibility with config-false data
> nodes under config-true data nodes, there is no problem with the reverse -
> correct?
You are allowed config false nodes under config true, but not config 
true nodes under config false.

I had assumed in the example above that there wasn't already a config 
true "foo" to put them under, so to reconsider my answer:

In draft-ietf-netmod-routing-cfg "routing" is a top level container that 
is nominally config true.  But it is also a non presence container, so 
it would be allowed to put the config false RIB nodes directly under the 
"routing" container.  Given that "routing" is an NP container, its 
existence (e.g. to report the RIB) doesn't imply that routing has been 
configured.

In fact (given the recent discussion on the NETCONF alias), it is 
questionable what a "config" true NP container actually means.  I 
suspect that really it just ends up being a filter as to what type of 
child nodes are allowed.  I.e. if the NP container is config=true, then 
child nodes can be config true or config false. Conversely, if the NP 
container is config false then any child nodes must also be config false.

Thanks,
Rob


>
> Thanks,
> Acee
>
>
>
>
>> Rob
>>
>>
>>> Lada
>>>
>>>> regards Balazs
>>>>
>>>> -- 
>>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>>> Senior Specialist
>>>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>>>>
>>> --
>>> 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 Aug  4 06: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 792E812D0A1 for ; Thu,  4 Aug 2016 06:56:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.808
X-Spam-Level: 
X-Spam-Status: No, score=-15.808 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=-1.287, 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 Jhz2rfgV7wQO for ; Thu,  4 Aug 2016 06:56:14 -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 79CF112B00E for ; Thu,  4 Aug 2016 06:56:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4686; q=dns/txt; s=iport; t=1470318974; x=1471528574; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=4H9WhLxGBtrYi3+hacEMffchMT99nJgfc0dC4UDXL80=; b=Oy/xL1FuRk0JQ++2QyLv3jYE4jZYdq6K3MCPbL791H1MRGzAJ7aN7If6 /Ha7l94uiVlPy98POIfE/vw2HjoO2cZonbtzVKCvg5e4v8BxtxRJ4eRLf r7BowUmXK/Iho9+IUZ0JKx+6ZpiEppjGSxrpYRSWit7jxaCXAhLL1VsGG E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BdAgAESaNX/5xdJa1dg0VWfAe5FIF9J?= =?us-ascii?q?IUvSgIcgTY4FAEBAQEBAQFdJ4RfAQUBASEROgsQAgEIGAICJgICAiULFRACBAE?= =?us-ascii?q?NBRmIGA6udY9vAQEBAQEBAQEBAQEBAQEBAQEBAQEBFwWBAYl2hBIKBwEzgmqCW?= =?us-ascii?q?gWZNAGPAY9AjDGDdgEeNoN6boYIDxcgfwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,470,1464652800"; d="scan'208";a="306743118"
Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Aug 2016 13:56:13 +0000
Received: from XCH-RTP-010.cisco.com (xch-rtp-010.cisco.com [64.101.220.150]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id u74DuDci029965 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Aug 2016 13:56:13 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-010.cisco.com (64.101.220.150) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Thu, 4 Aug 2016 09:56:12 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 4 Aug 2016 09:56:12 -0400
From: "Acee Lindem (acee)" 
To: "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" ,  Ladislav Lhotka , Balazs Lengyel 
Thread-Topic: [netmod] OpsState and Schema-Mount
Thread-Index: AQHR7Nww0Wi3xAkXLk+F7Qwy4jNZ96A3D5IAgAAlNwCAAF3CAIABU36A///wI4A=
Date: Thu, 4 Aug 2016 13:56:12 +0000
Message-ID: 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>
In-Reply-To: <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <21497D94857ADA46853D40C145A63714@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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: Thu, 04 Aug 2016 13:56:16 -0000

DQoNCk9uIDgvNC8xNiwgNjo1MiBBTSwgIlJvYmVydCBXaWx0b24gLVggKHJ3aWx0b24gLSBFTlNP
RlQgTElNSVRFRCBhdCBDaXNjbykiDQo8cndpbHRvbkBjaXNjby5jb20+IHdyb3RlOg0KDQo+DQo+
DQo+T24gMDMvMDgvMjAxNiAxOTozNywgQWNlZSBMaW5kZW0gKGFjZWUpIHdyb3RlOg0KPj4NCj4+
IE9uIDgvMy8xNiwgNTowMiBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgUm9iZXJ0IFdpbHRvbiAt
WCAocndpbHRvbiAtDQo+PiBFTlNPRlQgTElNSVRFRCBhdCBDaXNjbykiIDxuZXRtb2QtYm91bmNl
c0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YNCj4+IHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4+
DQo+Pj4NCj4+PiBPbiAwMy8wOC8yMDE2IDA3OjQ5LCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQo+
Pj4+PiBPbiAwMiBBdWcgMjAxNiwgYXQgMTg6MzUsIEJhbGF6cyBMZW5neWVsDQo+Pj4+PjxiYWxh
enMubGVuZ3llbEBlcmljc3Nvbi5jb20+DQo+Pj4+PiB3cm90ZToNCj4+Pj4+DQo+Pj4+PiBIZWxs
bywNCj4+Pj4+IElmIHdlIGFsbG93IGZvbyBhbmQgZm9vLXN0YXRlIGZvciBvcHN0YXRlLCBtb3Vu
dGluZyBtb2RlbHMgYXRvcCBzdWNoDQo+Pj4+PmENCj4+Pj4+IG11bHRpIHJvb3RlZCB5YW5nIG1v
ZHVsZSB3aWxsIGJlIGZ1bi4NCj4+Pj4+IG1vdW50IG1vZEItY29uZmlnLXBhcnQgb250byBtb2RB
LWNvbmZpZy1wYXJ0DQo+Pj4+PiBtb3VudCBtb2RCLXN0YXRlLXBhcnQgb250byBtb2RBLXN0YXRl
LXBhcnQNCj4+Pj4+IE9uZSBtb3VudCBiZWNvbWVzIHR3byBhbmQgeW91IGhhdmUgdG8gbWFpbnRh
aW4gcGFyYWxsZWwgbW91bnRzDQo+Pj4+PiBvdGhlcndpc2UgeW91IGFyZSBtb3VudGluZyBoYWxm
IG1vZHVsZXMuDQo+Pj4+IFRoaXMgaXMgYWxyZWFkeSBoYXBwZW5uaW5nIHdpdGggYXVnbWVudHMu
IEl0IG1lYW5zIHNvbWUgd29yayBidXQNCj4+Pj4gbm90aGluZyB0ZXJyaWJseSBjb21wbGV4Lg0K
Pj4+Pg0KPj4+Pj4gQWN0dWFsbHkgdGhlIHByb2JsZW0gaXMgbm90IGNhdXNlZCBieSBvcHN0YXRl
LCBidXQgcmF0aGVyIGJ5DQo+Pj4+PiBtdWx0aS1yb290ZWQgbW9kZWxzLiBidXQgYXZvaWRpbmcg
Zm9vLXN0YXRlIHdvdWxkIG1ha2UgbGlmZSBlYXNpZXINCj4+Pj4+b25jZQ0KPj4+Pj4gbW9yZS4N
Cj4+Pj4gV2UgYWxyZWFkeSBhZ3JlZWQgdGhhdCBzb21lIGl0ZW1zIChzdWNoIGFzIFJJQnMpIGFy
ZSAidHJ1ZSIgc3RhdGUNCj4+Pj53aGljaA0KPj4+PiBkb24ndCBoYXZlIGRpcmVjdCBjb3VudGVy
cGFydHMgaW4gY29uZmlndXJhdGlvbi4gSWYgd2UgZG9uJ3QgaGF2ZQ0KPj4+PiBmb28tc3RhdGUs
IHdoZXJlIGFyZSB0aGVzZSBzdXBwb3NlZCB0byBiZSBwbGFjZWQ/DQo+Pj4gT25lIGNob2ljZSBp
cyB0aGF0IHRoZXkgY291bGQganVzdCBiZSBwbGFjZWQgdW5kZXIgZm9vLCB3aGVyZSBmb28gaXMg
YQ0KPj4+IGNvbmZpZyBmYWxzZSBsZWFmLg0KPj4gV2hpbGUgdGhlcmUgaXMgYSBORVRDT05GL1JF
U1RDT05GIGluY29tcGF0aWJpbGl0eSB3aXRoIGNvbmZpZy1mYWxzZSBkYXRhDQo+PiBub2RlcyB1
bmRlciBjb25maWctdHJ1ZSBkYXRhIG5vZGVzLCB0aGVyZSBpcyBubyBwcm9ibGVtIHdpdGggdGhl
DQo+PnJldmVyc2UgLQ0KPj4gY29ycmVjdD8NCj5Zb3UgYXJlIGFsbG93ZWQgY29uZmlnIGZhbHNl
IG5vZGVzIHVuZGVyIGNvbmZpZyB0cnVlLCBidXQgbm90IGNvbmZpZw0KPnRydWUgbm9kZXMgdW5k
ZXIgY29uZmlnIGZhbHNlLg0KPg0KPkkgaGFkIGFzc3VtZWQgaW4gdGhlIGV4YW1wbGUgYWJvdmUg
dGhhdCB0aGVyZSB3YXNuJ3QgYWxyZWFkeSBhIGNvbmZpZw0KPnRydWUgImZvbyIgdG8gcHV0IHRo
ZW0gdW5kZXIsIHNvIHRvIHJlY29uc2lkZXIgbXkgYW5zd2VyOg0KPg0KPkluIGRyYWZ0LWlldGYt
bmV0bW9kLXJvdXRpbmctY2ZnICJyb3V0aW5nIiBpcyBhIHRvcCBsZXZlbCBjb250YWluZXIgdGhh
dA0KPmlzIG5vbWluYWxseSBjb25maWcgdHJ1ZS4gIEJ1dCBpdCBpcyBhbHNvIGEgbm9uIHByZXNl
bmNlIGNvbnRhaW5lciwgc28NCj5pdCB3b3VsZCBiZSBhbGxvd2VkIHRvIHB1dCB0aGUgY29uZmln
IGZhbHNlIFJJQiBub2RlcyBkaXJlY3RseSB1bmRlciB0aGUNCj4icm91dGluZyIgY29udGFpbmVy
LiAgR2l2ZW4gdGhhdCAicm91dGluZyIgaXMgYW4gTlAgY29udGFpbmVyLCBpdHMNCj5leGlzdGVu
Y2UgKGUuZy4gdG8gcmVwb3J0IHRoZSBSSUIpIGRvZXNuJ3QgaW1wbHkgdGhhdCByb3V0aW5nIGhh
cyBiZWVuDQo+Y29uZmlndXJlZC4NCj4NCj5JbiBmYWN0IChnaXZlbiB0aGUgcmVjZW50IGRpc2N1
c3Npb24gb24gdGhlIE5FVENPTkYgYWxpYXMpLCBpdCBpcw0KPnF1ZXN0aW9uYWJsZSB3aGF0IGEg
ImNvbmZpZyIgdHJ1ZSBOUCBjb250YWluZXIgYWN0dWFsbHkgbWVhbnMuICBJDQo+c3VzcGVjdCB0
aGF0IHJlYWxseSBpdCBqdXN0IGVuZHMgdXAgYmVpbmcgYSBmaWx0ZXIgYXMgdG8gd2hhdCB0eXBl
IG9mDQo+Y2hpbGQgbm9kZXMgYXJlIGFsbG93ZWQuICBJLmUuIGlmIHRoZSBOUCBjb250YWluZXIg
aXMgY29uZmlnPXRydWUsIHRoZW4NCj5jaGlsZCBub2RlcyBjYW4gYmUgY29uZmlnIHRydWUgb3Ig
Y29uZmlnIGZhbHNlLiBDb252ZXJzZWx5LCBpZiB0aGUgTlANCj5jb250YWluZXIgaXMgY29uZmln
IGZhbHNlIHRoZW4gYW55IGNoaWxkIG5vZGVzIG11c3QgYWxzbyBiZSBjb25maWcgZmFsc2UuDQoN
Cg0KVGhlbiBJIHNlZSBubyBZQU5HIGxhbmd1YWdlIGJhcnJpZXJzIGluIGNvbGxhcHNpbmcgY29u
ZmlnIGFuZCBzdGF0ZSB0cmVlcw0KLSB0aGUgbW9kZWwgcm9vdCBqdXN0IG5lZWRzIHRvIGJlIOKA
nGNvbmZpZyB0cnVl4oCdLg0KDQpUaGFua3MsDQpBY2VlIA0KDQoNCg0KPg0KPlRoYW5rcywNCj5S
b2INCj4NCj4NCj4+DQo+PiBUaGFua3MsDQo+PiBBY2VlDQo+Pg0KPj4NCj4+DQo+Pg0KPj4+IFJv
Yg0KPj4+DQo+Pj4NCj4+Pj4gTGFkYQ0KPj4+Pg0KPj4+Pj4gcmVnYXJkcyBCYWxhenMNCj4+Pj4+
DQo+Pj4+PiAtLSANCj4+Pj4+IEJhbGF6cyBMZW5neWVsICAgICAgICAgICAgICAgICAgICAgICBF
cmljc3NvbiBIdW5nYXJ5IEx0ZC4NCj4+Pj4+IFNlbmlvciBTcGVjaWFsaXN0DQo+Pj4+PiBNb2Jp
bGU6ICszNi03MC0zMzAtNzkwOSAgICAgICAgICAgICAgZW1haWw6DQo+Pj4+PkJhbGF6cy5MZW5n
eWVsQGVyaWNzc29uLmNvbQ0KPj4+Pj4NCj4+Pj4gLS0NCj4+Pj4gTGFkaXNsYXYgTGhvdGthLCBD
Wi5OSUMgTGFicw0KPj4+PiBQR1AgS2V5IElEOiBFNzRFOEMwQw0KPj4+Pg0KPj4+Pg0KPj4+Pg0K
Pj4+Pg0KPj4+PiAuDQo+Pj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+Pj4gbmV0bW9kQGlldGYu
b3JnDQo+Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCj4N
Cg0K


From nobody Fri Aug  5 03:37: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 56FE012B004 for ; Fri,  5 Aug 2016 03:37:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.487
X-Spam-Level: 
X-Spam-Status: No, score=-5.487 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.287] 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 Cv56u_p-sVTA for ; Fri,  5 Aug 2016 03:37:03 -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 B31F012B047 for ; Fri,  5 Aug 2016 03:36:59 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CD0C78DB; Fri,  5 Aug 2016 12:36:57 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id p53DjVBzID9h; Fri,  5 Aug 2016 12:36:51 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri,  5 Aug 2016 12:36:55 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CB3CA2008E; Fri,  5 Aug 2016 12:36:55 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WdXLTL9Sb7Rk; Fri,  5 Aug 2016 12:36:54 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id F1AE22008D; Fri,  5 Aug 2016 12:36:53 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 35E143C0F568; Fri,  5 Aug 2016 12:36:50 +0200 (CEST)
Date: Fri, 5 Aug 2016 12:36:50 +0200
From: Juergen Schoenwaelder 
To: "Clyde Wildes (cwildes)" 
Message-ID: <20160805103650.GA34225@elstar.local>
Mail-Followup-To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" 
References: <20160615152932.GA31216@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] partial review of draft-ietf-netmod-syslog-model-08.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: Fri, 05 Aug 2016 10:37:07 -0000

On Fri, Jul 08, 2016 at 10:37:06PM +0000, Clyde Wildes (cwildes) wrote:
> Juergen,
> 
> Thanks for your detailed review!
> 
> I addressed all of your comments in the latest draft.

Thanks for the update. As my role as a YANG doctoc and someone
generally interested, I took another look at the syslog model.  I
think it has much improved and is close to be done. But of course, I
always find stuff to comment on...

* Document

  Should the title be changed to

    A YANG Data Model for Syslog Configuration

  to match existing YANG RFC names and to indicate that the scope
  is configuration (as stated in the abstract)?

  Why is the term message originator needed? The definition says:

     The term "message originator" is derived from the term "originator"
     as defined in [RFC5424]: an "originator" generates syslog content to
     be carried in a message.

  This does not explain why 'originator' is not good enough and why a
  new term is needed. What the figure in section 3 shows looks pretty
  much as originators as well. (BTW, it might be nice to give figures
  a number and a caption - makes it easier to refer to them.)

  I am also not sure why the term "message distributor" is needed; is
  this not just a 'relay' in the RFC 5424 sense? Or is your message
  distributor a combination of a 'relay' and a 'collector'? I think at
  least some explanation should be given how these terms fit together.
  I also note that the terms "message distributor" and "message
  originator" are never used in the YANG model definition itself; so
  if we can simply use RFC 5424 terms in the introductory part I would
  find that simpler. (I am also not clear whether I would call a Log
  File a Message Distributor as the figure in section 3 suggests; for
  me these are actually what RFC 5424 calls collectors.)

  You wrote "to configure one or more syslog processes" and I wonder
  what you mean with 'syslog processes' here and why you stress
  'multiple'. Is there anything in the data model that was designed
  specifically to support _multiple_ syslog processes? Is syslog
  process here the same as 'message distributor'? If so, use a single
  term; if not, please explain the difference.

  You wrote:

    This module can be used to configure the syslog application
    conceptual layer [RFC5424].

  Is this statement correct? How do I use the data model to configure
  the list of originators shown in section 3?

  You wrote:

    The leaves in the base syslog model log-input-transports container
    correspond to remote message originators or remote message relays.

    The leaves in the base syslog model log-actions container correspond
    to each message distributor:

  I could not find log-input-transports and log-actions anywhere, I
  think renaming has not been reflected in the text yet.

  I would prefer if the examples would be trimmed down to show just
  the XML config and not an entire NETCONF RPC exchange in order to
  reduce noise. Also reduce the number of namespace definitions to the
  minimum needed.

  I am not sure the namespace used in Appendix A.1 is a good idea.
  Perhaps use "http://example.com/ethernet" and in general use
  example.com for example domain names (and not vendor.com) 

* ietf-syslog-types

  Instead of just 'Alert Level Msg' in the description, perhaps write
  full sentence that is more descriptive, e.g.,

    "The severity level 'Alert' indicating that an action must be
    taken immediately."

  Note that Table 2 in RFC 5424 provides phrases describing syslog
  message severities.

* ietf-syslog

  The commented out reference to ietf-tls-client needs to be resolved.

  Is the regular expression matching clearly enough specified? How do
  you deal with flags such as REG_ICASE? Are these what is sometimes
  referred to as extended regular expressions?

  I wonder whether names can be further streamlined, e.g.

  log-selector -> selector
  log-facility -> facility
  no-log-facility -> facility
  facility -> name

  This would turn

           
             
               
                 
                   all
                   critical
                 
               
             
           

  into this
  
           
             
               
                 
                   all
                   critical
                 
               
             
           

  BTW, is the following valid?

           
             
               
                 
                   kern
                   notice
		   equal
                 
                 
                   kern
                   debug
		   equal
                 
               
             
           

  I do not think this is valid but would it not be desirable to
  support multiple filters on the same facility? Good old BSD like
  syslog daemons do understand configurations such as

  kern.notice;kern.debug: |/dev/xconsole

  If my syslog implementation supports structured data, is it a
  reasonable default to remove structured data (default false of
  structured-data)?

  The model allows me to configure limits such as buffer-limit-bytes
  or buffer-limit-messages. Is there a way to obtain the system bounds
  for these limits (if there are any) or is the idea that applications
  determine the limits eventually via trial and error?

  Should 'uses selector;' always be immediately followed by 'uses
  structured-data;'? Sometimes there are other definitions in between,
  sometimes not. On some actions, the uses structured-data; is absent,
  is there any reason why this exists sometimes but not always?

  Is 'log file archiving' the right term? Is this not more commonly
  known as log file rotation? Archiving to me suggests that data is
  kept for a long period of time but log rotation usually only covers
  a couple of days.

  I am not sure I understand destination-facility which defaults to
  syslogtypes:local7. Can I not forward a syslog message to a remote
  destination without messing around with the facility?

  The source-interface description says an IP address can be specified
  which I think is not true (you use type if:interface-ref). I think
  what you are doing is right, the description likely needs an update.

  I suggest to a unit statements to cert-resend-delay, sig-max-delay,
  and sig-resend-delay.

* Editorial

  s/(5)as/(5) as/

  s/admisintrator/administrator/

  s/sprecific/specific/

/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 Aug  8 13:16: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 CDEB812D09C for ; Mon,  8 Aug 2016 13:16:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XSAyM3kFJBoM for ; Mon,  8 Aug 2016 13:16:14 -0700 (PDT)
Received: from NAM01-BY2-obe.outbound.protection.outlook.com (mail-by2nam01on0097.outbound.protection.outlook.com [104.47.34.97]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB15C12B004 for ; Mon,  8 Aug 2016 13:16:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gc3LF86Uk4xk0r8IgtMro90VcbJyHcR0R9E5W0V/J4o=; b=P++rul+M8CMYbBf/UmQUmAtYV/DfhN6M6YJnS2ccKoliBX/Ci2gVjYNiYIhMGx1iDJEhH5DumJpUHE8XXItmpYUJ/E7yz0NFSF1LQNZ8300yu07XI0j0aesW0qJua49YrwmDEoWnSwcoRg8srTB36Tj2PDvjiqRhigrH2EP4Xx0=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1451.namprd05.prod.outlook.com (10.160.149.12) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Mon, 8 Aug 2016 20:16:12 +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.0557.009; Mon, 8 Aug 2016 20:16:12 +0000
From: Kent Watsen 
To: "Acee Lindem (acee)" , "Robert Wilton -X (rwilton - ENSOFT LIMITED at Cisco)" , Ladislav Lhotka , Balazs Lengyel 
Thread-Topic: [netmod] OpsState and Schema-Mount
Thread-Index: AQHR7Nwrg+3BeZANfEqM5r9gczFpmaA2zIQAgAAlNwCAAKDWgIABEGmAgAAzOACABnBxAA==
Date: Mon, 8 Aug 2016 20:16:12 +0000
Message-ID: <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 57ae9d75-493f-43cf-0a94-08d3bfc8d7e6
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1451; 6:HuDlrvLhO1NmlGqCnWAyzSfr46NQWb0iOT5xlKV53yAWx4EKlZDG4C1L3OgzQYAC2HAa6aVB7KRArMGPLQ6sH3+Vv9IqJvmaWAjdZ5keFFzlS/KICkC8E7Mb3P7LCXMAb7gc8q4dF/IJ3buCHnvp33WY596In8WR9GEKMm5AxWhtcfFgVNP6K8BkS5nzGMSf/ESD9zIzsSUXMlsjXzrB+fYrsyPZ9uhj43xmUqAWOS2kA5UBfZrdFHVrDzNmiPnI0nt8N74XSA0DLsRzvlT1CiOywhQs8SBnHSxm0DLrLAuJxCvBPt05yO1Q33t0FJ1KrepHbYnZbcb8PzrDeLJncQ==; 5:dtS20bDRuoswxmFBMBSz0mENCdeB0OIJwmFLN7j4gvPay+geFnU55NsznEl3iUvfE6m5LNXE5jiMnfTtPilSrOnJROq6yW3SjTFzLIVstD+45XjDTghr9YlS79YZ8UKNJygldnyYNzbOWmcihxU8EA==; 24:3tP2IATgbnMH1F4zglfrbX5R5HT0TMcPUWfpn0MDMBDuUOyz8hKJHUmxZbeJWoa208Nv/OEnj7zyhzVS9hG+NHzi2/TObmPEDXXvTICEbwI=; 7:0vnZKqLD1MWIhMe7VdlaEhTt2GazUGOSZom0+uKwBlJlyXunlwYCSc4AOPo9GDWFG2M3jy1nXk5vTGMWyhl5P9L7Q0nKFY6JbAvqf5mNFZaU1RZmm0Uc8kENujEAQ9mVgm27Z6UtkEGlFBglXiLc9k7rcRInQdIhNQX9Bjp+74naEAiYXwN4Wmnrtbm9EZ0qW6OTnd2qYbe638NHCtPjbO26uc0XUp4p+joL9pgmdObvlS064Q6MvUiLm83nch/0
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1451;
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)(6055026);  SRVR:CY1PR0501MB1451; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1451; 
x-forefront-prvs: 00286C0CA6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(81166006)(83506001)(586003)(97736004)(2950100001)(33656002)(82746002)(189998001)(8936002)(81156014)(106116001)(101416001)(93886004)(87936001)(102836003)(4001350100001)(36756003)(8676002)(68736007)(2900100001)(106356001)(561944003)(83716003)(15975445007)(2906002)(11100500001)(19580395003)(5001770100001)(6116002)(10400500002)(3846002)(66066001)(54356999)(86362001)(305945005)(50986999)(575784001)(76176999)(5002640100001)(99286002)(77096005)(105586002)(122556002)(92566002)(4326007)(3280700002)(7736002)(3660700001)(7846002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1451; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2016 20:16:12.5333 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1451
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 08 Aug 2016 20:16:17 -0000

QWNlZSB3cml0ZXM6DQo+ICAgIFRoZW4gSSBzZWUgbm8gWUFORyBsYW5ndWFnZSBiYXJyaWVycyBp
biBjb2xsYXBzaW5nIGNvbmZpZyBhbmQgc3RhdGUgdHJlZXMNCj4gICAgLSB0aGUgbW9kZWwgcm9v
dCBqdXN0IG5lZWRzIHRvIGJlIOKAnGNvbmZpZyB0cnVl4oCdLg0KDQpHcmVhdCwgSSB0aGluayB3
ZeKAmXJlIGFsbCBhZ3JlZWQuICBDYW4gd2Ugbm93IGRpc2N1c3MgdGhlIHRleHQgSSBwcm9wb3Nl
ZCBmb3IgNjA4N2Jpcz8gIC0gaGVyZeKAmXMgdGhlIGxpbmsgdG8gbXkgcHJvcG9zYWw6ICBodHRw
czovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25ldG1vZC8temJYTmh3MkJKWU15ckJU
OW5uQ3dvTEFKMHMuDQoNCkhpbnQ6IHRoZSBmaXJzdCBmZXcgZWRpdHMgYXJlIGp1c3Qgbml0cy4u
LnNraXAgb3ZlciB0aGUgZmlyc3QgZmV3IHBhcmFncmFwaHMgdW50aWwgeW91IHN0YXJ0IHNlZWlu
ZyBsYXJnZSBibG9ja3Mgb2YgY2hhbmdlZCBsaW5lcy4uLg0KDQpLZW50IC8vIGFzIGEgY29udHJp
YnV0b3INCg0KDQoNCg==


From nobody Mon Aug  8 14:51: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 019E112D552 for ; Mon,  8 Aug 2016 14:51:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NYAhzAU6kY8U for ; Mon,  8 Aug 2016 14:51:29 -0700 (PDT)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 C116D12D1B7 for ; Mon,  8 Aug 2016 14:51:28 -0700 (PDT)
Received: by mail-ua0-x234.google.com with SMTP id 74so89588019uau.0 for ; Mon, 08 Aug 2016 14:51:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Kr1DTm15+vcAMnVRA0WCDWharbuJuNaUzevfDH7N57U=; b=TCYGRfSWN5cTa3bmqlTn6v8SuYZ+tkP9UhKhylX07v6tL09d1CUdmYexhthN0arIvA llPPFrNixjRNaa726qbQ2p/oL1jWO+8rDIpyHDEsgumCLZNoHhUnebFRqv6irLVruDXY vQlawveVO8Z2M63JBFLmYMFF97pU4Xv581j51Ey4VFKr0S1X/cFTGAad4gglU4VjaKkI u7zgAiVxPwusiB67Bn1aBKnodJWlFtVUjDMQPTtInabOnZ34lehy2yQfA+/YF9UkjBCX SVfPoRI7e0s2USZTC7lwmv+16qr/k4bp+MU/pn4bOyOZiZo9YsypDdPuhJ9ziZX7cyjB Wc+w==
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:from:date :message-id:subject:to:cc; bh=Kr1DTm15+vcAMnVRA0WCDWharbuJuNaUzevfDH7N57U=; b=j/H9ZWQlxoKjCDszY9SDwPRCILctXSPeQPFn5pl9yLer6P+j2hTSY/AiIqQqN5YR2d a0hLrAXvklA8hNW6KMIKCdwHFX2JprYrFokDHpkGJv2142Z1aXOt5bG8+wQB4HBAMTL9 7c61ut6+P/Z8eq1gxoaeA9RB+CSXYovETL8YiHAyK/6mQ2lBNeY4nd0IDFZaYfx2YMod lH9POZEI+mHocnlGNol8AzO5cqdga1GYkjjOBU+R5e5gW8eHuFNEf+t3ToQPAOIvug7U +YXChGwpuq93GG9g8BU9QFabytem1EQYlVzSlCpu03Z+8nuQMZ/srUIH3Q9m7g4iIKU2 R8Pw==
X-Gm-Message-State: AEkoousozQHs05x2QnUBELlw/t7vwnUM9u8AcHvNw5wUCrb8DPvWJNQMe8UWly6xUKv9JjEww/+p+rn4jDn+DA==
X-Received: by 10.176.3.232 with SMTP id 95mr7501437uau.9.1470693087917; Mon, 08 Aug 2016 14:51:27 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Mon, 8 Aug 2016 14:51:27 -0700 (PDT)
In-Reply-To: <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>
From: Andy Bierman 
Date: Mon, 8 Aug 2016 14:51:27 -0700
Message-ID: 
To: Kent Watsen 
Content-Type: multipart/alternative; boundary=94eb2c056550144ee80539966b70
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 08 Aug 2016 21:51:31 -0000

--94eb2c056550144ee80539966b70
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  wrote:

> Acee writes:
> >    Then I see no YANG language barriers in collapsing config and state
> trees
> >    - the model root just needs to be =E2=80=9Cconfig true=E2=80=9D.
>
> Great, I think we=E2=80=99re all agreed.  Can we now discuss the text I p=
roposed
> for 6087bis?  - here=E2=80=99s the link to my proposal:
> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>
>
IMO this effort to avoid 2 containers is not well thought out.
Some concerns:

1) modularity
    placing the monitoring objects within the configuration means the
monitoring
    cannot be used on its own

2) access control
    placing the monitoring data within configuration means the
monitoring-only clients
    need write permission turned on for the nodes they can access for
read-only
    This relies on granular and complex NACM rules which require regular
maintenance.

3) YANG conformance
    placing the monitoring data inside the configuration means the
configuration
    will be required for conformance; it is not likely to be just 1 NP
container.

4) pointless;
   given that new RPC operations are needed to access applied config, the
only data not
   affected (and moved under the config container anyway) is stuff that
does not share
   the same indexing, or counters which are not part of the opstate problem=
.



Andy


Hint: the first few edits are just nits...skip over the first few
> paragraphs until you start seeing large blocks of changed lines...
>
> Kent // as a contributor
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--94eb2c056550144ee80539966b70
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <kwatsen@juniper.net=
> wrote:
Acee writes:

>=C2=A0 =C2=A0 Then I see no YANG language barriers in collapsing config=
 and state trees

>=C2=A0 =C2=A0 - the model root just needs to be =E2=80=9Cconfig true=E2=
=80=9D.



Great, I think we=E2=80=99re all agreed.=C2=A0 Can we now discuss the text =
I proposed for 6087bis?=C2=A0 - here=E2=80=99s the link to my proposal:=C2=
=A0 https://mailarchive.ietf=
.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.



IMO this effort to avoid 2 containers =
is not well thought out.
Some concerns:

=
1) modularity
=C2=A0 =C2=A0 placing the monitoring objects within=
 the configuration means the monitoring
=C2=A0 =C2=A0 cannot be u=
sed on its own

2) access control
=C2=A0 =
=C2=A0 placing the monitoring data within configuration means the monitorin=
g-only clients
=C2=A0 =C2=A0 need write permission turned on for =
the nodes they can access for read-only
=C2=A0 =C2=A0 This relies=
 on granular and complex NACM rules which require regular maintenance.

3) YANG conformance
=C2=A0 =C2=A0 placing th=
e monitoring data inside the configuration means the configuration
=C2=A0 =C2=A0 will be required for conformance; it is not likely to be ju=
st 1 NP container.=C2=A0

4) pointless;
=
=C2=A0 =C2=A0given that new RPC operations are needed to access applied con=
fig, the only data not
=C2=A0 =C2=A0affected (and moved under the=
 config container anyway) is stuff that does not share
=C2=A0 =C2=
=A0the same indexing, or counters which are not part of the opstate problem=
.



Andy


Hint: the first few edits are just nits...skip over the first few paragraph=
s until you start seeing large blocks of changed lines...



Kent // as a contributor







_______________________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c056550144ee80539966b70--


From nobody Mon Aug  8 16:24: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 6263712B030 for ; Mon,  8 Aug 2016 16:24:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B_BQmNcNFRiK for ; Mon,  8 Aug 2016 16:24:43 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0095.outbound.protection.outlook.com [104.47.41.95]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E0012B012 for ; Mon,  8 Aug 2016 16:24:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=xZEATlkKXy27QyPTJJs1WWwghDA4T5xEA6zvJHG5hK4=; b=gnAfaGeiCsMEjSDZjYfWQ84Tfill5eWR4miC/bZSJsWoPodAxe19gfzYgy7Fhaykq+lePFL1rOe0WAH38ILzf1VPYm5n1TM6yc56H8vbnejv0aF6+5hQgZ6zbgBKrifWyZ/bj/IlwpSuVB0w5YaLDkOWLhARBa+XDDdrxGtDBfU=
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 (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Mon, 8 Aug 2016 23:24:39 +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.0557.009; Mon, 8 Aug 2016 23:24:39 +0000
From: Kent Watsen 
To: Andy Bierman 
Thread-Topic: [netmod] OpsState and Schema-Mount
Thread-Index: AQHR7Nwrg+3BeZANfEqM5r9gczFpmaA2zIQAgAAlNwCAAKDWgIABEGmAgAAzOACABnBxAIAAXauA///W/IA=
Date: Mon, 8 Aug 2016 23:24:39 +0000
Message-ID: <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net>
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 07fb29f4-81d3-4ba3-4af1-08d3bfe32b57
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:YllsjFe2KNZCykTpEkrDXreGZBMDmrzwBnDJTzjr4fqAmKvlxIulJbv/d80P0jvSnPd0HkkgHXA8hYAEIri59gtt7opzoD5lLYEAo4Rj0NR7QwI3/dz0ndFbDDpW+EXuce+gThPuShncu7QE8AKcsJDCs22utjKoaOJMKTuV5E1OyCuKJgH6uCmugXtnqKvMZI378tf5+XRW9ylmAt7CYPsVrb3MqfSUSbqUaXKjKY1tXXv73WxmFnxtDgMvVryt8s0a4GqmfjaqbEtt0zvia11GJ6QGw1LQ30XGa0UjHJjzKxPTZNLWIiBo6douxVi/EXKHQ8sqPLSCeC83T9u0SQ==; 5:l401O9EHJqwzvp/siO7rxoHgOG4dcVbb8CVSSeoTrv9ZpBeH8u8I6kCxaYfH0L/SZLwjDIUbBPUk2rsxL6xEnyA5RHd17/Cvek/4g2kCEOvkAC9JW+hCCdeVA2JYm1EQu5GEYp5whVWWifxsKeV5bQ==; 24:DdNC5zOIFXXN0nTF1GSadHWIjZKHUpMooLELkKPVzEpF5MTaD6k5QizJ631RqhTPu2+oafzYfaktWE4IZGxVa7AZBSCyuhcLf2JbF2Y8RoY=; 7:T8fL51tcI5PJ5CJqfbwFH1q+OnXj/F6aAWmkY5ncSQMGHzDnNkBe5eYzK1DgrDR+dRedu4EAX1OO+N1qGNE2+ePqlf3rNbHqM20YTYrT1L/ZpTAqVKjQ6zqjLNiaixTNASapgIt2rQSSB6mPbkXe2lqGoBoRXDCIliz2kwKxMjbR+rjypPaPHWEKQMxDRFfqiC1v/LaIpvowFywrgMe1a2OQywuvTwc2MHFdLFlkKdHj76HonTr/85LfrYy74b7+
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1452;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(72170088055959)(138986009662008)(95692535739014)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046)(6055026);  SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 00286C0CA6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(24454002)(377454003)(189002)(199003)(66066001)(99286002)(110136002)(83716003)(77096005)(82746002)(189998001)(36756003)(19625215002)(2906002)(83506001)(106116001)(106356001)(2900100001)(97736004)(8936002)(4001350100001)(16236675004)(2950100001)(101416001)(76176999)(33656002)(54356999)(15975445007)(50986999)(87936001)(561944003)(7906003)(586003)(11100500001)(105586002)(81156014)(81166006)(68736007)(7736002)(7846002)(10400500002)(6116002)(102836003)(3846002)(3280700002)(3660700001)(5002640100001)(19300405004)(19617315012)(4326007)(93886004)(92566002)(19580395003)(122556002)(19580405001)(575784001)(86362001)(8676002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_673D423675644B648088BE6CBA3A790Ejunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Aug 2016 23:24:39.4514 (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 WG 
Subject: Re: [netmod] OpsState and 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, 08 Aug 2016 23:24:45 -0000

--_000_673D423675644B648088BE6CBA3A790Ejunipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

Rm9yIDEsMiwzLCByZWFsaXplIHRoYXQgcGxhY2luZyBjb25maWcgZmFsc2Ugbm9kZXMgdW5kZXIg
Y29uZmlnIHRydWUgbm9kZXMgaGFzIGJlZW4gd2l0aCB1cyBmcm9tIHRoZSBiZWdpbm5pbmcuICBB
bGwgdGhlIGlzc3VlcyB5b3UgbWVudGlvbmVkIChpZiB0aGV54oCZcmUgaXNzdWVzIGF0IGFsbCkg
Y2Fu4oCZdCBiZSBuZXcuICAgSGF2aW5nIGEgZHVwbGljYXRlIC1zdGF0ZSB0cmVlIGlzIHRoZSB3
YXJ0IGhlcmUsIGl04oCZcyBpbnRyb2R1Y2luZyBhbiBpbmNvbnNpc3RlbmN5IGluIGhvdyBtb2Rl
bHMgaGF2ZSBiZWVuIHdyaXR0ZW4gZm9yIGEgbG9uZyB0aW1lLiAgSSBwcmVmZXIgdG8gcmVtb3Zl
IHRoZSB3YXJ0IHRoYW4gY2VsZWJyYXRlIGl0Lg0KDQpGb3IgNCwgcmlnaHQsIHRoaXMgZGlzY3Vz
c2lvbiBvbiBzNS4yMyBvZiA2MDg3YmlzIHJlZ2FyZHMgaG93IHRvIGhhbmRsZSBzdGF0ZSBmb3Ig
c3lzdGVtLWdlbmVyYXRlZCBvYmplY3RzIChlLmcuLCBpbnRlcmZhY2VzKS4gIEl0IGlzIG5vdCBk
aXJlY3RseSByZWxhdGVkIHRvIHRoZSBob3cgdG8gcmVwb3J0IGFwcGxpZWQgY29uZmlndXJhdGlv
biBwcm9ibGVtLiAgSXQgaXMgaG93ZXZlciBpbmRpcmVjdGx5IHJlbGF0ZWQsIGluIHRoYXQgYSBo
b2xpc3RpYyBzb2x1dGlvbiBjYW4gYWRkcmVzcyBib3RoLg0KDQpLZW50DQoNCg0KRnJvbTogQW5k
eSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+DQpEYXRlOiBNb25kYXksIEF1Z3VzdCA4LCAy
MDE2IGF0IDU6NTEgUE0NClRvOiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkNj
OiAiQWNlZSBMaW5kZW0gKGFjZWUpIiA8YWNlZUBjaXNjby5jb20+LCAiUm9iZXJ0IFdpbHRvbiAt
WCAocndpbHRvbiAtIEVOU09GVCBMSU1JVEVEIGF0IENpc2NvKSIgPHJ3aWx0b25AY2lzY28uY29t
PiwgTGFkaXNsYXYgTGhvdGthIDxsaG90a2FAbmljLmN6PiwgQmFsYXpzIExlbmd5ZWwgPGJhbGF6
cy5sZW5neWVsQGVyaWNzc29uLmNvbT4sICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5v
cmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gT3BzU3RhdGUgYW5kIFNjaGVtYS1Nb3VudA0KDQoN
Cg0KT24gTW9uLCBBdWcgOCwgMjAxNiBhdCAxOjE2IFBNLCBLZW50IFdhdHNlbiA8a3dhdHNlbkBq
dW5pcGVyLm5ldDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KQWNlZSB3cml0
ZXM6DQo+ICAgIFRoZW4gSSBzZWUgbm8gWUFORyBsYW5ndWFnZSBiYXJyaWVycyBpbiBjb2xsYXBz
aW5nIGNvbmZpZyBhbmQgc3RhdGUgdHJlZXMNCj4gICAgLSB0aGUgbW9kZWwgcm9vdCBqdXN0IG5l
ZWRzIHRvIGJlIOKAnGNvbmZpZyB0cnVl4oCdLg0KDQpHcmVhdCwgSSB0aGluayB3ZeKAmXJlIGFs
bCBhZ3JlZWQuICBDYW4gd2Ugbm93IGRpc2N1c3MgdGhlIHRleHQgSSBwcm9wb3NlZCBmb3IgNjA4
N2Jpcz8gIC0gaGVyZeKAmXMgdGhlIGxpbmsgdG8gbXkgcHJvcG9zYWw6ICBodHRwczovL21haWxh
cmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25ldG1vZC8temJYTmh3MkJKWU15ckJUOW5uQ3dvTEFK
MHMuDQoNCklNTyB0aGlzIGVmZm9ydCB0byBhdm9pZCAyIGNvbnRhaW5lcnMgaXMgbm90IHdlbGwg
dGhvdWdodCBvdXQuDQpTb21lIGNvbmNlcm5zOg0KDQoxKSBtb2R1bGFyaXR5DQogICAgcGxhY2lu
ZyB0aGUgbW9uaXRvcmluZyBvYmplY3RzIHdpdGhpbiB0aGUgY29uZmlndXJhdGlvbiBtZWFucyB0
aGUgbW9uaXRvcmluZw0KICAgIGNhbm5vdCBiZSB1c2VkIG9uIGl0cyBvd24NCg0KMikgYWNjZXNz
IGNvbnRyb2wNCiAgICBwbGFjaW5nIHRoZSBtb25pdG9yaW5nIGRhdGEgd2l0aGluIGNvbmZpZ3Vy
YXRpb24gbWVhbnMgdGhlIG1vbml0b3Jpbmctb25seSBjbGllbnRzDQogICAgbmVlZCB3cml0ZSBw
ZXJtaXNzaW9uIHR1cm5lZCBvbiBmb3IgdGhlIG5vZGVzIHRoZXkgY2FuIGFjY2VzcyBmb3IgcmVh
ZC1vbmx5DQogICAgVGhpcyByZWxpZXMgb24gZ3JhbnVsYXIgYW5kIGNvbXBsZXggTkFDTSBydWxl
cyB3aGljaCByZXF1aXJlIHJlZ3VsYXIgbWFpbnRlbmFuY2UuDQoNCjMpIFlBTkcgY29uZm9ybWFu
Y2UNCiAgICBwbGFjaW5nIHRoZSBtb25pdG9yaW5nIGRhdGEgaW5zaWRlIHRoZSBjb25maWd1cmF0
aW9uIG1lYW5zIHRoZSBjb25maWd1cmF0aW9uDQogICAgd2lsbCBiZSByZXF1aXJlZCBmb3IgY29u
Zm9ybWFuY2U7IGl0IGlzIG5vdCBsaWtlbHkgdG8gYmUganVzdCAxIE5QIGNvbnRhaW5lci4NCg0K
NCkgcG9pbnRsZXNzOw0KICAgZ2l2ZW4gdGhhdCBuZXcgUlBDIG9wZXJhdGlvbnMgYXJlIG5lZWRl
ZCB0byBhY2Nlc3MgYXBwbGllZCBjb25maWcsIHRoZSBvbmx5IGRhdGEgbm90DQogICBhZmZlY3Rl
ZCAoYW5kIG1vdmVkIHVuZGVyIHRoZSBjb25maWcgY29udGFpbmVyIGFueXdheSkgaXMgc3R1ZmYg
dGhhdCBkb2VzIG5vdCBzaGFyZQ0KICAgdGhlIHNhbWUgaW5kZXhpbmcsIG9yIGNvdW50ZXJzIHdo
aWNoIGFyZSBub3QgcGFydCBvZiB0aGUgb3BzdGF0ZSBwcm9ibGVtLg0KDQoNCg0KQW5keQ0KDQoN
CkhpbnQ6IHRoZSBmaXJzdCBmZXcgZWRpdHMgYXJlIGp1c3Qgbml0cy4uLnNraXAgb3ZlciB0aGUg
Zmlyc3QgZmV3IHBhcmFncmFwaHMgdW50aWwgeW91IHN0YXJ0IHNlZWluZyBsYXJnZSBibG9ja3Mg
b2YgY2hhbmdlZCBsaW5lcy4uLg0KDQpLZW50IC8vIGFzIGEgY29udHJpYnV0b3INCg0KDQoNCl9f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFp
bGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBz
Oi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==

--_000_673D423675644B648088BE6CBA3A790Ejunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <0CA174F20A1F8A4B8C17CF2333EDD142@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWls
eTpNaW5nTGlVOw0KCXBhbm9zZS0xOjIgMiA1IDkgMCAwIDAgMCAwIDA7fQ0KLyogU3R5bGUgRGVm
aW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7
bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsN
Cglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJs
aW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3Jh
dGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJ
e21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9u
OnVuZGVybGluZTt9DQpzcGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25h
bC1yZXBseTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bh
bi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6
IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBE
ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7
fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp
biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkZvciAxLDIsMywgcmVhbGl6ZSB0aGF0IHBsYWNpbmcgY29u
ZmlnIGZhbHNlIG5vZGVzIHVuZGVyIGNvbmZpZyB0cnVlIG5vZGVzIGhhcyBiZWVuIHdpdGggdXMg
ZnJvbSB0aGUgYmVnaW5uaW5nLiZuYnNwOyBBbGwgdGhlIGlzc3VlcyB5b3UgbWVudGlvbmVkIChp
ZiB0aGV54oCZcmUgaXNzdWVzIGF0IGFsbCkgY2Fu4oCZdCBiZSBuZXcuJm5ic3A7Jm5ic3A7DQog
SGF2aW5nIGEgZHVwbGljYXRlIC1zdGF0ZSB0cmVlIGlzIHRoZSB3YXJ0IGhlcmUsIGl04oCZcyBp
bnRyb2R1Y2luZyBhbiBpbmNvbnNpc3RlbmN5IGluIGhvdyBtb2RlbHMgaGF2ZSBiZWVuIHdyaXR0
ZW4gZm9yIGEgbG9uZyB0aW1lLiZuYnNwOyBJIHByZWZlciB0byByZW1vdmUgdGhlIHdhcnQgdGhh
biBjZWxlYnJhdGUgaXQuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+Rm9yIDQsIHJpZ2h0LCB0
aGlzIGRpc2N1c3Npb24gb24gczUuMjMgb2YgNjA4N2JpcyByZWdhcmRzIGhvdyB0byBoYW5kbGUg
c3RhdGUgZm9yIHN5c3RlbS1nZW5lcmF0ZWQgb2JqZWN0cyAoZS5nLiwgaW50ZXJmYWNlcykuJm5i
c3A7IEl0IGlzIG5vdCBkaXJlY3RseSByZWxhdGVkIHRvIHRoZSBob3cgdG8gcmVwb3J0IGFwcGxp
ZWQgY29uZmlndXJhdGlvbg0KIHByb2JsZW0uJm5ic3A7IEl0IGlzIGhvd2V2ZXIgaW5kaXJlY3Rs
eSByZWxhdGVkLCBpbiB0aGF0IGEgaG9saXN0aWMgc29sdXRpb24gY2FuIGFkZHJlc3MgYm90aC48
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5LZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6Q2FsaWJyaSI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9y
ZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7
Y29sb3I6YmxhY2siPkZyb206IDwvc3Bhbj4NCjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
Q2FsaWJyaTtjb2xvcjpibGFjayI+QW5keSBCaWVybWFuICZsdDthbmR5QHl1bWF3b3Jrcy5jb20m
Z3Q7PGJyPg0KPGI+RGF0ZTogPC9iPk1vbmRheSwgQXVndXN0IDgsIDIwMTYgYXQgNTo1MSBQTTxi
cj4NCjxiPlRvOiA8L2I+S2VudCBXYXRzZW4gJmx0O2t3YXRzZW5AanVuaXBlci5uZXQmZ3Q7PGJy
Pg0KPGI+Q2M6IDwvYj4mcXVvdDtBY2VlIExpbmRlbSAoYWNlZSkmcXVvdDsgJmx0O2FjZWVAY2lz
Y28uY29tJmd0OywgJnF1b3Q7Um9iZXJ0IFdpbHRvbiAtWCAocndpbHRvbiAtIEVOU09GVCBMSU1J
VEVEIGF0IENpc2NvKSZxdW90OyAmbHQ7cndpbHRvbkBjaXNjby5jb20mZ3Q7LCBMYWRpc2xhdiBM
aG90a2EgJmx0O2xob3RrYUBuaWMuY3omZ3Q7LCBCYWxhenMgTGVuZ3llbCAmbHQ7YmFsYXpzLmxl
bmd5ZWxAZXJpY3Nzb24uY29tJmd0OywgJnF1b3Q7bmV0bW9kQGlldGYub3JnJnF1b3Q7ICZsdDtu
ZXRtb2RAaWV0Zi5vcmcmZ3Q7PGJyPg0KPGI+U3ViamVjdDogPC9iPlJlOiBbbmV0bW9kXSBPcHNT
dGF0ZSBhbmQgU2NoZW1hLU1vdW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIE1vbiwgQXVnIDgsIDIwMTYgYXQgMToxNiBQ
TSwgS2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0IiB0
YXJnZXQ9Il9ibGFuayI+a3dhdHNlbkBqdW5pcGVyLm5ldDwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlk
ICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0Ljhw
dDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
Ym90dG9tOjEyLjBwdCI+QWNlZSB3cml0ZXM6PGJyPg0KJmd0OyZuYnNwOyAmbmJzcDsgVGhlbiBJ
IHNlZSBubyBZQU5HIGxhbmd1YWdlIGJhcnJpZXJzIGluIGNvbGxhcHNpbmcgY29uZmlnIGFuZCBz
dGF0ZSB0cmVlczxicj4NCiZndDsmbmJzcDsgJm5ic3A7IC0gdGhlIG1vZGVsIHJvb3QganVzdCBu
ZWVkcyB0byBiZSDigJxjb25maWcgdHJ1ZeKAnS48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6TWlu
Z0xpVSI+PGJyPg0KPGJyPg0KPC9zcGFuPkdyZWF0LCBJIHRoaW5rIHdl4oCZcmUgYWxsIGFncmVl
ZC4mbmJzcDsgQ2FuIHdlIG5vdyBkaXNjdXNzIHRoZSB0ZXh0IEkgcHJvcG9zZWQgZm9yIDYwODdi
aXM/Jm5ic3A7IC0gaGVyZeKAmXMgdGhlIGxpbmsgdG8gbXkgcHJvcG9zYWw6Jm5ic3A7DQo8YSBo
cmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25ldG1vZC8temJYTmh3
MkJKWU15ckJUOW5uQ3dvTEFKMHMiIHRhcmdldD0iX2JsYW5rIj4NCmh0dHBzOi8vbWFpbGFyY2hp
dmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0bW9kLy16YlhOaHcyQkpZTXlyQlQ5bm5Dd29MQUowczwv
YT4uPG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5JTU8gdGhpcyBlZmZvcnQgdG8gYXZvaWQgMiBjb250YWluZXJzIGlzIG5vdCB3ZWxs
IHRob3VnaHQgb3V0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+U29tZSBjb25jZXJuczo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+MSkgbW9kdWxhcml0eTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBwbGFjaW5nIHRoZSBt
b25pdG9yaW5nIG9iamVjdHMgd2l0aGluIHRoZSBjb25maWd1cmF0aW9uIG1lYW5zIHRoZSBtb25p
dG9yaW5nPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij4mbmJzcDsgJm5ic3A7IGNhbm5vdCBiZSB1c2VkIG9uIGl0cyBvd248bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+MikgYWNjZXNzIGNvbnRyb2w8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OyAmbmJzcDsgcGxhY2luZyB0aGUgbW9uaXRvcmluZyBkYXRhIHdpdGhpbiBjb25maWd1cmF0aW9u
IG1lYW5zIHRoZSBtb25pdG9yaW5nLW9ubHkgY2xpZW50czxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyBuZWVkIHdyaXRlIHBl
cm1pc3Npb24gdHVybmVkIG9uIGZvciB0aGUgbm9kZXMgdGhleSBjYW4gYWNjZXNzIGZvciByZWFk
LW9ubHk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PiZuYnNwOyAmbmJzcDsgVGhpcyByZWxpZXMgb24gZ3JhbnVsYXIgYW5kIGNvbXBsZXggTkFDTSBy
dWxlcyB3aGljaCByZXF1aXJlIHJlZ3VsYXIgbWFpbnRlbmFuY2UuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N
CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjMpIFlBTkcgY29uZm9ybWFuY2U8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNw
OyAmbmJzcDsgcGxhY2luZyB0aGUgbW9uaXRvcmluZyBkYXRhIGluc2lkZSB0aGUgY29uZmlndXJh
dGlvbiBtZWFucyB0aGUgY29uZmlndXJhdGlvbjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyB3aWxsIGJlIHJlcXVpcmVkIGZv
ciBjb25mb3JtYW5jZTsgaXQgaXMgbm90IGxpa2VseSB0byBiZSBqdXN0IDEgTlAgY29udGFpbmVy
LiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj40KSBwb2ludGxlc3M7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Z2l2ZW4gdGhhdCBuZXcgUlBDIG9wZXJhdGlvbnMg
YXJlIG5lZWRlZCB0byBhY2Nlc3MgYXBwbGllZCBjb25maWcsIHRoZSBvbmx5IGRhdGEgbm90PG86
cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsg
Jm5ic3A7YWZmZWN0ZWQgKGFuZCBtb3ZlZCB1bmRlciB0aGUgY29uZmlnIGNvbnRhaW5lciBhbnl3
YXkpIGlzIHN0dWZmIHRoYXQgZG9lcyBub3Qgc2hhcmU8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDt0aGUgc2FtZSBpbmRleGlu
Zywgb3IgY291bnRlcnMgd2hpY2ggYXJlIG5vdCBwYXJ0IG9mIHRoZSBvcHN0YXRlIHByb2JsZW0u
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij5BbmR5PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0iYm9y
ZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgI0NDQ0NDQyAxLjBwdDtwYWRkaW5nOjBpbiAwaW4g
MGluIDYuMHB0O21hcmdpbi1sZWZ0OjQuOHB0O21hcmdpbi1yaWdodDowaW4iPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+SGludDogdGhlIGZpcnN0IGZldyBlZGl0cyBhcmUganVzdCBuaXRzLi4uc2tp
cCBvdmVyIHRoZSBmaXJzdCBmZXcgcGFyYWdyYXBocyB1bnRpbCB5b3Ugc3RhcnQgc2VlaW5nIGxh
cmdlIGJsb2NrcyBvZiBjaGFuZ2VkIGxpbmVzLi4uPGJyPg0KPGJyPg0KS2VudCAvLyBhcyBhIGNv
bnRyaWJ1dG9yPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX188YnI+DQpuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGEg
aHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4NCjxh
IGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIiB0YXJn
ZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q8
L2E+PG86cD48L286cD48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k
aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_673D423675644B648088BE6CBA3A790Ejunipernet_--


From nobody Mon Aug  8 16:30: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 C8DBA12D0EE for ; Mon,  8 Aug 2016 16:30:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X8sCCY0CiFEe for ; Mon,  8 Aug 2016 16:30:54 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5244F12B074 for ; Mon,  8 Aug 2016 16:30:54 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id 97so42791898uav.3 for ; Mon, 08 Aug 2016 16:30:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=QroEQV134eNQshREY4OjhyrwnN39HMWL0Hm5d38yrEw=; b=PFDHg/kdzP7hXtMUlg0VNMaLwdm29ffeBeKbFcGhde1CyzJF6nZYAzY82QBtQRBWqj tQVn302mLcOeDj+fcD+R1ctMMlFVLnfVooxNMcLtgPRPzHUy63J7ALh29LcIlUjq4/Rm hFGu6HvnIUjo39RaF2cm9KkPldGP4UcomLvZYdhRP60Ez/H+ptlHxytfwwO/tutxsCCU m5sE1mmXGPgDlKmTgVin6VsVlsLJ1WfZghHoLNT9SqIHC8LHSXCxlaefWH/yLzqQj/cT E9NDA2LAnEknubKgb2ja8g4mxzbL5Kmw7jhw7ssrhh4rgDBBTI7jnnqG7RruxYGi+OSr 2VfQ==
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:from:date :message-id:subject:to:cc; bh=QroEQV134eNQshREY4OjhyrwnN39HMWL0Hm5d38yrEw=; b=QaiQae5nw3oaNlCIYM9YJzc/S8c09jAaYGd8GzZfI3ilfOW6Gm9e3ZJj4+jl346Gwp LB+z5mTb9FmceAfZUI51mWK8QsOER354/ZmzNoaKjdxU9FoA4ke6+5N2A/m+6IUJEyO6 EBAVumNKEz+QHBdWQinQF2AwIgI5sEdkjXHt6mBkdNrmNJ7McbfeqcQ02UI4ye/NnJxW bO1tBOLPx2eHob9q/E7hzL6lTqWot9hhmDT7Y0ljHL1wHcUK55kN/KWEpIYizWXakp9y 9YfWe3qhgcXBVh19F5D+FytybISMzVpzR/9Lxw0rEwLid0O3vIGSgJwUUWEv9+URIH9O xqMQ==
X-Gm-Message-State: AEkooutzY+YlguvMpknX4i2jwg/7UVylTJ068xvH9yXoEiFQh4V5d+MKvsaC7Q8DMTG3Fb3gOJcGY7kQtaXs/w==
X-Received: by 10.176.69.168 with SMTP id u37mr1548337uau.16.1470699053464; Mon, 08 Aug 2016 16:30:53 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Mon, 8 Aug 2016 16:30:52 -0700 (PDT)
In-Reply-To: <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net>
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net>
From: Andy Bierman 
Date: Mon, 8 Aug 2016 16:30:52 -0700
Message-ID: 
To: Kent Watsen 
Content-Type: multipart/alternative; boundary=94eb2c11c9e6a75a75053997cee6
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 08 Aug 2016 23:30:57 -0000

--94eb2c11c9e6a75a75053997cee6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen  wrote:

> For 1,2,3, realize that placing config false nodes under config true node=
s
> has been with us from the beginning.  All the issues you mentioned (if
> they=E2=80=99re issues at all) can=E2=80=99t be new.   Having a duplicate=
 -state tree is
> the wart here, it=E2=80=99s introducing an inconsistency in how models ha=
ve been
> written for a long time.  I prefer to remove the wart than celebrate it.
>
>
>

No, it actually is not the way we have been doing things all along.
Historically (even with NETCONF, not just SNMP) we standardize
read-only monitoring information.  Sometimes configuration is added later.

Issues 1 - 3 are practical issues that need to be addressed if top-level
config=3Dfalse
nodes are not allowed anymore.


Andy



> For 4, right, this discussion on s5.23 of 6087bis regards how to handle
> state for system-generated objects (e.g., interfaces).  It is not directl=
y
> related to the how to report applied configuration problem.  It is howeve=
r
> indirectly related, in that a holistic solution can address both.
>
>
>
> Kent
>
>
>
>
>
> *From: *Andy Bierman 
> *Date: *Monday, August 8, 2016 at 5:51 PM
> *To: *Kent Watsen 
> *Cc: *"Acee Lindem (acee)" , "Robert Wilton -X (rwilton -
> ENSOFT LIMITED at Cisco)" , Ladislav Lhotka <
> lhotka@nic.cz>, Balazs Lengyel , "
> netmod@ietf.org" 
> *Subject: *Re: [netmod] OpsState and Schema-Mount
>
>
>
>
>
>
>
> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  wrote:
>
> Acee writes:
> >    Then I see no YANG language barriers in collapsing config and state
> trees
> >    - the model root just needs to be =E2=80=9Cconfig true=E2=80=9D.
>
> Great, I think we=E2=80=99re all agreed.  Can we now discuss the text I p=
roposed
> for 6087bis?  - here=E2=80=99s the link to my proposal:
> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>
>
>
> IMO this effort to avoid 2 containers is not well thought out.
>
> Some concerns:
>
>
>
> 1) modularity
>
>     placing the monitoring objects within the configuration means the
> monitoring
>
>     cannot be used on its own
>
>
>
> 2) access control
>
>     placing the monitoring data within configuration means the
> monitoring-only clients
>
>     need write permission turned on for the nodes they can access for
> read-only
>
>     This relies on granular and complex NACM rules which require regular
> maintenance.
>
>
>
> 3) YANG conformance
>
>     placing the monitoring data inside the configuration means the
> configuration
>
>     will be required for conformance; it is not likely to be just 1 NP
> container.
>
>
>
> 4) pointless;
>
>    given that new RPC operations are needed to access applied config, the
> only data not
>
>    affected (and moved under the config container anyway) is stuff that
> does not share
>
>    the same indexing, or counters which are not part of the opstate
> problem.
>
>
>
>
>
>
>
> Andy
>
>
>
>
>
> Hint: the first few edits are just nits...skip over the first few
> paragraphs until you start seeing large blocks of changed lines...
>
> Kent // as a contributor
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>
>

--94eb2c11c9e6a75a75053997cee6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen <kwatsen@juniper.net=
> wrote:













For 1,2,3, realize that placing config false nodes under config true nodes=
 has been with us from the beginning.=C2=A0 All the issues you mentioned (i=
f they=E2=80=99re issues at all) can=E2=80=99t be new.=C2=A0=C2=A0
 Having a duplicate -state tree is the wart here, it=E2=80=99s introducing =
an inconsistency in how models have been written for a long time.=C2=A0 I p=
refer to remove the wart than celebrate it.


=C2=A0

No, i=
t actually is not the way we have been doing things all along.
Hi=
storically (even with NETCONF, not just SNMP) we standardize
read=
-only monitoring information.=C2=A0 Sometimes configuration is added later.=


Issues 1 - 3 are practical issues that need to be=
 addressed if top-level config=3Dfalse
nodes are not allowed anym=
ore.


Andy

=
=C2=A0


For 4, right, this discussion on s5.23 of 6087bis regards how to handle st=
ate for system-generated objects (e.g., interfaces).=C2=A0 It is not direct=
ly related to the how to report applied configuration
 problem.=C2=A0 It is however indirectly related, in that a holistic soluti=
on can address both.


=C2=A0


Kent


=C2=A0


=C2=A0




F=
rom: 
Andy Bierman <andy@yumaworks.com>=
;

Date: Monday, August 8, 2016 at 5:51 PM

To: Kent Watsen <kwatsen@juniper.net>

Cc: "Acee Lindem (acee)" <acee@cisco.com>, "Robert Wilton -X (rwil=
ton - ENSOFT LIMITED at Cisco)" <rwilton@cisco.com>, Ladislav Lhotka <lhotka@nic.cz>, Balazs L=
engyel <balazs.lengyel@ericsson.com>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] OpsState and Schema-Mount=







=C2=A0










=C2=A0




=C2=A0




On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen <kwatsen@juniper.net> wrote:




Acee writes:

>=C2=A0 =C2=A0 Then I see no YANG language barriers in collapsing config=
 and state trees

>=C2=A0 =C2=A0 - the model root just needs to be =E2=80=9Cconfig true=E2=
=80=9D.



Great, I think we=E2=80=99re all agreed.=C2=A0 Can we now discuss th=
e text I proposed for 6087bis?=C2=A0 - here=E2=80=99s the link to my propos=
al:=C2=A0

https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnC=
woLAJ0s.






=C2=A0






IMO this effort to avoid 2 containers is not well th=
ought out.






Some concerns:






=C2=A0






1) modularity






=C2=A0 =C2=A0 placing the monitoring objects within =
the configuration means the monitoring






=C2=A0 =C2=A0 cannot be used on its own






=C2=A0






2) access control






=C2=A0 =C2=A0 placing the monitoring data within con=
figuration means the monitoring-only clients






=C2=A0 =C2=A0 need write permission turned on for th=
e nodes they can access for read-only






=C2=A0 =C2=A0 This relies on granular and complex NA=
CM rules which require regular maintenance.






=C2=A0






3) YANG conformance






=C2=A0 =C2=A0 placing the monitoring data inside the=
 configuration means the configuration






=C2=A0 =C2=A0 will be required for conformance; it i=
s not likely to be just 1 NP container.=C2=A0






=C2=A0






4) pointless;






=C2=A0 =C2=A0given that new RPC operations are neede=
d to access applied config, the only data not






=C2=A0 =C2=A0affected (and moved under the config co=
ntainer anyway) is stuff that does not share






=C2=A0 =C2=A0the same indexing, or counters which ar=
e not part of the opstate problem.






=C2=A0






=C2=A0






=C2=A0






Andy






=C2=A0






=C2=A0






Hint: the first few edits are just nits...skip over =
the first few paragraphs until you start seeing large blocks of changed lin=
es...



Kent // as a contributor







_______________________________________________

netmod mailing list

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






=C2=A0


















--94eb2c11c9e6a75a75053997cee6--


From nobody Mon Aug  8 22:46:40 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 5FA3D12D08C; Mon,  8 Aug 2016 14:35:28 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
From: Liaison Statement Management Tool 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147069212837.32181.3094970359014067018.idtracker@ietfa.amsl.com>
Date: Mon, 08 Aug 2016 14:35:28 -0700
Archived-At: 
X-Mailman-Approved-At: Mon, 08 Aug 2016 22:46:39 -0700
Cc: =?utf-8?q?Configuration_Discussion_List=22_=3Cnetconf=40ietf=2Eorg=3E=2C_?=@ietfa.amsl.com, =?utf-8?q?_=3Cdavid=2Esinicrope=40ericsson=2Ecom=3E=2C_=22Mahesh_Jethananda?=@ietfa.amsl.com, =?utf-8?q?university=2Ede=3E=2C_=22Joel_Jaeggli=22_=3Cjoelja=40bogus=2Ecom?=@ietfa.amsl.com, =?utf-8?b?IkrDvHJnZW4gU2Now7Zud8OkbGRlciIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMt?=@ietfa.amsl.com, =?utf-8?b?IkxvdSBCZXJnZXIiIDxsYmVyZ2VyQGxhYm4ubmV0PiwgIk5FVENPTkYgRGF0?=@ietfa.amsl.com, =?utf-8?q?ehmet=2Eersue=40nokia=2Ecom=3E?=@ietfa.amsl.com, =?utf-8?q?eau=22_=3Ctnadeau=40lucidvision=2Ecom=3E=2C_=22David_Sinicrope=22?=@ietfa.amsl.com, =?utf-8?b?LCAiQmVub2l0IENsYWlzZSIgPGJjbGFpc2VAY2lzY28uY29tPiwgIk5ldHdvcmsg?=@ietfa.amsl.com, =?utf-8?b?PiwgIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4sICJUb20gTmFk?=@ietfa.amsl.com, =?utf-8?q?a_Modeling_Language_Discussion_List=22_=3Cnetmod=40ietf=2Eorg=3E?=@ietfa.amsl.com, =?utf-8?b?bmkiIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4sICJNZWhtZXQgRXJzdWUiIDxt?=@ietfa.amsl.com
Subject: [netmod] New Liaison Statement, "In Response to Liaison to IETF on YANG Models to enable G.fast deployments"
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, 08 Aug 2016 21:35:28 -0000

Title: In Response to Liaison to IETF on YANG Models to enable G.fast deployments
Submission Date: 2016-08-08
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1488/

From: "Benoit Claise" 
To: michael.fargano@centurylink.com
Cc: Joel Jaeggli ,Mahesh Jethanandani ,David Sinicrope ,Mehmet Ersue ,NETCONF Data Modeling Language Discussion List ,Kent Watsen ,Lou Berger ,Benoit Claise ,Network Configuration Discussion List ,
Response Contacts: Jürgen Schönwälder , Tom Nadeau ,Mahesh Jethanandani ,Mehmet Ersue 
Technical Contacts: 
Purpose: In response

Referenced liaison: Liaison to IETF on YANG Models to enable G.fast deployments (https://datatracker.ietf.org/liaison/1476/)

Body: Dear all,

The NETMOD and NETCONF WGs thank you for referencing the work of the
IETF and contributing to the drafts you mention through the IETF
process. This is by far the best way to complete the work in a timely
manner and continues to foster the open and cooperative working
relationship between the IETF and the Broadband Forum.

In the mean time, the two drafts you note became WG documents:
draft-ietf-netmod-entity and draft-ietf-netmod-intf-ext-yang-00. We
encourage you to follow progress on data tracker
https://datatracker.ietf.org/doc/draft-ietf-netmod-intf-ext-yang/ and
https://datatracker.ietf.org/doc/draft-ietf-netmod-entity/ and through
the participation you have noted.

Regarding your interest to work on "forwarding/QoS and required
protocols (e.g. layer 2 multicast model & DHCP)", please note that there
are already a couple of forwarding related YANG data models, mainly L3
forwarding. There is also a QoS related YANG data model,
draft-asechoud-netmod-qos-model, which we believe could become a WG
document. And finally, a YANG multicast design team,
https://trac.tools.ietf.org/wg/pim/trac/wiki/yang, focuses on producing
PIM and IGMP/MLD YANG data models. Please work with the respective
contributors so that the layer 2 specific data model aspects nicely fit
in the overall data models.

If you have interest in other related IETF work please don't hesitate to
let us know.

Please continue to keep us apprised of your work noted.
Attachments:

No document has been attached


From nobody Tue Aug  9 04: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 AF33612D779 for ; Tue,  9 Aug 2016 04:34:18 -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 LR3ahB4WQ7Iw for ; Tue,  9 Aug 2016 04:34:16 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2DBA712D75F for ; Tue,  9 Aug 2016 04:34:15 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 1B26C1CC00D1; Tue,  9 Aug 2016 13:34:27 +0200 (CEST)
From: Ladislav Lhotka 
To: Kent Watsen , Andy Bierman 
In-Reply-To: <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net>
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 09 Aug 2016 13:34:17 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 09 Aug 2016 11:34:19 -0000

Kent Watsen  writes:

> For 1,2,3, realize that placing config false nodes under config true
> nodes has been with us from the beginning.  All the issues you
> mentioned (if they=E2=80=99re issues at all) can=E2=80=99t be new.   Havi=
ng a
> duplicate -state tree is the wart here, it=E2=80=99s introducing an
> inconsistency in how models have been written for a long time.  I
> prefer to remove the wart than celebrate it.

Before making changes to the existing models, I'd love to see a
(proposal of a) complete solution. Just moving the config false stuff
from foo-state to foo doesn't help at all.

Lada

>
> For 4, right, this discussion on s5.23 of 6087bis regards how to handle s=
tate for system-generated objects (e.g., interfaces).  It is not directly r=
elated to the how to report applied configuration problem.  It is however i=
ndirectly related, in that a holistic solution can address both.
>
> Kent
>
>
> From: Andy Bierman 
> Date: Monday, August 8, 2016 at 5:51 PM
> To: Kent Watsen 
> Cc: "Acee Lindem (acee)" , "Robert Wilton -X (rwilton - E=
NSOFT LIMITED at Cisco)" , Ladislav Lhotka , Balazs Lengyel , "netmod@ietf.org" 
> Subject: Re: [netmod] OpsState and Schema-Mount
>
>
>
> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen > wrote:
> Acee writes:
>>    Then I see no YANG language barriers in collapsing config and state t=
rees
>>    - the model root just needs to be =E2=80=9Cconfig true=E2=80=9D.
>
> Great, I think we=E2=80=99re all agreed.  Can we now discuss the text I p=
roposed for 6087bis?  - here=E2=80=99s the link to my proposal:  https://ma=
ilarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>
> IMO this effort to avoid 2 containers is not well thought out.
> Some concerns:
>
> 1) modularity
>     placing the monitoring objects within the configuration means the mon=
itoring
>     cannot be used on its own
>
> 2) access control
>     placing the monitoring data within configuration means the monitoring=
-only clients
>     need write permission turned on for the nodes they can access for rea=
d-only
>     This relies on granular and complex NACM rules which require regular =
maintenance.
>
> 3) YANG conformance
>     placing the monitoring data inside the configuration means the config=
uration
>     will be required for conformance; it is not likely to be just 1 NP co=
ntainer.
>
> 4) pointless;
>    given that new RPC operations are needed to access applied config, the=
 only data not
>    affected (and moved under the config container anyway) is stuff that d=
oes not share
>    the same indexing, or counters which are not part of the opstate probl=
em.
>
>
>
> Andy
>
>
> Hint: the first few edits are just nits...skip over the first few paragra=
phs until you start seeing large blocks of changed lines...
>
> Kent // as a contributor
>
>
>
> _______________________________________________
> 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 Aug  9 05: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 B491312B01E for ; Tue,  9 Aug 2016 05:24:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Level: 
X-Spam-Status: No, score=-15.768 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=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b7StzhgSWgz3 for ; Tue,  9 Aug 2016 05:24:28 -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 E6B9D12D5BD for ; Tue,  9 Aug 2016 05:24:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13184; q=dns/txt; s=iport; t=1470745468; x=1471955068; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=TKmR/bnDiPTmihaVAc4wxDZR8c55tsUfn6zujjIjwW8=; b=mFImfNMQmcq/BtW7kFvZ60zPYUAWvKKyqYlIdQWpm2UfQyfuIMDsazPj FQMjiLhZIbmRN3NW06n+fE9cCtrUqqaHErcXjLToeifOn4PdoUleRcTQY 3jWQaf6J6Uc8PJxOaku1l4hev6Dmgp+mXemnl9vqAPMxQT16SO8HFkJ2P Q=;
X-IronPort-AV: E=Sophos;i="5.28,494,1464652800";  d="scan'208,217";a="640557690"
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; 09 Aug 2016 12:24:26 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u79COP7S029217; Tue, 9 Aug 2016 12:24:25 GMT
To: Andy Bierman 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net> 
From: Robert Wilton 
Message-ID: <2e78a895-84d3-6381-ca34-f49a830f3bb0@cisco.com>
Date: Tue, 9 Aug 2016 13:24:18 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------2FF9F8778C3BBC69E494ECBF"
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 09 Aug 2016 12:24:31 -0000

This is a multi-part message in MIME format.
--------------2FF9F8778C3BBC69E494ECBF
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit

Hi Andy,

I don't properly understand the points that you are making, please see 
clarifying comments/questions inline ...

On 08/08/2016 22:51, Andy Bierman wrote:
>
>
> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  > wrote:
>
>     Acee writes:
>     >    Then I see no YANG language barriers in collapsing config and
>     state trees
>     >    - the model root just needs to be “config true”.
>
>     Great, I think we’re all agreed.  Can we now discuss the text I
>     proposed for 6087bis?  - here’s the link to my proposal:
>     https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s
>     .
>
>
> IMO this effort to avoid 2 containers is not well thought out.
> Some concerns:
>
> 1) modularity
>     placing the monitoring objects within the configuration means the 
> monitoring
>     cannot be used on its own
If it is one module with two top level augments (foo and foo-state) then 
this problem still exists.  Hence, please can you clarify why converging 
them on a single root node means that monitoring cannot be used on it 
own?  Wouldn't a device need to use deviations in both cases to strip 
out the config nodes that they are not supporting?


>
> 2) access control
>     placing the monitoring data within configuration means the 
> monitoring-only clients
>     need write permission turned on for the nodes they can access for 
> read-only
>     This relies on granular and complex NACM rules which require 
> regular maintenance.
Again, I don't quite follow this, in the specific example that I have 
regarding putting a RIB under a config true NP container, I would have 
thought that NACM read access would have been sufficient for a 
monitoring-only client.  Is that not the case?


>
> 3) YANG conformance
>     placing the monitoring data inside the configuration means the 
> configuration
>     will be required for conformance; it is not likely to be just 1 NP 
> container.
Similar to my response to the first question, I thought that conformance 
was done on a per module base, not a per sub-tree basis.  So even if you 
have top level 'foo' and 'foo-state' as part of the same module don't 
you run into the same conformance problem?


>
> 4) pointless;
>    given that new RPC operations are needed to access applied config, 
> the only data not
>    affected (and moved under the config container anyway) is stuff 
> that does not share
>    the same indexing, or counters which are not part of the opstate 
> problem.
Sorry, I don't really follow this one.  The original opstate draft put 
forward by OpenConfig was asking for both applied-configuration and 
derived state (e.g. statistics and other state) to be co-located under 
the same structures.  The original discussions focused on applied 
configuration, but when this was being discussed more recently the 
desire for a solution to the co-located derived state was also discussed 
- which is why both draft-schoenw-netmod-revised-datastores-01 and 
draft-wilton-netmod-refined-datastores-01 propose solutions to this problem.

There are also benefits to merging this data:

1) Having co-located config and state data means that clients can easily 
request config and state for a related object in a single request
1b) Having co-located config and state makes it easier for clients to 
code - they don't need to unify data across two (potentially different 
structures/indexes).
1c) Having a single structure, means less copying of the same 
organization structure into both config and state sub trees (which could 
be a source of bugs)

2) Having a single root makes schema mount work more nicely, it avoids a 
duplicate hierarchy.

3) Finally, I also agree with Kent, in that merging these makes the 
models easier to read and removes a historical wart.

Thanks,
Rob


>
>
>
> Andy
>
>
>     Hint: the first few edits are just nits...skip over the first few
>     paragraphs until you start seeing large blocks of changed lines...
>
>     Kent // as a contributor
>
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>     
>
>


--------------2FF9F8778C3BBC69E494ECBF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Andy,

    

    I don't properly understand the points that you are making, please
    see clarifying comments/questions inline ...

    

    
On 08/08/2016 22:51, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Aug 8, 2016 at 1:16 PM, Kent
            Watsen <kwatsen@juniper.net>
            wrote:

            
Acee
              writes:

              >    Then I see no YANG language barriers in collapsing
              config and state trees

              >    - the model root just needs to be “config true”.

              

              Great, I think we’re all agreed.  Can we now discuss the
              text I proposed for 6087bis?  - here’s the link to my
              proposal:  https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.

              

            

            


            

            
IMO this effort to avoid 2 containers is not well
              thought out.

            
Some concerns:

            


            

            
1) modularity

            
    placing the monitoring objects within the
              configuration means the monitoring

            
    cannot be used on its own

          

        

      

    

    If it is one module with two top level augments (foo and foo-state)
    then this problem still exists.  Hence, please can you clarify why
    converging them on a single root node means that monitoring cannot
    be used on it own?  Wouldn't a device need to use deviations in both
    cases to strip out the config nodes that they are not supporting?

    

    

    

      

        

          

            


            

            
2) access control

            
    placing the monitoring data within configuration
              means the monitoring-only clients

            
    need write permission turned on for the nodes they
              can access for read-only

            
    This relies on granular and complex NACM rules
              which require regular maintenance.

          

        

      

    

    Again, I don't quite follow this, in the specific example that I
    have regarding putting a RIB under a config true NP container, I
    would have thought that NACM read access would have been sufficient
    for a monitoring-only client.  Is that not the case?

    

    

    

      

        

          

            


            

            
3) YANG conformance

            
    placing the monitoring data inside the
              configuration means the configuration

            
    will be required for conformance; it is not likely
              to be just 1 NP container. 

            

          

        

      

    

    Similar to my response to the first question, I thought that
    conformance was done on a per module base, not a per sub-tree
    basis.  So even if you have top level 'foo' and 'foo-state' as part
    of the same module don't you run into the same conformance problem?

    

    

    

      

        

          

            


            

            
4) pointless;

            
   given that new RPC operations are needed to access
              applied config, the only data not

            
   affected (and moved under the config container
              anyway) is stuff that does not share

            
   the same indexing, or counters which are not part of
              the opstate problem.

          

        

      

    

    Sorry, I don't really follow this one.  The original opstate draft
    put forward by OpenConfig was asking for both applied-configuration
    and derived state (e.g. statistics and other state) to be co-located
    under the same structures.  The original discussions focused on
    applied configuration, but when this was being discussed more
    recently the desire for a solution to the co-located derived state
    was also discussed - which is why both
    draft-schoenw-netmod-revised-datastores-01 and
    draft-wilton-netmod-refined-datastores-01 propose solutions to this
    problem.

    

    There are also benefits to merging this data:

    

    1) Having co-located config and state data means that clients can
    easily request config and state for a related object in a single
    request

    1b) Having co-located config and state makes it easier for clients
    to code - they don't need to unify data across two (potentially
    different structures/indexes).

    1c) Having a single structure, means less copying of the same
    organization structure into both config and state sub trees (which
    could be a source of bugs)

    

    2) Having a single root makes schema mount work more nicely, it
    avoids a duplicate hierarchy.

    

    3) Finally, I also agree with Kent, in that merging these makes the
    models easier to read and removes a historical wart.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            


            

            


            

            
Andy

            


            

            


            

            

              Hint: the first few edits are just nits...skip over the
              first few paragraphs until you start seeing large blocks
              of changed lines...

              

              Kent // as a contributor

              

              

              

              _______________________________________________

              netmod mailing list

              netmod@ietf.org

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

            

          

          

        

      

    

    

  


--------------2FF9F8778C3BBC69E494ECBF--


From nobody Tue Aug  9 06:12: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 7C44212D825 for ; Tue,  9 Aug 2016 06:12:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Level: 
X-Spam-Status: No, score=-15.768 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=-1.247, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9gnvLLNrLh1K for ; Tue,  9 Aug 2016 06:12:12 -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 315FA12D824 for ; Tue,  9 Aug 2016 06:12:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25366; q=dns/txt; s=iport; t=1470748331; x=1471957931; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to; bh=6M+iPFjbVldcUPBqS/bUbuxQ5gIxWlGRvfQIBUcP6lk=; b=diNk7dLTL1W181B9O4JaNcFktdalJDoJifiz5oUAs0Nz+zJsySAFUYxA /FAc1tlbdQly0TvsbsV+SP5OSpNn5km4Qh/P/NX+oacLbpyZyBsas4OwU vl5JrDDgvT+nBKOzTBZHOFR7HO8mQKnmlYEUvt3geUVk6u2C+EM2ZTbRW 0=;
X-IronPort-AV: E=Sophos;i="5.28,494,1464652800";  d="scan'208,217";a="640561384"
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; 09 Aug 2016 13:12:09 +0000
Received: from [10.63.23.91] (dhcp-ensft1-uk-vla370-10-63-23-91.cisco.com [10.63.23.91]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u79DC8kM010605; Tue, 9 Aug 2016 13:12:08 GMT
To: Andy Bierman , Kent Watsen 
References:  <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net> 
From: Robert Wilton 
Message-ID: <4c5eedb9-ce73-3693-1e17-6012755a2fdd@cisco.com>
Date: Tue, 9 Aug 2016 14:12:01 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------610778F5FB091720EF9F8233"
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 09 Aug 2016 13:12:14 -0000

This is a multi-part message in MIME format.
--------------610778F5FB091720EF9F8233
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit



On 09/08/2016 00:30, Andy Bierman wrote:
>
>
> On Mon, Aug 8, 2016 at 4:24 PM, Kent Watsen  > wrote:
>
>     For 1,2,3, realize that placing config false nodes under config
>     true nodes has been with us from the beginning.  All the issues
>     you mentioned (if they’re issues at all) can’t be new.   Having a
>     duplicate -state tree is the wart here, it’s introducing an
>     inconsistency in how models have been written for a long time.  I
>     prefer to remove the wart than celebrate it.
>
>
> No, it actually is not the way we have been doing things all along.
> Historically (even with NETCONF, not just SNMP) we standardize
> read-only monitoring information.  Sometimes configuration is added later.

For me, it seems to have been the opposite.  I.e. all the early pressure 
was to get configuration covered by YANG models, with the operational 
state following afterwards.  We are either being asked for config 
models, or config+state models.  I guess that is because there is an 
existing solution (SNMP) for monitoring devices, but there is no 
workable solution to configure devices without using YANG.

Further, it seems to me that NETCONF is quite config focused, and that 
handling state was more added as an afterthought (e.g. according to the 
NETCONF RFC, config false leaves don't even exist as part of any 
datastore!).  If reporting state was the main driver for NETCONF/YANG 
then I would have thought that the semantics for handling operational 
state would have been formalized earlier on.


>
> Issues 1 - 3 are practical issues that need to be addressed if 
> top-level config=false
> nodes are not allowed anymore.
I don't think that the proposal is to make them 'not allowed', but 'not 
recommended' instead.

In particular, I think that the guideline would be along the lines:
If a given module "foo" only contains state and no configuration, then 
having a single top-level "foo" config false node is fine, but if a 
given module contains both config and state then the recommendation is 
to put that under a config=true "foo" top-level node.  Refining that 
slightly, If the state data is relevant even if "foo" hasn't been 
enabled then make the top level "foo" an NP container.  If "foo" has to 
be enabled on the system for the state data to be relevant then make 
"foo" a P container (or give it a separate foo/enable leaf).  In 
summary, I would suggest that the foo state data should be pushed as far 
down the combined config/state tree as possible.  It should be sited 
below (or adjacent to) whichever config node is required to make that 
state data relevant.

If config and state are in the same tree then it is easy to return all 
the data in one RPC, or have separate RPC operations that just return 
configuration (e.g. ), or just return "state + containing 
hieararchy" (e.g. a newly defined , or equivalent).

Having separate foo vs foo-state trees at the top level is always going 
to make it harder to return and manage a combined view of the config and 
state data.

Thanks,
Rob


>
>
> Andy
>
>     For 4, right, this discussion on s5.23 of 6087bis regards how to
>     handle state for system-generated objects (e.g., interfaces).  It
>     is not directly related to the how to report applied configuration
>     problem.  It is however indirectly related, in that a holistic
>     solution can address both.
>
>     Kent
>
>     *From: *Andy Bierman >
>     *Date: *Monday, August 8, 2016 at 5:51 PM
>     *To: *Kent Watsen >
>     *Cc: *"Acee Lindem (acee)"      >, "Robert Wilton -X (rwilton - ENSOFT
>     LIMITED at Cisco)" >,
>     Ladislav Lhotka >, Balazs
>     Lengyel      >, "netmod@ietf.org
>     " >
>     *Subject: *Re: [netmod] OpsState and Schema-Mount
>
>     On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen      > wrote:
>
>         Acee writes:
>         >    Then I see no YANG language barriers in collapsing config
>         and state trees
>         >    - the model root just needs to be “config true”.
>
>         Great, I think we’re all agreed. Can we now discuss the text I
>         proposed for 6087bis?  - here’s the link to my proposal:
>         https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s
>         .
>
>     IMO this effort to avoid 2 containers is not well thought out.
>
>     Some concerns:
>
>     1) modularity
>
>         placing the monitoring objects within the configuration means
>     the monitoring
>
>         cannot be used on its own
>
>     2) access control
>
>         placing the monitoring data within configuration means the
>     monitoring-only clients
>
>         need write permission turned on for the nodes they can access
>     for read-only
>
>         This relies on granular and complex NACM rules which require
>     regular maintenance.
>
>     3) YANG conformance
>
>         placing the monitoring data inside the configuration means the
>     configuration
>
>         will be required for conformance; it is not likely to be just
>     1 NP container.
>
>     4) pointless;
>
>        given that new RPC operations are needed to access applied
>     config, the only data not
>
>        affected (and moved under the config container anyway) is stuff
>     that does not share
>
>        the same indexing, or counters which are not part of the
>     opstate problem.
>
>     Andy
>
>         Hint: the first few edits are just nits...skip over the first
>         few paragraphs until you start seeing large blocks of changed
>         lines...
>
>         Kent // as a contributor
>
>
>
>         _______________________________________________
>         netmod mailing list
>         netmod@ietf.org 
>         https://www.ietf.org/mailman/listinfo/netmod
>         
>
>


--------------610778F5FB091720EF9F8233
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    


    

    

    
On 09/08/2016 00:30, Andy Bierman
      wrote:

    

    

      
      


        


          
On Mon, Aug 8, 2016 at 4:24 PM, Kent
            Watsen <kwatsen@juniper.net>
            wrote:

            

              

                

                  
For
                      1,2,3, realize that placing config false nodes
                      under config true nodes has been with us from the
                      beginning.  All the issues you mentioned (if
                      they’re issues at all) can’t be new.   Having a
                      duplicate -state tree is the wart here, it’s
                      introducing an inconsistency in how models have
                      been written for a long time.  I prefer to remove
                      the wart than celebrate it.

                  
 

                

              

            

            


            

            
No, it actually is not the way we have been doing
              things all along.

            
Historically (even with NETCONF, not just SNMP) we
              standardize

            
read-only monitoring information.  Sometimes
              configuration is added later.

          

        

      

    

    

    For me, it seems to have been the opposite.  I.e. all the early
    pressure was to get configuration covered by YANG models, with the
    operational state following afterwards.  We are either being asked
    for config models, or config+state models.  I guess that is because
    there is an existing solution (SNMP) for monitoring devices, but
    there is no workable solution to configure devices without using
    YANG.

    

    Further, it seems to me that NETCONF is quite config focused, and
    that handling state was more added as an afterthought (e.g.
    according to the NETCONF RFC, config false leaves don't even exist
    as part of any datastore!).  If reporting state was the main driver
    for NETCONF/YANG then I would have thought that the semantics for
    handling operational state would have been formalized earlier on.

    

    

    

      

        

          

            


            

            
Issues 1 - 3 are practical issues that need to be
              addressed if top-level config=false

            
nodes are not allowed anymore.

          

        

      

    

    I don't think that the proposal is to make them 'not allowed', but
    'not recommended' instead.

    

    In particular, I think that the guideline would be along the lines:

    If a given module "foo" only contains state and no configuration,
    then having a single top-level "foo" config false node is fine, but
    if a given module contains both config and state then the
    recommendation is to put that under a config=true "foo" top-level
    node.  Refining that slightly, If the state data is relevant even if
    "foo" hasn't been enabled then make the top level "foo" an NP
    container.  If "foo" has to be enabled on the system for the state
    data to be relevant then make "foo" a P container (or give it a
    separate foo/enable leaf).  In summary, I would suggest that the foo
    state data should be pushed as far down the combined config/state
    tree as possible.  It should be sited below (or adjacent to)
    whichever config node is required to make that state data relevant.

    

    If config and state are in the same tree then it is easy to return
    all the data in one RPC, or have separate RPC operations that just
    return configuration (e.g. <get-config>), or just return
    "state + containing hieararchy" (e.g. a newly defined
    <get-state>, or equivalent).

    

    Having separate foo vs foo-state trees at the top level is always
    going to make it harder to return and manage a combined view of the
    config and state data.

    

    Thanks,

    Rob

    

    

    

      

        

          

            


            

            


            

            
Andy

            


            

            
 

            

              

                

                  

                  
For
                      4, right, this discussion on s5.23 of 6087bis
                      regards how to handle state for system-generated
                      objects (e.g., interfaces).  It is not directly
                      related to the how to report applied configuration
                      problem.  It is however indirectly related, in
                      that a holistic solution can address both.

                  
 

                  
Kent

                  
 

                  
 

                  

                    
From:
                        
                      Andy
                        Bierman <andy@yumaworks.com>

                        Date: Monday, August 8, 2016 at 5:51 PM

                        To: Kent Watsen <kwatsen@juniper.net>

                        Cc: "Acee Lindem (acee)" <acee@cisco.com>,
                        "Robert Wilton -X (rwilton - ENSOFT LIMITED at
                        Cisco)" <rwilton@cisco.com>,
                        Ladislav Lhotka <lhotka@nic.cz>,
                        Balazs Lengyel <balazs.lengyel@ericsson.com>,
                        "netmod@ietf.org"
                        <netmod@ietf.org>

                        Subject: Re: [netmod] OpsState and
                        Schema-Mount

                  

                  

                    
 

                  

                  

                    

                      

                        
 

                        

                          
 

                          

                            
On Mon, Aug 8, 2016 at
                              1:16 PM, Kent Watsen <kwatsen@juniper.net>
                              wrote:

                            

                              
Acee
                                writes:

                                >    Then I see no YANG language
                                barriers in collapsing config and state
                                trees

                                >    - the model root just needs to
                                be “config true”.

                                  

                                Great, I think we’re all agreed. 
                                Can we now discuss the text I proposed
                                for 6087bis?  - here’s the link to my
                                proposal: 
                                
                                  https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.

                            

                            

                              
 

                            

                            

                              
IMO this effort to
                                avoid 2 containers is not well thought
                                out.

                            

                            

                              
Some concerns:

                            

                            

                              
 

                            

                            

                              
1) modularity

                            

                            

                              
    placing the
                                monitoring objects within the
                                configuration means the monitoring

                            

                            

                              
    cannot be used on
                                its own

                            

                            

                              
 

                            

                            

                              
2) access control

                            

                            

                              
    placing the
                                monitoring data within configuration
                                means the monitoring-only clients

                            

                            

                              
    need write
                                permission turned on for the nodes they
                                can access for read-only

                            

                            

                              
    This relies on
                                granular and complex NACM rules which
                                require regular maintenance.

                            

                            

                              
 

                            

                            

                              
3) YANG conformance

                            

                            

                              
    placing the
                                monitoring data inside the configuration
                                means the configuration

                            

                            

                              
    will be required
                                for conformance; it is not likely to be
                                just 1 NP container. 

                            

                            

                              
 

                            

                            

                              
4) pointless;

                            

                            

                              
   given that new RPC
                                operations are needed to access applied
                                config, the only data not

                            

                            

                              
   affected (and
                                moved under the config container anyway)
                                is stuff that does not share

                            

                            

                              
   the same indexing,
                                or counters which are not part of the
                                opstate problem.

                            

                            

                              
 

                            

                            

                              
 

                            

                            

                              
 

                            

                            

                              
Andy

                            

                            

                              
 

                            

                            

                              
 

                            

                            

                              
Hint: the first few
                                edits are just nits...skip over the
                                first few paragraphs until you start
                                seeing large blocks of changed lines...

                                

                                Kent // as a contributor

                                

                                

                                

                                _______________________________________________

                                netmod mailing list

                                netmod@ietf.org

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

                            

                          

                          
 

                        

                      

                    

                  

                

              

            

          

          

        

      

    

    

  


--------------610778F5FB091720EF9F8233--


From nobody Tue Aug  9 06:39: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 5281812D095 for ; Tue,  9 Aug 2016 06:39:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Level: 
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 6NtGyX3bOViF for ; Tue,  9 Aug 2016 06:39:02 -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 16C9312D5CB for ; Tue,  9 Aug 2016 06:39:02 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 88427F03; Tue,  9 Aug 2016 15:39:00 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id L03e7yDOL1lN; Tue,  9 Aug 2016 15:38:58 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue,  9 Aug 2016 15:38:59 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 783A42008E; Tue,  9 Aug 2016 15:38:59 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3LtLkkiGt4MK; Tue,  9 Aug 2016 15:38:57 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C6B9B2008D; Tue,  9 Aug 2016 15:38:57 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C01CC3C14D39; Tue,  9 Aug 2016 15:38:56 +0200 (CEST)
Date: Tue, 9 Aug 2016 15:38:56 +0200
From: Juergen Schoenwaelder 
To: Robert Wilton 
Message-ID: <20160809133854.GD313@elstar.local>
Mail-Followup-To: Robert Wilton , Andy Bierman , Kent Watsen , netmod WG 
References: <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net>  <4c5eedb9-ce73-3693-1e17-6012755a2fdd@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <4c5eedb9-ce73-3693-1e17-6012755a2fdd@cisco.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and Schema-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: Tue, 09 Aug 2016 13:39:04 -0000

On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
> 
> In particular, I think that the guideline would be along the lines:
> If a given module "foo" only contains state and no configuration, then
> having a single top-level "foo" config false node is fine, but if a given
> module contains both config and state then the recommendation is to put that
> under a config=true "foo" top-level node.  Refining that slightly, If the
> state data is relevant even if "foo" hasn't been enabled then make the top
> level "foo" an NP container.  If "foo" has to be enabled on the system for
> the state data to be relevant then make "foo" a P container (or give it a
> separate foo/enable leaf).  In summary, I would suggest that the foo state
> data should be pushed as far down the combined config/state tree as
> possible.  It should be sited below (or adjacent to) whichever config node
> is required to make that state data relevant.
> 
> If config and state are in the same tree then it is easy to return all the
> data in one RPC, or have separate RPC operations that just return
> configuration (e.g. ), or just return "state + containing
> hieararchy" (e.g. a newly defined , or equivalent).
> 
> Having separate foo vs foo-state trees at the top level is always going to
> make it harder to return and manage a combined view of the config and state
> data.

I think it is crucial to separate (a) what protocols do today and (b)
what protocols might do at some time in the future.

The current protocol reality, that is (a), paired with the reality of
network interfaces has lead to the (/interfaces, /interfaces-state)
design pattern and until we have (b) in place I do not think we have
really an alternative for the (/interfaces, /interfaces-state)
design pattern.

If you have config and state are in the same tree, you simply can't
represent certain things that exist in reality. A single tree may look
'simpler' but in several cases also simply 'unusable'. We did not
particularly like the (/interfaces, /interfaces-state) design but it
was the only solution that seemed to work for all cases given the
protocol reality we were in.

/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 Aug  9 07:23: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 8331D12D5A5 for ; Tue,  9 Aug 2016 07:23:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 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=-1.247] autolearn=unavailable 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 LU8rcwvv813A for ; Tue,  9 Aug 2016 07:23:29 -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 5CC8912D876 for ; Tue,  9 Aug 2016 07:16:44 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:79c6:95cb:b1f6:9427] (unknown [IPv6:2001:718:1a02:1:79c6:95cb:b1f6:9427]) by mail.nic.cz (Postfix) with ESMTPSA id CD3A261515; Tue,  9 Aug 2016 16:16:42 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470752202; bh=To/6ew0qBlsqU4OvvYgU4c+i7Ia7XyCe8M1LVo0bjBM=; h=From:Date:To; b=T5WLdWCRg/lC80HaFYsOxMcqN33X1QfrJ161f2fuOiLza61Ze5GQ19gSomDCQVzzB ksB3/x1y1hKy3jJiLoMTCBqjDGpK9QChQyrHz9thj13HdvqcNr0AWmdVhZy2xCXvdt HD0y9fL5IST2HNb8sXEOrHvQgdZeY8gtBOyasEWI=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160809133854.GD313@elstar.local>
Date: Tue, 9 Aug 2016 16:16:46 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6007E205-5B8F-4A23-A7EE-3393A730FC61@nic.cz>
References: <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net>  <4c5eedb9-ce73-3693-1e17-6012755a2fdd@cisco.com> <20160809133854.GD313@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 WG 
Subject: Re: [netmod] OpsState and 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, 09 Aug 2016 14:23:30 -0000

> On 09 Aug 2016, at 15:38, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
>>=20
>> In particular, I think that the guideline would be along the lines:
>> If a given module "foo" only contains state and no configuration, =
then
>> having a single top-level "foo" config false node is fine, but if a =
given
>> module contains both config and state then the recommendation is to =
put that
>> under a config=3Dtrue "foo" top-level node.  Refining that slightly, =
If the
>> state data is relevant even if "foo" hasn't been enabled then make =
the top
>> level "foo" an NP container.  If "foo" has to be enabled on the =
system for
>> the state data to be relevant then make "foo" a P container (or give =
it a
>> separate foo/enable leaf).  In summary, I would suggest that the foo =
state
>> data should be pushed as far down the combined config/state tree as
>> possible.  It should be sited below (or adjacent to) whichever config =
node
>> is required to make that state data relevant.
>>=20
>> If config and state are in the same tree then it is easy to return =
all the
>> data in one RPC, or have separate RPC operations that just return
>> configuration (e.g. ), or just return "state + containing
>> hieararchy" (e.g. a newly defined , or equivalent).
>>=20
>> Having separate foo vs foo-state trees at the top level is always =
going to
>> make it harder to return and manage a combined view of the config and =
state
>> data.
>=20
> I think it is crucial to separate (a) what protocols do today and (b)
> what protocols might do at some time in the future.
>=20
> The current protocol reality, that is (a), paired with the reality of
> network interfaces has lead to the (/interfaces, /interfaces-state)
> design pattern and until we have (b) in place I do not think we have
> really an alternative for the (/interfaces, /interfaces-state)
> design pattern.

I would also add that some aspects of YANG (config true/false dichotomy, =
validation rules) make everything else difficult.=20

>=20
> If you have config and state are in the same tree, you simply can't
> represent certain things that exist in reality. A single tree may look
> 'simpler' but in several cases also simply 'unusable'. We did not
> particularly like the (/interfaces, /interfaces-state) design but it
> was the only solution that seemed to work for all cases given the
> protocol reality we were in.

Right. We have tried hard to find something more elegant, and some =
attempts (for example [1]) were quite similar to the current OpState =
proposals, but we eventually realised that our shortcuts only work in =
simple examples and break down in more complex situations.

That said, I don't claim that a more elegant solution is impossible (and =
Randy Presuhn would probably note that it was already available 25 years =
ago:-) but IMO it is not a low-hanging fruit given what we currently =
have (YANG and the protocols).

Lada

[1] https://tools.ietf.org/html/draft-bjorklund-netmod-operational-00

>=20
> /js
>=20
> --=20
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





From nobody Tue Aug  9 07:23: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 CC55F12D5CB for ; Tue,  9 Aug 2016 07:23:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cGI58yFCLVy3 for ; Tue,  9 Aug 2016 07:23:31 -0700 (PDT)
Received: from mail-ua0-x233.google.com (mail-ua0-x233.google.com [IPv6:2607:f8b0:400c:c08::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 41F1F12D81E for ; Tue,  9 Aug 2016 07:23:31 -0700 (PDT)
Received: by mail-ua0-x233.google.com with SMTP id n59so20880613uan.2 for ; Tue, 09 Aug 2016 07:23:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=sanOeOcDGWWUZPH9cmOqtr09DxWjCEGNZ01udnSWXTU=; b=iI6aGjxweSw2RiL1PzA9bl2dlCAz4/i2vz2dmj9fmJURRea9tR8F4pgogPyptAwiJE EpeTjuRbSrqojXQas1cATpVI7j/9GoEwV0a1fZSlsIY7l41i4iyOvMRwZszgOjw64I9Q us7FLAWHM8Q/u4UkiQGxrtnDxZrDDQ94N1vnMCv3YnpVMXRgqawHTgvoqYz6qp7w7Dak +ral3DpB/yk1rbx5UUViEWcXeBTwMFL/9Y1HsAMKc/MNpAGt8Toitm4o7GfZr+DOdZ0G E1CvfORk7gQ0gqEYdGe2p6I9Cn/fHVT+Ppx6zcfn7ZJQpE2daOgikrdYIZTDXN+K9UyY YqGw==
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:from:date :message-id:subject:to:cc; bh=sanOeOcDGWWUZPH9cmOqtr09DxWjCEGNZ01udnSWXTU=; b=T2vNIaKd5RooctuHT5ks0qrNFanfqePkEAU5QBL51N3H808ufLhk4h/fbsKVr3iWN6 P9VDO1KwOljRP95e+Wy7vFSGVZtbDleJpR7wwqgqWUcS8LrU8UuUbyUrFlxYPZ99jv+i 95QfEtgHOIKjz46qy5OSD+TEaciV4Gm5bmLcy/uRJ52DWOY7RdSYclGJb+FI8vT3jsEq +UNkRvN3eaFB5YumBX/hvD2Pl862O/VJKVl/2h0QUjSePHA+kGDE+MCsQHKo64HoMWNI n5AHRIlWAkmAEtt2N3g5nJqAo0gpNOxxRULHzSFCLn0FyNd/IkTzm4qMzNv8p34hdHy5 9ZnA==
X-Gm-Message-State: AEkoouvevNJ7ufpHg4y74/Zo+DfJLbkoJpoy0c3nJbUdzBu17JUOoSBwkWhQqYMDmOo4qmyM3LIMlQ2ZtIni9Q==
X-Received: by 10.31.252.203 with SMTP id a194mr44041203vki.44.1470752610381;  Tue, 09 Aug 2016 07:23:30 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Tue, 9 Aug 2016 07:23:29 -0700 (PDT)
In-Reply-To: <2e78a895-84d3-6381-ca34-f49a830f3bb0@cisco.com>
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <2e78a895-84d3-6381-ca34-f49a830f3bb0@cisco.com>
From: Andy Bierman 
Date: Tue, 9 Aug 2016 07:23:29 -0700
Message-ID: 
To: Robert Wilton 
Content-Type: multipart/alternative; boundary=94eb2c149bd4e50c1a0539a446f1
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 09 Aug 2016 14:23:39 -0000

--94eb2c149bd4e50c1a0539a446f1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton  wrote:

> Hi Andy,
> I don't properly understand the points that you are making, please see
> clarifying comments/questions inline ...
>
> On 08/08/2016 22:51, Andy Bierman wrote:
>
>
>
> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  wrote:
>
>> Acee writes:
>> >    Then I see no YANG language barriers in collapsing config and state
>> trees
>> >    - the model root just needs to be =E2=80=9Cconfig true=E2=80=9D.
>>
>> Great, I think we=E2=80=99re all agreed.  Can we now discuss the text I =
proposed
>> for 6087bis?  - here=E2=80=99s the link to my proposal:
>> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s=
.
>>
>>
> IMO this effort to avoid 2 containers is not well thought out.
> Some concerns:
>
> 1) modularity
>     placing the monitoring objects within the configuration means the
> monitoring
>     cannot be used on its own
>
> If it is one module with two top level augments (foo and foo-state) then
> this problem still exists.  Hence, please can you clarify why converging
> them on a single root node means that monitoring cannot be used on it own=
?
> Wouldn't a device need to use deviations in both cases to strip out the
> config nodes that they are not supporting?
>
>
Before the "rule" I can choose to place monitoring in its own module
without any reliance on other modules.  If the monitoring does not share
indexing,
what value is there in putting it in the config tree?  I see none except a
poor
attempt at model classification.



>
>
> 2) access control
>     placing the monitoring data within configuration means the
> monitoring-only clients
>     need write permission turned on for the nodes they can access for
> read-only
>     This relies on granular and complex NACM rules which require regular
> maintenance.
>
> Again, I don't quite follow this, in the specific example that I have
> regarding putting a RIB under a config true NP container, I would have
> thought that NACM read access would have been sufficient for a
> monitoring-only client.  Is that not the case?
>


If the monitoring is rooting under config=3Dtrue nodes, then those config=
=3Dtrue
nodes need to be created somehow.  A client with write access is probably
required.



>
>
> 3) YANG conformance
>     placing the monitoring data inside the configuration means the
> configuration
>     will be required for conformance; it is not likely to be just 1 NP
> container.
>
> Similar to my response to the first question, I thought that conformance
> was done on a per module base, not a per sub-tree basis.  So even if you
> have top level 'foo' and 'foo-state' as part of the same module don't you
> run into the same conformance problem?
>
>
>
Much easier to solve the conformance since /foo-state does not need any
objects from /foo
to exist first.  Creating the /foo container means that all config=3Dtrue
requirements for
that container must be implemented (or complex deviations used)


>
> 4) pointless;
>    given that new RPC operations are needed to access applied config, the
> only data not
>    affected (and moved under the config container anyway) is stuff that
> does not share
>    the same indexing, or counters which are not part of the opstate
> problem.
>
> Sorry, I don't really follow this one.  The original opstate draft put
> forward by OpenConfig was asking for both applied-configuration and deriv=
ed
> state (e.g. statistics and other state) to be co-located under the same
> structures.  The original discussions focused on applied configuration, b=
ut
> when this was being discussed more recently the desire for a solution to
> the co-located derived state was also discussed - which is why both
> draft-schoenw-netmod-revised-datastores-01 and
> draft-wilton-netmod-refined-datastores-01 propose solutions to this
> problem.
>


> There are also benefits to merging this data:
>
> 1) Having co-located config and state data means that clients can easily
> request config and state for a related object in a single request
> 1b) Having co-located config and state makes it easier for clients to cod=
e
> - they don't need to unify data across two (potentially different
> structures/indexes).
> 1c) Having a single structure, means less copying of the same organizatio=
n
> structure into both config and state sub trees (which could be a source o=
f
> bugs)
>
> 2) Having a single root makes schema mount work more nicely, it avoids a
> duplicate hierarchy.
>
> 3) Finally, I also agree with Kent, in that merging these makes the model=
s
> easier to read and removes a historical wart.
>
>

I don't agree with any of these "benefits".
The protocol can be made to solve these problems. (1) is already solved.
(1b) is pure speculation about implementation cost.
(1c) also makes subjective implementation assumptions
The new problems that are raised just make YANG worse and full of CLRs
that confuse people trying to learn YANG.




> Thanks,
> Rob
>
>
>
Andy


>
>
>
> Andy
>
>
> Hint: the first few edits are just nits...skip over the first few
>> paragraphs until you start seeing large blocks of changed lines...
>>
>> Kent // as a contributor
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>
>
>

--94eb2c149bd4e50c1a0539a446f1
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton <rwilton@cisco.com&g=
t; wrote:

 =20
   =20
 =20
  

    
Hi Andy,

    

    I don't properly understand the points that you are making, please
    see clarifying comments/questions inline ...

    

    
On 08/08/2016 22:51, Andy Bierman
      wrote:

    

    

     =20
      


        


          
On Mon, Aug 8, 2016 at 1:16 PM, Kent
            Watsen <kwatsen@juniper.net>
            wrote:

            
Acee
              writes:

              >=C2=A0 =C2=A0 Then I see no YANG language barriers in col=
lapsing
              config and state trees

              >=C2=A0 =C2=A0 - the model root just needs to be =E2=80=9C=
config true=E2=80=9D.

              

              Great, I think we=E2=80=99re all agreed.=C2=A0 Can we now dis=
cuss the
              text I proposed for 6087bis?=C2=A0 - here=E2=80=99s the link =
to my
              proposal:=C2=A0 https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9n=
nCwoLAJ0s.

              

            

            


            

            
IMO this effort to avoid 2 containers is not well
              thought out.

            
Some concerns:

            


            

            
1) modularity

            
=C2=A0 =C2=A0 placing the monitoring objects within the
              configuration means the monitoring

            
=C2=A0 =C2=A0 cannot be used on its own

          

        

      

    

    If it is one module with two top level augments (foo and foo-state)
    then this problem still exists.=C2=A0 Hence, please can you clarify why
    converging them on a single root node means that monitoring cannot
    be used on it own?=C2=A0 Wouldn't a device need to use deviations i=
n both
    cases to strip out the config nodes that they are not supporting?

    

Before the "rule" =
I can choose to place monitoring in its own module
without any re=
liance on other modules.=C2=A0 If the monitoring does not share indexing,
what value is there in putting it in the config tree?=C2=A0 I see =
none except a poor
attempt at model classification.
=C2=A0

    

    

      

        

          

            


            

            
2) access control

            
=C2=A0 =C2=A0 placing the monitoring data within configura=
tion
              means the monitoring-only clients

            
=C2=A0 =C2=A0 need write permission turned on for the node=
s they
              can access for read-only

            
=C2=A0 =C2=A0 This relies on granular and complex NACM rul=
es
              which require regular maintenance.

          

        

      

    

    Again, I don't quite follow this, in the specific example that I
    have regarding putting a RIB under a config true NP container, I
    would have thought that NACM read access would have been sufficient
    for a monitoring-only client.=C2=A0 Is that not the case?


If the monitoring is rooting un=
der config=3Dtrue nodes, then those config=3Dtrue
nodes need to b=
e created somehow.=C2=A0 A client with write access is probably required.



    

    

    

      

        

          

            


            

            
3) YANG conformance

            
=C2=A0 =C2=A0 placing the monitoring data inside the
              configuration means the configuration

            
=C2=A0 =C2=A0 will be required for conformance; it is not =
likely
              to be just 1 NP container. 

            

          

        

      

    

    Similar to my response to the first question, I thought that
    conformance was done on a per module base, not a per sub-tree
    basis.=C2=A0 So even if you have top level 'foo' and 'foo-s=
tate' as part
    of the same module don't you run into the same conformance problem?=


    

    

Much easier to solve the con=
formance since /foo-state does not need any objects from /foo
to =
exist first.=C2=A0 Creating the /foo container means that all config=3Dtrue=
 requirements for
that container must be implemented (or complex =
deviations used)
=C2=A0

    

      

        

          

            


            

            
4) pointless;

            
=C2=A0 =C2=A0given that new RPC operations are needed to a=
ccess
              applied config, the only data not

            
=C2=A0 =C2=A0affected (and moved under the config containe=
r
              anyway) is stuff that does not share

            
=C2=A0 =C2=A0the same indexing, or counters which are not =
part of
              the opstate problem.

          

        

      

    

    Sorry, I don't really follow this one.=C2=A0 The original opstate d=
raft
    put forward by OpenConfig was asking for both applied-configuration
    and derived state (e.g. statistics and other state) to be co-located
    under the same structures.=C2=A0 The original discussions focused on
    applied configuration, but when this was being discussed more
    recently the desire for a solution to the co-located derived state
    was also discussed - which is why both
    draft-schoenw-netmod-revised-datastores-01 and
    draft-wilton-netmod-refined-datastores-01 propose solutions to thi=
s
    problem.
=C2=A0

    There are also benefits to merging this data:

    

    1) Having co-located config and state data means that clients can
    easily request config and state for a related object in a single
    request

    1b) Having co-located config and state makes it easier for clients
    to code - they don't need to unify data across two (potentially
    different structures/indexes).

    1c) Having a single structure, means less copying of the same
    organization structure into both config and state sub trees (which
    could be a source of bugs)

    

    2) Having a single root makes schema mount work more nicely, it
    avoids a duplicate hierarchy.

    

    3) Finally, I also agree with Kent, in that merging these makes the
    models easier to read and removes a historical wart.

    


I don't a=
gree with any of these "benefits".
The protocol can be =
made to solve these problems. (1) is already solved.
(1b) is pure=
 speculation about implementation cost.
(1c) also makes subjectiv=
e implementation assumptions
The new problems that are raised jus=
t make YANG worse and full of CLRs
that confuse people trying to =
learn YANG.


=C2=A0

    Thanks,

    Rob

    

    

Andy
=C2=A0
<=
blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px=
 #ccc solid;padding-left:1ex">

    

      

        

          

            


            

            


            

            


            

            
Andy

            


            

            


            

            

              Hint: the first few edits are just nits...skip over the
              first few paragraphs until you start seeing large blocks
              of changed lines...

              

              Kent // as a contributor

              

              

              

              _______________________________________________

              netmod mailing list

              netmod@i=
etf.org

              https://www.ietf.org/mailman/listinf=
o/netmod

            

          

          

        

      

    

    

  






--94eb2c149bd4e50c1a0539a446f1--


From nobody Tue Aug  9 12:44: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 3336112D19B for ; Tue,  9 Aug 2016 12:44:29 -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 g7yuznORW4Bx for ; Tue,  9 Aug 2016 12:44:27 -0700 (PDT)
Received: from NAM02-SN1-obe.outbound.protection.outlook.com (mail-sn1nam02on0133.outbound.protection.outlook.com [104.47.36.133]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067F112D131 for ; Tue,  9 Aug 2016 12:44:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=ksD9uGe6/tnaxmX2EsLx2rTnlwPHqkRKD8vYqIJNL5s=; b=Gzh7RmoafBJS+g3lYfbzOCKD+GRchyBgiv7C19/XmJip3oo+sqnmMd7Jmo0UsE5MB3W7LPpoNgatdXQLHR3g6SNyfudR5mTEinDCRW3C5AxPjV0UB3+wmJK5Ukf3P8GigUup9oSrgFZnMlSLvw6FxpKpshGoIB+AKeGf0ogF9LA=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Tue, 9 Aug 2016 19:44:24 +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.0557.009; Tue, 9 Aug 2016 19:44:24 +0000
From: Kent Watsen 
To: Andy Bierman , Robert Wilton 
Thread-Topic: [netmod] OpsState and Schema-Mount
Thread-Index: AQHR7Nwrg+3BeZANfEqM5r9gczFpmaA2zIQAgAAlNwCAAKDWgIABEGmAgAAzOACABnBxAIAAXauAgADz3wCAACFNgIAAFpwA
Date: Tue, 9 Aug 2016 19:44:24 +0000
Message-ID: 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <2e78a895-84d3-6381-ca34-f49a830f3bb0@cisco.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: b37f4c80-7bfe-4d1a-efe3-08d3c08d9108
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:ygDNTrGZoCjNsxeA693nt5gwM7HZFEC64Rimhjhtj/CHcH44J4pSNOgHjUkV6y+PB42UFzfclA0k1Ei+SILopoAb394tdOxjiWJ1P9Denh7bsBkH/HOclEhM9hUCBjSSoOLlt6oFBETOjS30HFzwkBm0tZZEbsCu3LKaX2dS4d8XyiJybQCwalbmXtTR6cM2UivZfSvOtrKVZGtSHauBGncJQlI9MwbiVqVkd4nE2TYxaYCFVSfvbxFlWrzF/ERGK1iBDzORcWkpPIR+iHwGkjilL/W3IcQxbPtnr1RDdRxWxAaei5VjjNOtdJNyqnZSQJgNh0gLzLWeZBb4/ZB3fg==; 5:nMde7myiEhYBNfb7XbQYmsSUBaeUkHcN1GjbIOwDdskaRfaoe5EVIDeFUojUSs7UFVdzjvW6P9Dv+54GYE5GarIPDLxFBU00NJSmohZoUp1EhLmna8iTbJmGugcRgfJOBhmysUPgiHANtu3X7UMzGA==; 24:8onKtU88OLUJIw40wn0m1l3dytzhGr7lhlUC4KZgv6oky/cLiHNGXwD/zalz+usNi695zl68qQkJqc+5o6TXNHo5h+7qpulED3OlcA6aRRk=; 7:odhfum8+QoJ5fDbTXPFeVQAgDHC8/YXpI+c3kD6CLq+h07g8NMPy0a36tWCkO+Xd6QZfsys7pYACwoOc0h9YprlMMaC4j8E2dSv2TGI4WHxEZC6tsnlHL3PSR6knP9T15uVXcyhiafuXh2W8u9eznaTgmLgh6LPJ9I9DybiO6OvTylsD3buY6XXY+19Bu+9uyQi5T4tbdT7Mfc7nf9/XnOsQ4q26fKX3fdI1055xbSoGTlhWmq6FlLB1SkQHJ+nv
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(72170088055959)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);  SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; 
x-forefront-prvs: 0029F17A3F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(19580395003)(50986999)(8936002)(3660700001)(36756003)(81156014)(2950100001)(92566002)(5002640100001)(101416001)(8676002)(77096005)(81166006)(3280700002)(106356001)(87936001)(83716003)(2900100001)(19625215002)(82746002)(15975445007)(11100500001)(106116001)(83506001)(122556002)(5001770100001)(99286002)(105586002)(3846002)(4326007)(19300405004)(102836003)(10400500002)(7736002)(6116002)(93886004)(86362001)(33656002)(586003)(66066001)(54356999)(16236675004)(68736007)(7846002)(76176999)(97736004)(189998001)(2906002)(4001350100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_C2257A12930E4CD7AC9C1570145A82C0junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2016 19:44:24.3303 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 09 Aug 2016 19:44:29 -0000

--_000_C2257A12930E4CD7AC9C1570145A82C0junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpCZWZvcmUgdGhlICJydWxlIiBJIGNhbiBjaG9vc2UgdG8gcGxhY2UgbW9uaXRvcmluZyBpbiBp
dHMgb3duIG1vZHVsZQ0Kd2l0aG91dCBhbnkgcmVsaWFuY2Ugb24gb3RoZXIgbW9kdWxlcy4gIElm
IHRoZSBtb25pdG9yaW5nIGRvZXMgbm90IHNoYXJlIGluZGV4aW5nLA0Kd2hhdCB2YWx1ZSBpcyB0
aGVyZSBpbiBwdXR0aW5nIGl0IGluIHRoZSBjb25maWcgdHJlZT8gIEkgc2VlIG5vbmUgZXhjZXB0
IGEgcG9vcg0KYXR0ZW1wdCBhdCBtb2RlbCBjbGFzc2lmaWNhdGlvbi4NCg0KW0tFTlRdIGZyb20g
b3BzdGF0ZS1yZXFzOg0KDQogICAgNC4gQWJpbGl0eSB0byByZWxhdGUgY29uZmlndXJhdGlvbiB3
aXRoIGl0cyBjb3JyZXNwb25kaW5nDQogICAgICAgb3BlcmF0aW9uYWwgc3RhdGUuDQogICAgICAg
ICAgIEEuICBBYmlsaXR5IHRvIHJlbGF0ZSBpbnRlbmRlZCBjb25maWcgbm9kZXMgdG8gY29ycmVz
cG9uZGluZw0KICAgICAgICAgICAgICAgICAgYXBwbGllZCBjb25maWcgbm9kZXMNCiAgICAgICAg
ICAgIEIuICBBYmlsaXR5IHRvIHJlbGF0ZSBpbnRlbmRlZCBjb25maWcgbm9kZXMgdG8gYXNzb2Np
YXRlZCBkZXJpdmVkDQogICAgICAgICAgICAgICAgICBzdGF0ZSBub2Rlcw0KICAgICAgICAgICAg
Qy4gIFRoZSByZWxhdGlvbnNoaXBzIG5lZWQgdG8gYmUgcHJvZ3JhbW1hdGljYWxseSBjb25zdW1h
YmxlDQoNCg0KDQpJZiB0aGUgbW9uaXRvcmluZyBpcyByb290aW5nIHVuZGVyIGNvbmZpZz10cnVl
IG5vZGVzLCB0aGVuIHRob3NlIGNvbmZpZz10cnVlDQpub2RlcyBuZWVkIHRvIGJlIGNyZWF0ZWQg
c29tZWhvdy4gIEEgY2xpZW50IHdpdGggd3JpdGUgYWNjZXNzIGlzIHByb2JhYmx5IHJlcXVpcmVk
Lg0KDQpbS0VOVF0geWVzLCBidXQgdGhvc2UgY29uZmlnIHRydWUgYW5jZXN0b3Igbm9kZXMgY291
bGQgYmUgY3JlYXRlZCBieSBhbm90aGVyIGNsaWVudCB0aGF0IGhhcyB3cml0ZS1hY2Nlc3MsIHNp
bWlsYXIgdG8gUE9TSVggZmlsZXN5c3RlbS4NCg0KDQoNCk11Y2ggZWFzaWVyIHRvIHNvbHZlIHRo
ZSBjb25mb3JtYW5jZSBzaW5jZSAvZm9vLXN0YXRlIGRvZXMgbm90IG5lZWQgYW55IG9iamVjdHMg
ZnJvbSAvZm9vDQp0byBleGlzdCBmaXJzdC4gIENyZWF0aW5nIHRoZSAvZm9vIGNvbnRhaW5lciBt
ZWFucyB0aGF0IGFsbCBjb25maWc9dHJ1ZSByZXF1aXJlbWVudHMgZm9yDQp0aGF0IGNvbnRhaW5l
ciBtdXN0IGJlIGltcGxlbWVudGVkIChvciBjb21wbGV4IGRldmlhdGlvbnMgdXNlZCkNCg0KW0tF
TlRdIHNlZW1zIGxpa2UgYW4gaW1wbGVtZW50YXRpb24gZGV0YWlsLiAgVGhlIGNvbmNlcHR1YWwg
bW9kZWwgaXMgZmluZS4gICA8Z2V0LWNvbmZpZz4gYW5kIG5ldyA8Z2V0LXN0YXRlPiBjYW4gaGF2
ZSBkaWZmZXJlbnQgdmlld3MuICA8Z2V0LWNvbmZpZz4gc2hvdWxkIG1haW50YWluIHRoZSB2aWV3
IG9mIHRoZSBjb25maWcgZmFsc2Ugbm9kZXMgcmV0dXJuZWQgbm90IGluY2x1ZGluZyBzeXN0ZW0t
Z2VuZXJhdGVkIG9iamVjdHMgKGUuZy4sIGludGVyZmFjZXMpLCB3aGVyZWFzIDxnZXQtc3RhdGU+
IGNhbiBhbHNvIHJldHVybiBzeXN0ZW0tZ2VuZXJhdGVkIG9iamVjdHMsIHNvbWUgb2Ygd2hpY2gg
bWF5IHJlcXVpcmUgYWxzbyByZXR1cm5pbmcgY29uZmlnIHRydWUgYW5jZXN0b3Igbm9kZXMuDQoN
Cg0KDQoNCg==

--_000_C2257A12930E4CD7AC9C1570145A82C0junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <8136D0160C410C46A0CB077F1E5B471D@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsN
CgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdp
bi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OiJUaW1lcyBOZXcg
Um9tYW4iO30NCnNwYW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJl
cGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1z
b0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1
bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpA
cGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEu
MGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7
fQ0KLS0+PC9zdHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1V
UyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9u
dC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxk
aXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVm
b3JlIHRoZSAmcXVvdDtydWxlJnF1b3Q7IEkgY2FuIGNob29zZSB0byBwbGFjZSBtb25pdG9yaW5n
IGluIGl0cyBvd24gbW9kdWxlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj53aXRob3V0IGFueSByZWxpYW5jZSBvbiBvdGhlciBtb2R1bGVzLiZuYnNw
OyBJZiB0aGUgbW9uaXRvcmluZyBkb2VzIG5vdCBzaGFyZSBpbmRleGluZyw8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndoYXQgdmFsdWUgaXMgdGhl
cmUgaW4gcHV0dGluZyBpdCBpbiB0aGUgY29uZmlnIHRyZWU/Jm5ic3A7IEkgc2VlIG5vbmUgZXhj
ZXB0IGEgcG9vcjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+YXR0ZW1wdCBhdCBtb2RlbCBjbGFzc2lmaWNhdGlvbi48bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+W0tFTlRdIGZyb20gb3BzdGF0ZS1yZXFzOjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsgNC4gQWJpbGl0eSB0byByZWxhdGUgY29u
ZmlndXJhdGlvbiB3aXRoIGl0cyBjb3JyZXNwb25kaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtv
cGVyYXRpb25hbCBzdGF0ZS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO0EuJm5ic3A7IEFiaWxpdHkgdG8gcmVsYXRlIGludGVuZGVkIGNvbmZpZyBub2RlcyB0
byBjb3JyZXNwb25kaW5nPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJz
cDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXBwbGllZCBjb25maWcg
bm9kZXM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyZuYnNwOyAm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtCLiZu
YnNwOyBBYmlsaXR5IHRvIHJlbGF0ZSBpbnRlbmRlZCBjb25maWcgbm9kZXMgdG8gYXNzb2NpYXRl
ZCBkZXJpdmVkPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7c3RhdGUgbm9kZXM8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtDLiZuYnNwOyBUaGUgcmVsYXRp
b25zaGlwcyBuZWVkIHRvIGJlIHByb2dyYW1tYXRpY2FsbHkgY29uc3VtYWJsZTxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SWYgdGhlIG1vbml0b3JpbmcgaXMgcm9v
dGluZyB1bmRlciBjb25maWc9dHJ1ZSBub2RlcywgdGhlbiB0aG9zZSBjb25maWc9dHJ1ZTxvOnA+
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+bm9kZXMgbmVl
ZCB0byBiZSBjcmVhdGVkIHNvbWVob3cuJm5ic3A7IEEgY2xpZW50IHdpdGggd3JpdGUgYWNjZXNz
IGlzIHByb2JhYmx5IHJlcXVpcmVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5bS0VOVF0geWVzLCBidXQgdGhvc2UgY29uZmlnIHRydWUgYW5jZXN0b3Igbm9kZXMgY291
bGQgYmUgY3JlYXRlZCBieSBhbm90aGVyIGNsaWVudCB0aGF0IGhhcyB3cml0ZS1hY2Nlc3MsIHNp
bWlsYXIgdG8gUE9TSVggZmlsZXN5c3RlbS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPk11Y2ggZWFzaWVyIHRvIHNvbHZlIHRoZSBjb25mb3JtYW5jZSBzaW5jZSAv
Zm9vLXN0YXRlIGRvZXMgbm90IG5lZWQgYW55IG9iamVjdHMgZnJvbSAvZm9vPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj50byBleGlzdCBmaXJzdC4m
bmJzcDsgQ3JlYXRpbmcgdGhlIC9mb28gY29udGFpbmVyIG1lYW5zIHRoYXQgYWxsIGNvbmZpZz10
cnVlIHJlcXVpcmVtZW50cyBmb3I8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPnRoYXQgY29udGFpbmVyIG11c3QgYmUgaW1wbGVtZW50ZWQgKG9yIGNv
bXBsZXggZGV2aWF0aW9ucyB1c2VkKTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5bS0VOVF0gc2VlbXMgbGlrZSBhbiBpbXBsZW1lbnRhdGlvbiBkZXRhaWwuJm5ic3A7IFRo
ZSBjb25jZXB0dWFsIG1vZGVsIGlzIGZpbmUuJm5ic3A7ICZuYnNwOyZsdDtnZXQtY29uZmlnJmd0
OyBhbmQgbmV3ICZsdDtnZXQtc3RhdGUmZ3Q7IGNhbiBoYXZlIGRpZmZlcmVudCB2aWV3cy4mbmJz
cDsgJmx0O2dldC1jb25maWcmZ3Q7IHNob3VsZCBtYWludGFpbiB0aGUgdmlldyBvZiB0aGUgY29u
ZmlnIGZhbHNlIG5vZGVzIHJldHVybmVkIG5vdCBpbmNsdWRpbmcgc3lzdGVtLWdlbmVyYXRlZA0K
IG9iamVjdHMgKGUuZy4sIGludGVyZmFjZXMpLCB3aGVyZWFzICZsdDtnZXQtc3RhdGUmZ3Q7IGNh
biBhbHNvIHJldHVybiBzeXN0ZW0tZ2VuZXJhdGVkIG9iamVjdHMsIHNvbWUgb2Ygd2hpY2ggbWF5
IHJlcXVpcmUgYWxzbyByZXR1cm5pbmcgY29uZmlnIHRydWUgYW5jZXN0b3Igbm9kZXMuPG86cD48
L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o
dG1sPg0K

--_000_C2257A12930E4CD7AC9C1570145A82C0junipernet_--


From nobody Tue Aug  9 14:01: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 5468F12D89B for ; Tue,  9 Aug 2016 14:01:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hVZFbgDJ8pbQ for ; Tue,  9 Aug 2016 14:01:11 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 8A76C12B047 for ; Tue,  9 Aug 2016 14:01:11 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id 74so39812386uau.0 for ; Tue, 09 Aug 2016 14:01:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=X83mQZneAhoAO4phLE2gg1s/toURlt/Y/CS+3kBG8ls=; b=dXGxtfeWp7zmEMtveG6/psF2sfT4G2tiPPUa26zcRmWsogJoc2OsuL7zbRlM8SBPqv 4nSJMGhyNvNvIkc+Vrxwt34dO2InvyKseQyDpFJQLNrfSSarBUYpw2iec6DCcCoQOuP/ KV0tVJz8ooJZbHFyBJBHM7YKJLRxFbrM5/kNlhGZPleo7YFMZyItxM1Qt24ps+wM/nx3 khoDzxfeZRgCT6PXIA7X5lkfPPD5jSFj+SESz4PGPCYCv8cVp3hb7pIZ5S3KAvB+7qVt KAXe3QepfDo069C9utfc/DKtfQtGP01CD3oorhR7iwgbRfJapUuIk7Gs6ori4RBPd+C5 nuXw==
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:from:date :message-id:subject:to; bh=X83mQZneAhoAO4phLE2gg1s/toURlt/Y/CS+3kBG8ls=; b=hHmq3TdGUoa1OCqQyDL3oAETHWL+o82lqAjGmnPV1Dcb0lh0uySZxdu8Q+QM789l+5 enM70h37reEjckA9VtkYkYWa6BKO+iOSoRHwTDK7FES6MIwaCkU3DY3u2tnicMJDwkqV g7QuxINo4H3AywkYyfiK39THO7rIvQsrtBVnPtobLCbhm1zd9Ihmem/kZv0QSKDcLWQ0 cQIRZhQIZGAONHe8k+8zOJDBLMXRqDNOsQjgxj1yXLj1dX0LaGguNabWc6UaTpkD3AJX mGRNLRnZSum6vYltCAhG7ScgPlCGzZCCIiG683KceAMInmcaFI6jakvyY4ZM8KzUCo4A ei5Q==
X-Gm-Message-State: AEkoouupQWIHaDQdiSNu8cmsUM+VHn7w35yEBpCcI/Ud9R0c9Bw0dopOhHlNHrF4bs0JM4SL00t9qpzFdP96kA==
X-Received: by 10.176.3.72 with SMTP id 66mr204536uat.105.1470776470502; Tue, 09 Aug 2016 14:01:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Tue, 9 Aug 2016 14:01:09 -0700 (PDT)
In-Reply-To: <20160809133854.GD313@elstar.local>
References: <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net>  <4c5eedb9-ce73-3693-1e17-6012755a2fdd@cisco.com> <20160809133854.GD313@elstar.local>
From: Andy Bierman 
Date: Tue, 9 Aug 2016 14:01:09 -0700
Message-ID: 
To: Juergen Schoenwaelder , Robert Wilton ,  Andy Bierman , Kent Watsen , netmod WG 
Content-Type: multipart/alternative; boundary=001a113f26941198670539a9d57e
Archived-At: 
Subject: Re: [netmod] OpsState and 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, 09 Aug 2016 21:01:18 -0000

--001a113f26941198670539a9d57e
Content-Type: text/plain; charset=UTF-8

On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
> >
> > In particular, I think that the guideline would be along the lines:
> > If a given module "foo" only contains state and no configuration, then
> > having a single top-level "foo" config false node is fine, but if a given
> > module contains both config and state then the recommendation is to put
> that
> > under a config=true "foo" top-level node.  Refining that slightly, If the
> > state data is relevant even if "foo" hasn't been enabled then make the
> top
> > level "foo" an NP container.  If "foo" has to be enabled on the system
> for
> > the state data to be relevant then make "foo" a P container (or give it a
> > separate foo/enable leaf).  In summary, I would suggest that the foo
> state
> > data should be pushed as far down the combined config/state tree as
> > possible.  It should be sited below (or adjacent to) whichever config
> node
> > is required to make that state data relevant.
> >
> > If config and state are in the same tree then it is easy to return all
> the
> > data in one RPC, or have separate RPC operations that just return
> > configuration (e.g. ), or just return "state + containing
> > hieararchy" (e.g. a newly defined , or equivalent).
> >
> > Having separate foo vs foo-state trees at the top level is always going
> to
> > make it harder to return and manage a combined view of the config and
> state
> > data.
>
> I think it is crucial to separate (a) what protocols do today and (b)
> what protocols might do at some time in the future.
>
> The current protocol reality, that is (a), paired with the reality of
> network interfaces has lead to the (/interfaces, /interfaces-state)
> design pattern and until we have (b) in place I do not think we have
> really an alternative for the (/interfaces, /interfaces-state)
> design pattern.
>
> If you have config and state are in the same tree, you simply can't
> represent certain things that exist in reality. A single tree may look
> 'simpler' but in several cases also simply 'unusable'. We did not
> particularly like the (/interfaces, /interfaces-state) design but it
> was the only solution that seemed to work for all cases given the
> protocol reality we were in.
>
>
+1

IMO the suggestion of using YANG extensions to associate data from
different subtrees
was the most practical approach so far.  Moving objects and overloading
object location
semantics will have a big impact on existing code.  Adding metadata and RPC
operations
will not be disruptive, and it allows more complex associations to be
expressed.

If the config needs to exist in order for the opstate and statistics to be
relevant,
then of course put them in the config subtree.  But if they can be relevant
without config,
then the config data model has to be more complex to distinguish bogus
entries from real ones.
The YANG validation has to know the difference as well, adding hacks to
that code.
The access model needs to account for creation of bogus entries vs. real
ones,
adding an operational cost to this solution approach.

The YANG to use depends on the requirements.
The /foo-state tree can be considered "always on".
If this is not desired then a better design is to use a P-container:

   container foo {
     presence "Indicates foo counters are being collected";
     container foo-stats {
        config false;
        /...
     }
   }

This combination of config and state has a use-case.
I don't see a use-case for NP-container though.






/js
>


Andy


>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>

--001a113f26941198670539a9d57e
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilt=
on wrote:

>

> In particular, I think that the guideline would be along the lines:
> If a given module "foo" only contains state and no configura=
tion, then

> having a single top-level "foo" config false node is fine, b=
ut if a given

> module contains both config and state then the recommendation is to pu=
t that

> under a config=3Dtrue "foo" top-level node.=C2=A0 Refining t=
hat slightly, If the

> state data is relevant even if "foo" hasn't been enabled=
 then make the top

> level "foo" an NP container.=C2=A0 If "foo" has to=
 be enabled on the system for

> the state data to be relevant then make "foo" a P container =
(or give it a

> separate foo/enable leaf).=C2=A0 In summary, I would suggest that the =
foo state

> data should be pushed as far down the combined config/state tree as
> possible.=C2=A0 It should be sited below (or adjacent to) whichever co=
nfig node

> is required to make that state data relevant.

>

> If config and state are in the same tree then it is easy to return all=
 the

> data in one RPC, or have separate RPC operations that just return

> configuration (e.g. <get-config>), or just return "state + =
containing

> hieararchy" (e.g. a newly defined <get-state>, or equivalen=
t).

>

> Having separate foo vs foo-state trees at the top level is always goin=
g to

> make it harder to return and manage a combined view of the config and =
state

> data.



I think it is crucial to separate (a) what protocols do today and (b)

what protocols might do at some time in the future.



The current protocol reality, that is (a), paired with the reality of

network interfaces has lead to the (/interfaces, /interfaces-state)

design pattern and until we have (b) in place I do not think we have

really an alternative for the (/interfaces, /interfaces-state)

design pattern.



If you have config and state are in the same tree, you simply can't

represent certain things that exist in reality. A single tree may look

'simpler' but in several cases also simply 'unusable'. We d=
id not

particularly like the (/interfaces, /interfaces-state) design but it

was the only solution that seemed to work for all cases given the

protocol reality we were in.



+1

IMO the suggestion of us=
ing YANG extensions to associate data from different subtrees
was=
 the most practical approach so far.=C2=A0 Moving objects and overloading o=
bject location
semantics will have a big impact on existing code.=
=C2=A0 Adding metadata and RPC operations
will not be disruptive,=
 and it allows more complex associations to be expressed.

If the config needs to exist in order for the opstate and statistic=
s to be relevant,
then of course put them in the config subtree.=
=C2=A0 But if they can be relevant without config,
then the confi=
g data model has to be more complex to distinguish bogus entries from real =
ones.
The YANG validation has to know the difference as well, add=
ing hacks to that code.
The access model needs to account for cre=
ation of bogus entries vs. real ones,
adding an operational cost =
to this solution approach.

The YANG to use depends=
 on the requirements.
The /foo-state tree can be considered "=
;always on".
If this is not desired then a better design is =
to use a P-container:

=C2=A0 =C2=A0container foo {=

=C2=A0 =C2=A0 =C2=A0presence "Indicates foo counters are be=
ing collected";
=C2=A0 =C2=A0 =C2=A0container foo-stats {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;
=C2=A0 =C2=A0 =
=C2=A0 =C2=A0 /...
=C2=A0 =C2=A0 =C2=A0}
=C2=A0 =C2=A0}=


This combination of config and state has a use-ca=
se.
I don't see a use-case for NP-container though.







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





--001a113f26941198670539a9d57e--


From nobody Tue Aug  9 14:31: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 15FC812D146 for ; Tue,  9 Aug 2016 14:31: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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] 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 xi6_LinLWRfI for ; Tue,  9 Aug 2016 14:31:55 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0128.outbound.protection.outlook.com [104.47.41.128]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 65BF412B03F for ; Tue,  9 Aug 2016 14:31:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=rJO0Fgpib0SmEZzqjLXKh/nfCN+V21XnM97XqEVcwjQ=; b=QgUUw0sNwM8uoc19+1oT9fnadZQBb2YM5h/Y2AY583d+w2d3/EJco8ZUT90PqL1u02eUqU4nN1a70M7MTea9bRWxnipotmDOOIN2B7KmIyDHLrjR0R72iPZRHI6tfJsu40rqeO3EUZ4u+hyWisaXRmgOGWiWeJs3WtIa5zzam8k=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Tue, 9 Aug 2016 21:31:51 +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.0557.009; Tue, 9 Aug 2016 21:31:51 +0000
From: Kent Watsen 
To: Andy Bierman , Juergen Schoenwaelder , Robert Wilton , netmod WG 
Thread-Topic: [netmod] OpsState and Schema-Mount
Thread-Index: AQHR7Nwrg+3BeZANfEqM5r9gczFpmaA2zIQAgAAlNwCAAKDWgIABEGmAgAAzOACABnBxAIAAXauA///W/ICAAETLAIAA5W2AgAAHhQCAAHuOgP//xYUA
Date: Tue, 9 Aug 2016 21:31:51 +0000
Message-ID: <27A69432-1E9E-469D-8CE6-9A27996F97BE@juniper.net>
References: <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net>  <4c5eedb9-ce73-3693-1e17-6012755a2fdd@cisco.com> <20160809133854.GD313@elstar.local> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 456ecee1-cf2f-433d-4c10-08d3c09c938b
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:xsEFodgjzOJ/xLzB9v5PqzE6BKYL71x6zPM5jnGqrwgaXZRjH5ldLcKMphoUGePOVMGdxwr3coB4CmvBOpvntRvleBi57yfPASWmmEwOD9ygv065QznYt2Z3d7TxeBont5sbFJCaH2EJVt6pc8reGOWPBJz+rxte3mw8aCDRnTsLfZ6O0j1tX671BoBpGO98IkgVPhOHffEJaUzBFxjKo/P/gpu8K2VEkTEqFWOFUNGMtG4KyPwGD+fVHEekOIwXgQOeKZcOGYI4Oyhy0ilejlcPPBD55qTILYTeD2vdNw+JS60eaV/QLDBcn/Jr21NVZkVcCDrbqQYNPO8RbiFqIA==; 5:zjoL5k0YXe5HYaB2ZTs8Wc50IpsGIPP6vLc21v8f+JUg9QGE3+A0Macej1d6EHUp27H5Aez8Cg6ZypSH6ecmlP3YK3alnUr24k0VL6XWdhBLC2TooO9by5rkIRPP19CUsQ6lwsIqpHz37+O7m1FsiQ==; 24:zdFxBUzMqgv5lHFaPdQjtU4HPBOVgm9aCpiqUZbbUM1NiwREqo2scbE8yq7QTcVrM3wJinAm6UJylPFndIlPN+SSE1XYhmkOPYAsd0yYtp8=; 7:Hrfx6Vrj5sDO5bXekwkwuwtqgfAlh4Nn0g3yGlm96khrHofOz+fNVDGtZAY3Cj2jzlTe5eA+wgQ8mHCXk2XKiB1l0nLub0DPccEZvuw/dItlQxzCh39LL8rH2/mGBdlRERAej6AZhcox9HUTr/4VklL+D8FZo2ZP8rsDHOsdEsyB/85bsNVgz0iDD1QACYHQ71n3RYZZNmsnt9cpKwVqVCxxZl2MSiW6d4cIP5lhMYGi1z/CPQcL4jxEz5u9petD
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(95692535739014)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(601004)(2401047)(5005006)(8121501046)(3002001)(10201501046)(6055026);  SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; 
x-forefront-prvs: 0029F17A3F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(7916002)(199003)(377454003)(51444003)(24454002)(189002)(50986999)(19580395003)(8936002)(3660700001)(81156014)(36756003)(2950100001)(92566002)(5002640100001)(101416001)(8676002)(3280700002)(81166006)(77096005)(106356001)(19580405001)(19617315012)(87936001)(83716003)(19625215002)(2900100001)(15975445007)(11100500001)(106116001)(82746002)(83506001)(122556002)(5001770100001)(99286002)(105586002)(107886002)(3846002)(10400500002)(102836003)(19300405004)(7906003)(7736002)(6116002)(93886004)(86362001)(586003)(54356999)(66066001)(16236675004)(33656002)(7846002)(561944003)(68736007)(76176999)(189998001)(97736004)(2906002)(4001350100001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_27A694321E9E469D8CE69A27996F97BEjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Aug 2016 21:31:51.0331 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449
Archived-At: 
Subject: Re: [netmod] OpsState and 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, 09 Aug 2016 21:31:58 -0000

--_000_27A694321E9E469D8CE69A27996F97BEjunipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SnVlcmdlbiwgQW5keSwNCg0KSSB0aGluayB0aGF0IG15IHByb3Bvc2VkIHRleHQgZm9yIDYwODdi
aXMgY2xlYXJseSBhcnRpY3VsYXRlcyB3aGF0IHByb3RvY29scyBjYW4gZG8gdG9kYXkgYW5kIHRv
bW9ycm93LCB3aGlsZSBtYWtpbmcgYSAqdmVyeSBzdWJ0bGUqIHJlY29tbWVuZGF0aW9uIGZvciB0
b2RheeKAmXMgbW9kZWwgZGVzaWduZXJzIHRvIGZ1dHVyZS1wcm9vZiB0aGVpciBtb2RlbHMuDQoN
ClBsZWFzZSBmb2N1cyBvbiB0aGUgcHJvcG9zYWwsIGNvbnNpc3RlbnQgd2l0aCB0aGUgTG914oCZ
cyBjaGFpci1yZXF1ZXN0IChodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gvbXNnL25l
dG1vZC9OSzg2NG9YdklmZUFZb0NVVEs0MHduMkt3LTgpLg0KDQpLZW50IC8vIGFzIGEgY29udHJp
YnV0b3INCg0KDQpGcm9tOiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4NCkRhdGU6
IFR1ZXNkYXksIEF1Z3VzdCA5LCAyMDE2IGF0IDU6MDEgUE0NClRvOiBKdWVyZ2VuIFNjaG9lbndh
ZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4sIFJvYmVydCBXaWx0
b24gPHJ3aWx0b25AY2lzY28uY29tPiwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+
LCBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4sICJuZXRtb2RAaWV0Zi5vcmciIDxu
ZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBSZTogW25ldG1vZF0gT3BzU3RhdGUgYW5kIFNjaGVt
YS1Nb3VudA0KDQoNCg0KT24gVHVlLCBBdWcgOSwgMjAxNiBhdCA2OjM4IEFNLCBKdWVyZ2VuIFNj
aG9lbndhZWxkZXIgPGouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZTxtYWlsdG86
ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4gd3JvdGU6DQpPbiBUdWUsIEF1
ZyAwOSwgMjAxNiBhdCAwMjoxMjowMVBNICswMTAwLCBSb2JlcnQgV2lsdG9uIHdyb3RlOg0KPg0K
PiBJbiBwYXJ0aWN1bGFyLCBJIHRoaW5rIHRoYXQgdGhlIGd1aWRlbGluZSB3b3VsZCBiZSBhbG9u
ZyB0aGUgbGluZXM6DQo+IElmIGEgZ2l2ZW4gbW9kdWxlICJmb28iIG9ubHkgY29udGFpbnMgc3Rh
dGUgYW5kIG5vIGNvbmZpZ3VyYXRpb24sIHRoZW4NCj4gaGF2aW5nIGEgc2luZ2xlIHRvcC1sZXZl
bCAiZm9vIiBjb25maWcgZmFsc2Ugbm9kZSBpcyBmaW5lLCBidXQgaWYgYSBnaXZlbg0KPiBtb2R1
bGUgY29udGFpbnMgYm90aCBjb25maWcgYW5kIHN0YXRlIHRoZW4gdGhlIHJlY29tbWVuZGF0aW9u
IGlzIHRvIHB1dCB0aGF0DQo+IHVuZGVyIGEgY29uZmlnPXRydWUgImZvbyIgdG9wLWxldmVsIG5v
ZGUuICBSZWZpbmluZyB0aGF0IHNsaWdodGx5LCBJZiB0aGUNCj4gc3RhdGUgZGF0YSBpcyByZWxl
dmFudCBldmVuIGlmICJmb28iIGhhc24ndCBiZWVuIGVuYWJsZWQgdGhlbiBtYWtlIHRoZSB0b3AN
Cj4gbGV2ZWwgImZvbyIgYW4gTlAgY29udGFpbmVyLiAgSWYgImZvbyIgaGFzIHRvIGJlIGVuYWJs
ZWQgb24gdGhlIHN5c3RlbSBmb3INCj4gdGhlIHN0YXRlIGRhdGEgdG8gYmUgcmVsZXZhbnQgdGhl
biBtYWtlICJmb28iIGEgUCBjb250YWluZXIgKG9yIGdpdmUgaXQgYQ0KPiBzZXBhcmF0ZSBmb28v
ZW5hYmxlIGxlYWYpLiAgSW4gc3VtbWFyeSwgSSB3b3VsZCBzdWdnZXN0IHRoYXQgdGhlIGZvbyBz
dGF0ZQ0KPiBkYXRhIHNob3VsZCBiZSBwdXNoZWQgYXMgZmFyIGRvd24gdGhlIGNvbWJpbmVkIGNv
bmZpZy9zdGF0ZSB0cmVlIGFzDQo+IHBvc3NpYmxlLiAgSXQgc2hvdWxkIGJlIHNpdGVkIGJlbG93
IChvciBhZGphY2VudCB0bykgd2hpY2hldmVyIGNvbmZpZyBub2RlDQo+IGlzIHJlcXVpcmVkIHRv
IG1ha2UgdGhhdCBzdGF0ZSBkYXRhIHJlbGV2YW50Lg0KPg0KPiBJZiBjb25maWcgYW5kIHN0YXRl
IGFyZSBpbiB0aGUgc2FtZSB0cmVlIHRoZW4gaXQgaXMgZWFzeSB0byByZXR1cm4gYWxsIHRoZQ0K
PiBkYXRhIGluIG9uZSBSUEMsIG9yIGhhdmUgc2VwYXJhdGUgUlBDIG9wZXJhdGlvbnMgdGhhdCBq
dXN0IHJldHVybg0KPiBjb25maWd1cmF0aW9uIChlLmcuIDxnZXQtY29uZmlnPiksIG9yIGp1c3Qg
cmV0dXJuICJzdGF0ZSArIGNvbnRhaW5pbmcNCj4gaGllYXJhcmNoeSIgKGUuZy4gYSBuZXdseSBk
ZWZpbmVkIDxnZXQtc3RhdGU+LCBvciBlcXVpdmFsZW50KS4NCj4NCj4gSGF2aW5nIHNlcGFyYXRl
IGZvbyB2cyBmb28tc3RhdGUgdHJlZXMgYXQgdGhlIHRvcCBsZXZlbCBpcyBhbHdheXMgZ29pbmcg
dG8NCj4gbWFrZSBpdCBoYXJkZXIgdG8gcmV0dXJuIGFuZCBtYW5hZ2UgYSBjb21iaW5lZCB2aWV3
IG9mIHRoZSBjb25maWcgYW5kIHN0YXRlDQo+IGRhdGEuDQoNCkkgdGhpbmsgaXQgaXMgY3J1Y2lh
bCB0byBzZXBhcmF0ZSAoYSkgd2hhdCBwcm90b2NvbHMgZG8gdG9kYXkgYW5kIChiKQ0Kd2hhdCBw
cm90b2NvbHMgbWlnaHQgZG8gYXQgc29tZSB0aW1lIGluIHRoZSBmdXR1cmUuDQoNClRoZSBjdXJy
ZW50IHByb3RvY29sIHJlYWxpdHksIHRoYXQgaXMgKGEpLCBwYWlyZWQgd2l0aCB0aGUgcmVhbGl0
eSBvZg0KbmV0d29yayBpbnRlcmZhY2VzIGhhcyBsZWFkIHRvIHRoZSAoL2ludGVyZmFjZXMsIC9p
bnRlcmZhY2VzLXN0YXRlKQ0KZGVzaWduIHBhdHRlcm4gYW5kIHVudGlsIHdlIGhhdmUgKGIpIGlu
IHBsYWNlIEkgZG8gbm90IHRoaW5rIHdlIGhhdmUNCnJlYWxseSBhbiBhbHRlcm5hdGl2ZSBmb3Ig
dGhlICgvaW50ZXJmYWNlcywgL2ludGVyZmFjZXMtc3RhdGUpDQpkZXNpZ24gcGF0dGVybi4NCg0K
SWYgeW91IGhhdmUgY29uZmlnIGFuZCBzdGF0ZSBhcmUgaW4gdGhlIHNhbWUgdHJlZSwgeW91IHNp
bXBseSBjYW4ndA0KcmVwcmVzZW50IGNlcnRhaW4gdGhpbmdzIHRoYXQgZXhpc3QgaW4gcmVhbGl0
eS4gQSBzaW5nbGUgdHJlZSBtYXkgbG9vaw0KJ3NpbXBsZXInIGJ1dCBpbiBzZXZlcmFsIGNhc2Vz
IGFsc28gc2ltcGx5ICd1bnVzYWJsZScuIFdlIGRpZCBub3QNCnBhcnRpY3VsYXJseSBsaWtlIHRo
ZSAoL2ludGVyZmFjZXMsIC9pbnRlcmZhY2VzLXN0YXRlKSBkZXNpZ24gYnV0IGl0DQp3YXMgdGhl
IG9ubHkgc29sdXRpb24gdGhhdCBzZWVtZWQgdG8gd29yayBmb3IgYWxsIGNhc2VzIGdpdmVuIHRo
ZQ0KcHJvdG9jb2wgcmVhbGl0eSB3ZSB3ZXJlIGluLg0KDQorMQ0KDQpJTU8gdGhlIHN1Z2dlc3Rp
b24gb2YgdXNpbmcgWUFORyBleHRlbnNpb25zIHRvIGFzc29jaWF0ZSBkYXRhIGZyb20gZGlmZmVy
ZW50IHN1YnRyZWVzDQp3YXMgdGhlIG1vc3QgcHJhY3RpY2FsIGFwcHJvYWNoIHNvIGZhci4gIE1v
dmluZyBvYmplY3RzIGFuZCBvdmVybG9hZGluZyBvYmplY3QgbG9jYXRpb24NCnNlbWFudGljcyB3
aWxsIGhhdmUgYSBiaWcgaW1wYWN0IG9uIGV4aXN0aW5nIGNvZGUuICBBZGRpbmcgbWV0YWRhdGEg
YW5kIFJQQyBvcGVyYXRpb25zDQp3aWxsIG5vdCBiZSBkaXNydXB0aXZlLCBhbmQgaXQgYWxsb3dz
IG1vcmUgY29tcGxleCBhc3NvY2lhdGlvbnMgdG8gYmUgZXhwcmVzc2VkLg0KDQpJZiB0aGUgY29u
ZmlnIG5lZWRzIHRvIGV4aXN0IGluIG9yZGVyIGZvciB0aGUgb3BzdGF0ZSBhbmQgc3RhdGlzdGlj
cyB0byBiZSByZWxldmFudCwNCnRoZW4gb2YgY291cnNlIHB1dCB0aGVtIGluIHRoZSBjb25maWcg
c3VidHJlZS4gIEJ1dCBpZiB0aGV5IGNhbiBiZSByZWxldmFudCB3aXRob3V0IGNvbmZpZywNCnRo
ZW4gdGhlIGNvbmZpZyBkYXRhIG1vZGVsIGhhcyB0byBiZSBtb3JlIGNvbXBsZXggdG8gZGlzdGlu
Z3Vpc2ggYm9ndXMgZW50cmllcyBmcm9tIHJlYWwgb25lcy4NClRoZSBZQU5HIHZhbGlkYXRpb24g
aGFzIHRvIGtub3cgdGhlIGRpZmZlcmVuY2UgYXMgd2VsbCwgYWRkaW5nIGhhY2tzIHRvIHRoYXQg
Y29kZS4NClRoZSBhY2Nlc3MgbW9kZWwgbmVlZHMgdG8gYWNjb3VudCBmb3IgY3JlYXRpb24gb2Yg
Ym9ndXMgZW50cmllcyB2cy4gcmVhbCBvbmVzLA0KYWRkaW5nIGFuIG9wZXJhdGlvbmFsIGNvc3Qg
dG8gdGhpcyBzb2x1dGlvbiBhcHByb2FjaC4NCg0KVGhlIFlBTkcgdG8gdXNlIGRlcGVuZHMgb24g
dGhlIHJlcXVpcmVtZW50cy4NClRoZSAvZm9vLXN0YXRlIHRyZWUgY2FuIGJlIGNvbnNpZGVyZWQg
ImFsd2F5cyBvbiIuDQpJZiB0aGlzIGlzIG5vdCBkZXNpcmVkIHRoZW4gYSBiZXR0ZXIgZGVzaWdu
IGlzIHRvIHVzZSBhIFAtY29udGFpbmVyOg0KDQogICBjb250YWluZXIgZm9vIHsNCiAgICAgcHJl
c2VuY2UgIkluZGljYXRlcyBmb28gY291bnRlcnMgYXJlIGJlaW5nIGNvbGxlY3RlZCI7DQogICAg
IGNvbnRhaW5lciBmb28tc3RhdHMgew0KICAgICAgICBjb25maWcgZmFsc2U7DQogICAgICAgIC8u
Li4NCiAgICAgfQ0KICAgfQ0KDQpUaGlzIGNvbWJpbmF0aW9uIG9mIGNvbmZpZyBhbmQgc3RhdGUg
aGFzIGEgdXNlLWNhc2UuDQpJIGRvbid0IHNlZSBhIHVzZS1jYXNlIGZvciBOUC1jb250YWluZXIg
dGhvdWdoLg0KDQoNCg0KDQoNCg0KL2pzDQoNCg0KQW5keQ0KDQoNCi0tDQpKdWVyZ2VuIFNjaG9l
bndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21iSA0KUGhvbmU6
ICs0OSA0MjEgMjAwIDM1ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwg
R2VybWFueQ0KRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMgICAgICAgICA8aHR0cDovL3d3dy5qYWNv
YnMtdW5pdmVyc2l0eS5kZS8+DQoNCg==

--_000_27A694321E9E469D8CE69A27996F97BEjunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1z
dHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxvd2VkDQoJe21zby1zdHlsZS1w
cmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9
DQpzcGFuLmhvZW56Yg0KCXttc28tc3R5bGUtbmFtZTpob2VuemI7fQ0Kc3Bhbi5FbWFpbFN0eWxl
MTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJy
aTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4
cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxp
bmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBv
cnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXpl
OjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2Lldv
cmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0K
PGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVy
cGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTpDYWxpYnJpIj5KdWVyZ2Vu
LCBBbmR5LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPkkgdGhpbmsgdGhhdCBteSBwcm9wb3Nl
ZCB0ZXh0IGZvciA2MDg3YmlzIGNsZWFybHkgYXJ0aWN1bGF0ZXMgd2hhdCBwcm90b2NvbHMgY2Fu
IGRvIHRvZGF5IGFuZCB0b21vcnJvdywgd2hpbGUgbWFraW5nIGEgKnZlcnkgc3VidGxlKiByZWNv
bW1lbmRhdGlvbiBmb3IgdG9kYXnigJlzIG1vZGVsIGRlc2lnbmVycyB0byBmdXR1cmUtcHJvb2YN
CiB0aGVpciBtb2RlbHMuJm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPlBs
ZWFzZSBmb2N1cyBvbiB0aGUgcHJvcG9zYWwsIGNvbnNpc3RlbnQgd2l0aCB0aGUgTG914oCZcyBj
aGFpci1yZXF1ZXN0ICg8YSBocmVmPSJodHRwczovL21haWxhcmNoaXZlLmlldGYub3JnL2FyY2gv
bXNnL25ldG1vZC9OSzg2NG9YdklmZUFZb0NVVEs0MHduMkt3LTgiPmh0dHBzOi8vbWFpbGFyY2hp
dmUuaWV0Zi5vcmcvYXJjaC9tc2cvbmV0bW9kL05LODY0b1h2SWZlQVlvQ1VUSzQwd24yS3ctODwv
YT4pLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQgLy8gYXMgYSBjb250cmlidXRvcjxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEu
MHB0O2ZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxk
aXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAxLjBwdDtwYWRk
aW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTpDYWxpYnJpO2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+DQo8L2I+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmk7Y29sb3I6YmxhY2siPkFuZHkgQmllcm1h
biAmbHQ7YW5keUB5dW1hd29ya3MuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBB
dWd1c3QgOSwgMjAxNiBhdCA1OjAxIFBNPGJyPg0KPGI+VG86IDwvYj5KdWVyZ2VuIFNjaG9lbndh
ZWxkZXIgJmx0O2ouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZSZndDssIFJvYmVy
dCBXaWx0b24gJmx0O3J3aWx0b25AY2lzY28uY29tJmd0OywgQW5keSBCaWVybWFuICZsdDthbmR5
QHl1bWF3b3Jrcy5jb20mZ3Q7LCBLZW50IFdhdHNlbiAmbHQ7a3dhdHNlbkBqdW5pcGVyLm5ldCZn
dDssICZxdW90O25ldG1vZEBpZXRmLm9yZyZxdW90OyAmbHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxi
cj4NCjxiPlN1YmplY3Q6IDwvYj5SZTogW25ldG1vZF0gT3BzU3RhdGUgYW5kIFNjaGVtYS1Nb3Vu
dDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj5PbiBUdWUsIEF1ZyA5LCAyMDE2IGF0IDY6MzggQU0sIEp1ZXJnZW4gU2Nob2Vud2Fl
bGRlciAmbHQ7PGEgaHJlZj0ibWFpbHRvOmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0
eS5kZSIgdGFyZ2V0PSJfYmxhbmsiPmouc2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5k
ZTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRl
cjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBp
biA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+T24gVHVlLCBBdWcgMDksIDIw
MTYgYXQgMDI6MTI6MDFQTSAmIzQzOzAxMDAsIFJvYmVydCBXaWx0b24gd3JvdGU6PGJyPg0KJmd0
Ozxicj4NCiZndDsgSW4gcGFydGljdWxhciwgSSB0aGluayB0aGF0IHRoZSBndWlkZWxpbmUgd291
bGQgYmUgYWxvbmcgdGhlIGxpbmVzOjxicj4NCiZndDsgSWYgYSBnaXZlbiBtb2R1bGUgJnF1b3Q7
Zm9vJnF1b3Q7IG9ubHkgY29udGFpbnMgc3RhdGUgYW5kIG5vIGNvbmZpZ3VyYXRpb24sIHRoZW48
YnI+DQomZ3Q7IGhhdmluZyBhIHNpbmdsZSB0b3AtbGV2ZWwgJnF1b3Q7Zm9vJnF1b3Q7IGNvbmZp
ZyBmYWxzZSBub2RlIGlzIGZpbmUsIGJ1dCBpZiBhIGdpdmVuPGJyPg0KJmd0OyBtb2R1bGUgY29u
dGFpbnMgYm90aCBjb25maWcgYW5kIHN0YXRlIHRoZW4gdGhlIHJlY29tbWVuZGF0aW9uIGlzIHRv
IHB1dCB0aGF0PGJyPg0KJmd0OyB1bmRlciBhIGNvbmZpZz10cnVlICZxdW90O2ZvbyZxdW90OyB0
b3AtbGV2ZWwgbm9kZS4mbmJzcDsgUmVmaW5pbmcgdGhhdCBzbGlnaHRseSwgSWYgdGhlPGJyPg0K
Jmd0OyBzdGF0ZSBkYXRhIGlzIHJlbGV2YW50IGV2ZW4gaWYgJnF1b3Q7Zm9vJnF1b3Q7IGhhc24n
dCBiZWVuIGVuYWJsZWQgdGhlbiBtYWtlIHRoZSB0b3A8YnI+DQomZ3Q7IGxldmVsICZxdW90O2Zv
byZxdW90OyBhbiBOUCBjb250YWluZXIuJm5ic3A7IElmICZxdW90O2ZvbyZxdW90OyBoYXMgdG8g
YmUgZW5hYmxlZCBvbiB0aGUgc3lzdGVtIGZvcjxicj4NCiZndDsgdGhlIHN0YXRlIGRhdGEgdG8g
YmUgcmVsZXZhbnQgdGhlbiBtYWtlICZxdW90O2ZvbyZxdW90OyBhIFAgY29udGFpbmVyIChvciBn
aXZlIGl0IGE8YnI+DQomZ3Q7IHNlcGFyYXRlIGZvby9lbmFibGUgbGVhZikuJm5ic3A7IEluIHN1
bW1hcnksIEkgd291bGQgc3VnZ2VzdCB0aGF0IHRoZSBmb28gc3RhdGU8YnI+DQomZ3Q7IGRhdGEg
c2hvdWxkIGJlIHB1c2hlZCBhcyBmYXIgZG93biB0aGUgY29tYmluZWQgY29uZmlnL3N0YXRlIHRy
ZWUgYXM8YnI+DQomZ3Q7IHBvc3NpYmxlLiZuYnNwOyBJdCBzaG91bGQgYmUgc2l0ZWQgYmVsb3cg
KG9yIGFkamFjZW50IHRvKSB3aGljaGV2ZXIgY29uZmlnIG5vZGU8YnI+DQomZ3Q7IGlzIHJlcXVp
cmVkIHRvIG1ha2UgdGhhdCBzdGF0ZSBkYXRhIHJlbGV2YW50Ljxicj4NCiZndDs8YnI+DQomZ3Q7
IElmIGNvbmZpZyBhbmQgc3RhdGUgYXJlIGluIHRoZSBzYW1lIHRyZWUgdGhlbiBpdCBpcyBlYXN5
IHRvIHJldHVybiBhbGwgdGhlPGJyPg0KJmd0OyBkYXRhIGluIG9uZSBSUEMsIG9yIGhhdmUgc2Vw
YXJhdGUgUlBDIG9wZXJhdGlvbnMgdGhhdCBqdXN0IHJldHVybjxicj4NCiZndDsgY29uZmlndXJh
dGlvbiAoZS5nLiAmbHQ7Z2V0LWNvbmZpZyZndDspLCBvciBqdXN0IHJldHVybiAmcXVvdDtzdGF0
ZSAmIzQzOyBjb250YWluaW5nPGJyPg0KJmd0OyBoaWVhcmFyY2h5JnF1b3Q7IChlLmcuIGEgbmV3
bHkgZGVmaW5lZCAmbHQ7Z2V0LXN0YXRlJmd0Oywgb3IgZXF1aXZhbGVudCkuPGJyPg0KJmd0Ozxi
cj4NCiZndDsgSGF2aW5nIHNlcGFyYXRlIGZvbyB2cyBmb28tc3RhdGUgdHJlZXMgYXQgdGhlIHRv
cCBsZXZlbCBpcyBhbHdheXMgZ29pbmcgdG88YnI+DQomZ3Q7IG1ha2UgaXQgaGFyZGVyIHRvIHJl
dHVybiBhbmQgbWFuYWdlIGEgY29tYmluZWQgdmlldyBvZiB0aGUgY29uZmlnIGFuZCBzdGF0ZTxi
cj4NCiZndDsgZGF0YS48YnI+DQo8YnI+DQpJIHRoaW5rIGl0IGlzIGNydWNpYWwgdG8gc2VwYXJh
dGUgKGEpIHdoYXQgcHJvdG9jb2xzIGRvIHRvZGF5IGFuZCAoYik8YnI+DQp3aGF0IHByb3RvY29s
cyBtaWdodCBkbyBhdCBzb21lIHRpbWUgaW4gdGhlIGZ1dHVyZS48YnI+DQo8YnI+DQpUaGUgY3Vy
cmVudCBwcm90b2NvbCByZWFsaXR5LCB0aGF0IGlzIChhKSwgcGFpcmVkIHdpdGggdGhlIHJlYWxp
dHkgb2Y8YnI+DQpuZXR3b3JrIGludGVyZmFjZXMgaGFzIGxlYWQgdG8gdGhlICgvaW50ZXJmYWNl
cywgL2ludGVyZmFjZXMtc3RhdGUpPGJyPg0KZGVzaWduIHBhdHRlcm4gYW5kIHVudGlsIHdlIGhh
dmUgKGIpIGluIHBsYWNlIEkgZG8gbm90IHRoaW5rIHdlIGhhdmU8YnI+DQpyZWFsbHkgYW4gYWx0
ZXJuYXRpdmUgZm9yIHRoZSAoL2ludGVyZmFjZXMsIC9pbnRlcmZhY2VzLXN0YXRlKTxicj4NCmRl
c2lnbiBwYXR0ZXJuLjxicj4NCjxicj4NCklmIHlvdSBoYXZlIGNvbmZpZyBhbmQgc3RhdGUgYXJl
IGluIHRoZSBzYW1lIHRyZWUsIHlvdSBzaW1wbHkgY2FuJ3Q8YnI+DQpyZXByZXNlbnQgY2VydGFp
biB0aGluZ3MgdGhhdCBleGlzdCBpbiByZWFsaXR5LiBBIHNpbmdsZSB0cmVlIG1heSBsb29rPGJy
Pg0KJ3NpbXBsZXInIGJ1dCBpbiBzZXZlcmFsIGNhc2VzIGFsc28gc2ltcGx5ICd1bnVzYWJsZScu
IFdlIGRpZCBub3Q8YnI+DQpwYXJ0aWN1bGFybHkgbGlrZSB0aGUgKC9pbnRlcmZhY2VzLCAvaW50
ZXJmYWNlcy1zdGF0ZSkgZGVzaWduIGJ1dCBpdDxicj4NCndhcyB0aGUgb25seSBzb2x1dGlvbiB0
aGF0IHNlZW1lZCB0byB3b3JrIGZvciBhbGwgY2FzZXMgZ2l2ZW4gdGhlPGJyPg0KcHJvdG9jb2wg
cmVhbGl0eSB3ZSB3ZXJlIGluLjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+JiM0MzsxPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPklNTyB0aGUgc3VnZ2VzdGlvbiBvZiB1c2luZyBZ
QU5HIGV4dGVuc2lvbnMgdG8gYXNzb2NpYXRlIGRhdGEgZnJvbSBkaWZmZXJlbnQgc3VidHJlZXM8
bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPndhcyB0
aGUgbW9zdCBwcmFjdGljYWwgYXBwcm9hY2ggc28gZmFyLiZuYnNwOyBNb3Zpbmcgb2JqZWN0cyBh
bmQgb3ZlcmxvYWRpbmcgb2JqZWN0IGxvY2F0aW9uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5zZW1hbnRpY3Mgd2lsbCBoYXZlIGEgYmlnIGltcGFj
dCBvbiBleGlzdGluZyBjb2RlLiZuYnNwOyBBZGRpbmcgbWV0YWRhdGEgYW5kIFJQQyBvcGVyYXRp
b25zPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj53
aWxsIG5vdCBiZSBkaXNydXB0aXZlLCBhbmQgaXQgYWxsb3dzIG1vcmUgY29tcGxleCBhc3NvY2lh
dGlvbnMgdG8gYmUgZXhwcmVzc2VkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5JZiB0aGUgY29uZmlnIG5lZWRzIHRvIGV4aXN0IGluIG9yZGVy
IGZvciB0aGUgb3BzdGF0ZSBhbmQgc3RhdGlzdGljcyB0byBiZSByZWxldmFudCw8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPnRoZW4gb2YgY291cnNl
IHB1dCB0aGVtIGluIHRoZSBjb25maWcgc3VidHJlZS4mbmJzcDsgQnV0IGlmIHRoZXkgY2FuIGJl
IHJlbGV2YW50IHdpdGhvdXQgY29uZmlnLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+dGhlbiB0aGUgY29uZmlnIGRhdGEgbW9kZWwgaGFzIHRvIGJl
IG1vcmUgY29tcGxleCB0byBkaXN0aW5ndWlzaCBib2d1cyBlbnRyaWVzIGZyb20gcmVhbCBvbmVz
LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl
IFlBTkcgdmFsaWRhdGlvbiBoYXMgdG8ga25vdyB0aGUgZGlmZmVyZW5jZSBhcyB3ZWxsLCBhZGRp
bmcgaGFja3MgdG8gdGhhdCBjb2RlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+VGhlIGFjY2VzcyBtb2RlbCBuZWVkcyB0byBhY2NvdW50IGZvciBj
cmVhdGlvbiBvZiBib2d1cyBlbnRyaWVzIHZzLiByZWFsIG9uZXMsPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hZGRpbmcgYW4gb3BlcmF0aW9uYWwg
Y29zdCB0byB0aGlzIHNvbHV0aW9uIGFwcHJvYWNoLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgWUFORyB0byB1c2UgZGVwZW5kcyBvbiB0
aGUgcmVxdWlyZW1lbnRzLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+VGhlIC9mb28tc3RhdGUgdHJlZSBjYW4gYmUgY29uc2lkZXJlZCAmcXVvdDth
bHdheXMgb24mcXVvdDsuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj5JZiB0aGlzIGlzIG5vdCBkZXNpcmVkIHRoZW4gYSBiZXR0ZXIgZGVzaWduIGlz
IHRvIHVzZSBhIFAtY29udGFpbmVyOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7Y29udGFpbmVyIGZvbyB7PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5ic3A7
ICZuYnNwO3ByZXNlbmNlICZxdW90O0luZGljYXRlcyBmb28gY291bnRlcnMgYXJlIGJlaW5nIGNv
bGxlY3RlZCZxdW90Ozs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPiZuYnNwOyAmbmJzcDsgJm5ic3A7Y29udGFpbmVyIGZvby1zdGF0cyB7PG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsgY29uZmlnIGZhbHNlOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IC8u
Li48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyAmbmJzcDsgJm5ic3A7fTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+Jm5ic3A7ICZuYnNwO308bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBjb21iaW5hdGlvbiBvZiBjb25maWcgYW5k
IHN0YXRlIGhhcyBhIHVzZS1jYXNlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+SSBkb24ndCBzZWUgYSB1c2UtY2FzZSBmb3IgTlAtY29udGFpbmVy
IHRob3VnaC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
c3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGlu
ZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGNsYXNzPSJob2VuemIiPjxzcGFuIHN0eWxlPSJj
b2xvcjojODg4ODg4Ij4vanM8L3NwYW4+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9ibG9ja3F1
b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0K
PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5BbmR5PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpwPjwv
cD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNv
bGlkICNDQ0NDQ0MgMS4wcHQ7cGFkZGluZzowaW4gMGluIDBpbiA2LjBwdDttYXJnaW4tbGVmdDo0
LjhwdDttYXJnaW4tcmlnaHQ6MGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJjb2xvcjojODg4ODg4Ij48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj4tLTwvc3Bhbj48YnI+
DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5KdWVyZ2VuIFNjaG9lbndhZWxkZXImbmJzcDsgJm5ic3A7
ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwO0phY29icyBVbml2ZXJzaXR5IEJyZW1lbiBnR21i
SDwvc3Bhbj48YnI+DQo8c3BhbiBjbGFzcz0iaG9lbnpiIj5QaG9uZTogJiM0Mzs0OSA0MjEgMjAw
IDM1ODcmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Q2FtcHVzIFJpbmcgMSB8IDI4
NzU5IEJyZW1lbiB8IEdlcm1hbnk8L3NwYW4+PGJyPg0KPHNwYW4gY2xhc3M9ImhvZW56YiI+RmF4
OiZuYnNwOyAmbmJzcDsmIzQzOzQ5IDQyMSAyMDAgMzEwMyZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsmbHQ7PGEgaHJlZj0iaHR0cDovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8i
IHRhcmdldD0iX2JsYW5rIj5odHRwOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRlLzwvYT4mZ3Q7
PC9zcGFuPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_27A694321E9E469D8CE69A27996F97BEjunipernet_--


From nobody Tue Aug  9 14:57: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 049CC12D56C; Tue,  9 Aug 2016 14:57:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Level: 
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 jIxkV-XV817I; Tue,  9 Aug 2016 14:57:10 -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 E19F312D5AE; Tue,  9 Aug 2016 14:57:09 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 327ADFDE; Tue,  9 Aug 2016 23:57:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id sKLutiAz2VBp; Tue,  9 Aug 2016 23:57:01 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue,  9 Aug 2016 23:57:03 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id E717B2009D; Tue,  9 Aug 2016 23:57:02 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Qdq82mfnPWT0; Tue,  9 Aug 2016 23:57:00 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 47AF22008D; Tue,  9 Aug 2016 23:57:00 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5F5673C15C3E; Tue,  9 Aug 2016 23:56:59 +0200 (CEST)
Date: Tue, 9 Aug 2016 23:56:58 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20160809215658.GA1644@elstar.local>
Mail-Followup-To: Kent Watsen , Lou Berger , "netmod@ietf.org" , "draft-ietf-netmod-rfc6087bis@ietf.org" 
References: <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>     <125693B9-D275-495E-90BE-514803A75C0D@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <125693B9-D275-495E-90BE-514803A75C0D@juniper.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "draft-ietf-netmod-rfc6087bis@ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] OpsState Direction Impact on Recommended IETF YANG Model Structure
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, 09 Aug 2016 21:57:13 -0000

Comments inline... I generally like the approach of explaining the
situation so that module writers can take an informed decision. I am
struggling a bit with the strong recommendation given and I am not
sure whether using two separate modules for /foo and /foo-state makes
things really simpler.

/js

On Tue, Aug 02, 2016 at 01:10:05AM +0000, Kent Watsen wrote:
> 
> 
> Following Lou’s recommendation, my proposed changes for rfc6087bis Section 5.23 follow:
> 
> 
> 5.23.  Operational Data
> 
>    In YANG, any data that has a "config" statement value of "false"
>    could be considered operational data.  The relationship between
>    configuration (i.e., "config" statement has a value of "true") and
>    operational data can be complex.
> 
> -   One challenge for client developers is determining if the configured
> -   value is being used, which requires the developer to know which
> -   operational data parameters are associated with the particular
> +  One challenge for client applications is determining if a configured
> +  value is being used, which requires the application to know which
> +  operational data parameters are associated with a particular
>    configuration object (or group of objects).
> 
>    In the simplest use-cases, there is no interaction between
>    configuration and operational data.  For example, the arbitrary
>    administrative name or sequence number assigned to an access control
>    rule.  The configured value is always the value that is being used by
>    the system.
> 
>    However, some configuration parameters interact with routing and
> -   other signalling protocols, such that the operational value in use by
> +  other signaling protocols, such that the operational value in use by
>    the system may not be the same as the configured value.  Other
>    parameters specify the desired state, but environmental and other
>    factors can cause the actual state to be different.
> 
> -   For example a "temperature" configuration setting only represents the
> +   For example, a "temperature" configuration setting only represents the
>    desired temperature.  An operational data parameter is needed that
>    reports the actual temperature in order to determine if the cooling
>    system is operating correctly.  YANG has no mechanism other than the
>    "description" statement to associate the desired temperature and the
>    actual temperature.
> 
>   [Editor’s Note: we should define a ‘related-config’ statement ASAP!]
> 
>    Careful consideration needs to be given to the location of
>    operational data.  It can either be located within the configuration
>    subtree for which it applies, or it can be located outside the
>    particular configuration subtree.  Placing operational data within
> -   the configuration subtree is appropriate if the operational values
> -   can only exist if the configuration exists.
> +   the configuration subtree is ideal, as the association between the
> +   configuration and operational state is clear.  However, doing so must
> +   be done with the knowledge that NETCONF and RESTCONF can 
> +   currently only return the operational state for configured values,
> +   not system generated values such as system created interfaces or
> +   routing table entries.   This is because the config false nodes are 
> +   descendants of config true nodes and hence cannot be returned
> +   for nodes that haven’t been configured.   At least, this is the case
> +   for how NETCONF and RESTCONF currently support returning
> +   mixed config true and config false content.
> 
> 
> -   The "interfaces" and "interfaces-state" subtrees defined in [RFC7223]
> -   are an example of a complex relationship between configuration and
> -   operational data.  The operational values can include interface
> -   entries that have been discovered or initialized by the system.  An
> -   interface may be in use that has not been configured at all.
> -   Therefore, the operational data for an interface cannot be located
> -   within the configuration for that same interface.
> +   In order to support returning operational state for system generated
> +   values, some YANG module designers have created a parallel top-level
> +   config false hierarchy that mirrors the structure of the config true 
> +   hierarchy.  For instance, this is seen in the ‘interfaces-state’ node in 
> +   [RFC7223].  By doing this, it enables the operational state for system
> +   generated values to be returned, since then all the ancestor nodes are
> +   config false as well.  However, this approach is not ideal as it leads to 
> +   needing to maintain duplicate structures and also requires the use of
> +   description statements to describe the association between the two
> +   structures.
> 
> +   To address this situation, the NETMOD and NETCONF working groups
> +   are at this time in the process of defining a holistic operational state
> +   solution that entails both a revised conceptual datastore model and
> +   the necessary protocol extensions to enable, in part, both NETCONF
> +   and RESTCONF to be able to return operational state for system
> +   generated values using the same config true hierarchy used to return
> +   the operational state for configured values.

I do not know what a 'holistic operational state solution is'.
Interestingly, the revised datastore design team is _not_ tasked to
address the operational state datastore (even though this might still
fall out of their work).

> +   This being the case, it is RECOMMENDED that YANG module designers
> +   always mix config true and config false nodes into a single hierarchy.

I have a problem with this. In several situations, this is the wrong
thing to do until there is a solution where doing so makes sense. 

> +   This is so the YANG modules will be in proper form for when the
> +   holistic operational state solution is available.   To address any 
> +   immediate needs to also report the operational state for system
> +   generated values, it is RECOMMENDED to define a second module
> +   that imports the first module and defines a parallel top-level
> +   config false hierarchy that mirrors the structure of the config true 
> +   hierarchy in the first module.   This recommendation is made to
> +   enable NETCONF/RESTCONF servers supporting the finalized
> +   opstate solution to choose when to stop supporting the second 
> +   module, as it would then only be needed to support legacy 
> +   opstate-unaware clients.

Factoring things into separate modules may be a workable idea but it
is just a different variant from simply deprecating /foo-state nodes
onces there is a solution in place that can work with a single tree.
I have no clear view what the trade-offs between the two options
really are.

> FOUR SCENARIOS:
> 
> 1) an opstate-unaware server might only support “ietf-foo”, as it is deemed unnecessary to provide the operational state for system-generated bars.  A client can get the operational state for just the configured bars using NETCONF’s  or RESTCONF’s content ‘all’ query parameter.
>  
> 2) an opstate-unaware server might support both “ietf-foo” and “ietf-foo-state”, as it is deemed important to provide the operational state for system-generated bars.   Same as above, a client can get the operational state for just the configured bars, when targeting the “ietf-foo” module.  Better though, a client can get the operational state for both configured and system-generated bars together when targeting the “ietf-foo-state” module.  A client that is savvy enough to do this would of course not want the redundant operational state data from the ietf-foo module and therefore would likely only use NETCONF’s  and/or RESTCONF’s content ‘config’ query parameter when targeting the “ietf-foo” module.

Not sure what 'targeting the “ietf-foo-state” module means in protocol
terms. If you select all in ietf-foo-state, you will likely get all in
ietf-foo-state and not more. I am not sure I understand the argument,
it all boils down how you use filters.

> 3) an opstate-aware server might only support “ietf-foo”, as it can provide the operational state for both configured and system-generated bars using protocol mechanisms defined by the holistic opstate solution (e.g., via an “operational” datastore), and it doesn’t care about enabling legacy opstate-unaware clients to be able to obtain the operational state for the system generated bars.
> 
> 4) an opstate-aware server might support both “ietf-foo” and “ietf-foo-state”, so that it can provide the operational state for both configured and system-generated bars to both opstate-aware and opstate-unaware clients.  This is hopefully a temporary condition as eventually the clients will be upgraded to be opstate-aware and then the vendor can deprecate support for the ietf-foo-state module.

I think the same works with /foo and /foo-state in one module with
/foo-state eventually being deprecated. The real costs, likely, is
that some modules provide definitions other modules build on and it
does not matter how you organize the trees into modules - once you
have many dependent modules, making changes is going to be hard.
 
> WHY IMPORT?   The text above includes the statement “it is RECOMMENDED to define a second module that imports the first module”.  Technically, there isn’t a need for the import as of yet, but I’m very much thinking that we should *quickly* define a YANG statement called “related-config” that allows the client to programmatically related which config true nodes in the first module might are associated to the config false nodes in the second module.  Obviously, this would only make the association for configured values, and the client could assume that any key-misses are the result of the that operational state being for a system-generated value.  The association has to be in that direction because config false nodes can point to config true nodes, but not visa versa.
 
An IMPORT makes sense if there is something to import. It does not
make sense to IMPORT a module just because in the future such an
import may be useful.

/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 Aug  9 16:04:57 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 B6A7012B02B for ; Tue,  9 Aug 2016 16:04:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fMnXZ8vkSHhg for ; Tue,  9 Aug 2016 16:04:53 -0700 (PDT)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 0646012D1DE for ; Tue,  9 Aug 2016 16:04:53 -0700 (PDT)
Received: by mail-ua0-x234.google.com with SMTP id k90so43936918uak.1 for ; Tue, 09 Aug 2016 16:04:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bz576Lmj6zACiabcHzQ6h2vIqocgPjlMqnMTiWvXW7c=; b=VXidNKgm783PvSlWmdxUS8AuanUX6ZWNKyrc3r8mCSngMc6kTUQMZUjLyqUQiXKK+e fcoa7T4EV0hGXqvBG4aELe4j/gKDtZVBbiMShDslW3rXHxGjiS4WajL3Von/NzF/7dgh WFpvhRK9G5d2oGA6RvQC2n4ga9I8/ANb33qPeSBAayKJHO3Fq4EXdB7HA69fPDpjnKoP vZBZ5A5HjbE4cSNtHj9+Hkdd7y6rV+j+jRUvYnIYlxlcsrTf6iQri3vu491JI68Jq/83 jTG2+wmNN3DnyA1TO/+SYSEq8xkTmO62mnzAoOMeOXCBWN3kYCBoiEADMCYzNLgYIuLm PHRA==
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:from:date :message-id:subject:to:cc; bh=bz576Lmj6zACiabcHzQ6h2vIqocgPjlMqnMTiWvXW7c=; b=dTGHwIEi89lfs6/BL35Wls08z5SEeYYejUKi6gZNhr0mt36tYSh221LabNpQc3mShZ OYg3XvmnPpJIgFhRzkBRPVzabC5ux+w+wrC03rKLyxkageIVwAtNvqIcmuW5hpcYAE7y 0mLgsSCPStrivtdasFM5zsC+xv3kJK4fLEgbwDtTKo55bYq2rYTbtL3X4mrH0uIITiMj VzGEMnag9KMi+O8M/VDQZjDR6JlfFe/KD3aKnazKhUER1jK6DTRI8LgrslMRNowUiwEY ChKn5HD5Afnrra/BohZK2WK0DC7hD1j+R912Ck0TMr3GjzyUIQNosjIxfYYDAQUFubmq ESTQ==
X-Gm-Message-State: AEkoouvCYD99gW69VmsjziljwEODwad0FGnYZe0xquCrIOJRM6WoO3AVqMlDdrjINf1O7ZMO2NP/wkXg54fT8g==
X-Received: by 10.31.136.70 with SMTP id k67mr453870vkd.13.1470783892115; Tue, 09 Aug 2016 16:04:52 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Tue, 9 Aug 2016 16:04:51 -0700 (PDT)
In-Reply-To: <27A69432-1E9E-469D-8CE6-9A27996F97BE@juniper.net>
References: <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <673D4236-7564-4B64-8088-BE6CBA3A790E@juniper.net>  <4c5eedb9-ce73-3693-1e17-6012755a2fdd@cisco.com> <20160809133854.GD313@elstar.local>  <27A69432-1E9E-469D-8CE6-9A27996F97BE@juniper.net>
From: Andy Bierman 
Date: Tue, 9 Aug 2016 16:04:51 -0700
Message-ID: 
To: Kent Watsen 
Content-Type: multipart/alternative; boundary=001a11440bb66e69fd0539ab8f3a
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 09 Aug 2016 23:04:56 -0000

--001a11440bb66e69fd0539ab8f3a
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

I do not see any justification to RECOMMEND a combined tree.
I do not think 6087bis should give guidelines based on speculation
about a new holistic architecture in the future,

I agree with Juergen that the pros and cons of different approaches
should be discussed, and designers can decide which trade-offs
work best for them.


Andy


On Tue, Aug 9, 2016 at 2:31 PM, Kent Watsen  wrote:

> Juergen, Andy,
>
>
>
> I think that my proposed text for 6087bis clearly articulates what
> protocols can do today and tomorrow, while making a *very subtle*
> recommendation for today=E2=80=99s model designers to future-proof their =
models.
>
>
>
> Please focus on the proposal, consistent with the Lou=E2=80=99s chair-req=
uest (
> https://mailarchive.ietf.org/arch/msg/netmod/NK864oXvIfeAYoCUTK40wn2Kw-8)=
.
>
>
>
> Kent // as a contributor
>
>
>
>
>
> *From: *Andy Bierman 
> *Date: *Tuesday, August 9, 2016 at 5:01 PM
> *To: *Juergen Schoenwaelder ,
> Robert Wilton , Andy Bierman ,
> Kent Watsen , "netmod@ietf.org" 
> *Subject: *Re: [netmod] OpsState and Schema-Mount
>
>
>
>
>
>
>
> On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
> On Tue, Aug 09, 2016 at 02:12:01PM +0100, Robert Wilton wrote:
> >
> > In particular, I think that the guideline would be along the lines:
> > If a given module "foo" only contains state and no configuration, then
> > having a single top-level "foo" config false node is fine, but if a giv=
en
> > module contains both config and state then the recommendation is to put
> that
> > under a config=3Dtrue "foo" top-level node.  Refining that slightly, If=
 the
> > state data is relevant even if "foo" hasn't been enabled then make the
> top
> > level "foo" an NP container.  If "foo" has to be enabled on the system
> for
> > the state data to be relevant then make "foo" a P container (or give it=
 a
> > separate foo/enable leaf).  In summary, I would suggest that the foo
> state
> > data should be pushed as far down the combined config/state tree as
> > possible.  It should be sited below (or adjacent to) whichever config
> node
> > is required to make that state data relevant.
> >
> > If config and state are in the same tree then it is easy to return all
> the
> > data in one RPC, or have separate RPC operations that just return
> > configuration (e.g. ), or just return "state + containing
> > hieararchy" (e.g. a newly defined , or equivalent).
> >
> > Having separate foo vs foo-state trees at the top level is always going
> to
> > make it harder to return and manage a combined view of the config and
> state
> > data.
>
> I think it is crucial to separate (a) what protocols do today and (b)
> what protocols might do at some time in the future.
>
> The current protocol reality, that is (a), paired with the reality of
> network interfaces has lead to the (/interfaces, /interfaces-state)
> design pattern and until we have (b) in place I do not think we have
> really an alternative for the (/interfaces, /interfaces-state)
> design pattern.
>
> If you have config and state are in the same tree, you simply can't
> represent certain things that exist in reality. A single tree may look
> 'simpler' but in several cases also simply 'unusable'. We did not
> particularly like the (/interfaces, /interfaces-state) design but it
> was the only solution that seemed to work for all cases given the
> protocol reality we were in.
>
>
>
> +1
>
>
>
> IMO the suggestion of using YANG extensions to associate data from
> different subtrees
>
> was the most practical approach so far.  Moving objects and overloading
> object location
>
> semantics will have a big impact on existing code.  Adding metadata and
> RPC operations
>
> will not be disruptive, and it allows more complex associations to be
> expressed.
>
>
>
> If the config needs to exist in order for the opstate and statistics to b=
e
> relevant,
>
> then of course put them in the config subtree.  But if they can be
> relevant without config,
>
> then the config data model has to be more complex to distinguish bogus
> entries from real ones.
>
> The YANG validation has to know the difference as well, adding hacks to
> that code.
>
> The access model needs to account for creation of bogus entries vs. real
> ones,
>
> adding an operational cost to this solution approach.
>
>
>
> The YANG to use depends on the requirements.
>
> The /foo-state tree can be considered "always on".
>
> If this is not desired then a better design is to use a P-container:
>
>
>
>    container foo {
>
>      presence "Indicates foo counters are being collected";
>
>      container foo-stats {
>
>         config false;
>
>         /...
>
>      }
>
>    }
>
>
>
> This combination of config and state has a use-case.
>
> I don't see a use-case for NP-container though.
>
>
>
>
>
>
>
>
>
>
>
>
>
> /js
>
>
>
>
>
> Andy
>
>
>
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
>
>

--001a11440bb66e69fd0539ab8f3a
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I do not see any justification to R=
ECOMMEND a combined tree.
I do not think 6087bis should give guid=
elines based on speculation
about a new holistic architecture in =
the future,

I agree with Juergen that the pros and=
 cons of different approaches
should be discussed, and designers =
can decide which trade-offs
work best for them.


Andy


On Tue, Aug 9, 2016 at 2:31 PM, Kent W=
atsen <kwatsen@juniper.net> wrote:













Juergen, Andy,


=C2=A0


I think that my proposed text for 6087bis clearly articulates what protoco=
ls can do today and tomorrow, while making a *very subtle* recommendation f=
or today=E2=80=99s model designers to future-proof
 their models.=C2=A0=C2=A0 


=C2=A0


Please focus on the proposal, consistent with the Lou=E2=80=99s chair-requ=
est (https://mailarchive.ietf.org/arch/msg=
/netmod/NK864oXvIfeAYoCUTK40wn2Kw-8).


=C2=A0


Kent // as a contributor


=C2=A0


=C2=A0




F=
rom: 
Andy Bierman <andy@yumaworks.com>=
;

Date: Tuesday, August 9, 2016 at 5:01 PM

To: Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.=
de>, Robert Wilton <rwilton@cisco.com>, Andy Bierman <andy@yumaworks.com>, Kent Watse=
n <kwatsen@juni=
per.net>, "netmod@ietf.org" <netmod@ietf.org>

Subject: Re: [netmod] OpsState and Schema-Mount=







=C2=A0










=C2=A0




=C2=A0




On Tue, Aug 9, 2016 at 6:38 AM, Juergen Schoenwaelde=
r <j.schoenwaelder@jacobs-university.de> wrote:=





On Tue, Aug 09, 2016 =
at 02:12:01PM +0100, Robert Wilton wrote:

>

> In particular, I think that the guideline would be along the lines:
> If a given module "foo" only contains state and no configura=
tion, then

> having a single top-level "foo" config false node is fine, b=
ut if a given

> module contains both config and state then the recommendation is to pu=
t that

> under a config=3Dtrue "foo" top-level node.=C2=A0 Refining t=
hat slightly, If the

> state data is relevant even if "foo" hasn't been enabled=
 then make the top

> level "foo" an NP container.=C2=A0 If "foo" has to=
 be enabled on the system for

> the state data to be relevant then make "foo" a P container =
(or give it a

> separate foo/enable leaf).=C2=A0 In summary, I would suggest that the =
foo state

> data should be pushed as far down the combined config/state tree as
> possible.=C2=A0 It should be sited below (or adjacent to) whichever co=
nfig node

> is required to make that state data relevant.

>

> If config and state are in the same tree then it is easy to return all=
 the

> data in one RPC, or have separate RPC operations that just return

> configuration (e.g. <get-config>), or just return "state + =
containing

> hieararchy" (e.g. a newly defined <get-state>, or equivalen=
t).

>

> Having separate foo vs foo-state trees at the top level is always goin=
g to

> make it harder to return and manage a combined view of the config and =
state

> data.



I think it is crucial to separate (a) what protocols do today and (b)

what protocols might do at some time in the future.



The current protocol reality, that is (a), paired with the reality of

network interfaces has lead to the (/interfaces, /interfaces-state)

design pattern and until we have (b) in place I do not think we have

really an alternative for the (/interfaces, /interfaces-state)

design pattern.



If you have config and state are in the same tree, you simply can't

represent certain things that exist in reality. A single tree may look

'simpler' but in several cases also simply 'unusable'. We d=
id not

particularly like the (/interfaces, /interfaces-state) design but it

was the only solution that seemed to work for all cases given the

protocol reality we were in.






=C2=A0






+1






=C2=A0






IMO the suggestion of using YANG extensions to assoc=
iate data from different subtrees






was the most practical approach so far.=C2=A0 Moving=
 objects and overloading object location






semantics will have a big impact on existing code.=
=C2=A0 Adding metadata and RPC operations






will not be disruptive, and it allows more complex a=
ssociations to be expressed.






=C2=A0






If the config needs to exist in order for the opstat=
e and statistics to be relevant,






then of course put them in the config subtree.=C2=A0=
 But if they can be relevant without config,






then the config data model has to be more complex to=
 distinguish bogus entries from real ones.






The YANG validation has to know the difference as we=
ll, adding hacks to that code.






The access model needs to account for creation of bo=
gus entries vs. real ones,






adding an operational cost to this solution approach=
.






=C2=A0






The YANG to use depends on the requirements.<=
u>






The /foo-state tree can be considered "always o=
n".






If this is not desired then a better design is to us=
e a P-container:






=C2=A0






=C2=A0 =C2=A0container foo {






=C2=A0 =C2=A0 =C2=A0presence "Indicates foo cou=
nters are being collected";






=C2=A0 =C2=A0 =C2=A0container foo-stats {<=
/u>






=C2=A0 =C2=A0 =C2=A0 =C2=A0 config false;<=
/u>






=C2=A0 =C2=A0 =C2=A0 =C2=A0 /...






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






=C2=A0 =C2=A0}






=C2=A0






This combination of config and state has a use-case.=







I don't see a use-case for NP-container though.<=
u>






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0






=C2=A0






/js






=C2=A0






=C2=A0






Andy






=C2=A0








--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs =
University Bremen gGmbH

Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campus Ring =
1 | 28759 Bremen | Germany

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0&l=
t;http://www=
.jacobs-university.de/>






=C2=A0


















--001a11440bb66e69fd0539ab8f3a--


From nobody Wed Aug 10 04:39: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 EDD4D12D7A5 for ; Wed, 10 Aug 2016 04:39:37 -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 2MstftrvsjFC for ; Wed, 10 Aug 2016 04:39:35 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id F06EA12D159 for ; Wed, 10 Aug 2016 04:39:34 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 608AF1CC00D1; Wed, 10 Aug 2016 13:39:46 +0200 (CEST)
From: Ladislav Lhotka 
To: Andy Bierman , Robert Wilton 
In-Reply-To: 
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <2e78a895-84d3-6381-ca34-f49a830f3bb0@cisco.com> 
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Wed, 10 Aug 2016 13:39:31 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] OpsState and 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, 10 Aug 2016 11:39:38 -0000

Andy Bierman  writes:

> On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton  wrote:
>
>> Hi Andy,
>> I don't properly understand the points that you are making, please see
>> clarifying comments/questions inline ...
>>
>> On 08/08/2016 22:51, Andy Bierman wrote:
>>
>>
>>
>> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  wrote:
>>
>>> Acee writes:
>>> >    Then I see no YANG language barriers in collapsing config and state
>>> trees
>>> >    - the model root just needs to be =E2=80=9Cconfig true=E2=80=9D.
>>>
>>> Great, I think we=E2=80=99re all agreed.  Can we now discuss the text I=
 proposed
>>> for 6087bis?  - here=E2=80=99s the link to my proposal:
>>> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0=
s.
>>>
>>>
>> IMO this effort to avoid 2 containers is not well thought out.
>> Some concerns:
>>
>> 1) modularity
>>     placing the monitoring objects within the configuration means the
>> monitoring
>>     cannot be used on its own
>>
>> If it is one module with two top level augments (foo and foo-state) then
>> this problem still exists.  Hence, please can you clarify why converging
>> them on a single root node means that monitoring cannot be used on it ow=
n?
>> Wouldn't a device need to use deviations in both cases to strip out the
>> config nodes that they are not supporting?
>>
>>
> Before the "rule" I can choose to place monitoring in its own module
> without any reliance on other modules.  If the monitoring does not
> share indexing, what value is there in putting it in the config tree?
> I see none except a poor attempt at model classification.

Sometimes it may indeed make sense to keep configuration and state data
schemas in different modules. For instance, it may be useful (or even
necessary) to have common configuration but different state data for
different implementations, e.g. when devices use vastly different
internal architectures.

One example are packet filters: while it may be possible to have a
common configuration for Linux nftables and Cisco ACLs, monitoring or
debugging either implementation requires access to what the system is
doing under the hood, i.e. system-specific state data and counters.

Lada

>
>
>
>>
>>
>> 2) access control
>>     placing the monitoring data within configuration means the
>> monitoring-only clients
>>     need write permission turned on for the nodes they can access for
>> read-only
>>     This relies on granular and complex NACM rules which require regular
>> maintenance.
>>
>> Again, I don't quite follow this, in the specific example that I have
>> regarding putting a RIB under a config true NP container, I would have
>> thought that NACM read access would have been sufficient for a
>> monitoring-only client.  Is that not the case?
>>
>
>
> If the monitoring is rooting under config=3Dtrue nodes, then those config=
=3Dtrue
> nodes need to be created somehow.  A client with write access is probably
> required.
>
>
>
>>
>>
>> 3) YANG conformance
>>     placing the monitoring data inside the configuration means the
>> configuration
>>     will be required for conformance; it is not likely to be just 1 NP
>> container.
>>
>> Similar to my response to the first question, I thought that conformance
>> was done on a per module base, not a per sub-tree basis.  So even if you
>> have top level 'foo' and 'foo-state' as part of the same module don't you
>> run into the same conformance problem?
>>
>>
>>
> Much easier to solve the conformance since /foo-state does not need any
> objects from /foo
> to exist first.  Creating the /foo container means that all config=3Dtrue
> requirements for
> that container must be implemented (or complex deviations used)
>
>
>>
>> 4) pointless;
>>    given that new RPC operations are needed to access applied config, the
>> only data not
>>    affected (and moved under the config container anyway) is stuff that
>> does not share
>>    the same indexing, or counters which are not part of the opstate
>> problem.
>>
>> Sorry, I don't really follow this one.  The original opstate draft put
>> forward by OpenConfig was asking for both applied-configuration and deri=
ved
>> state (e.g. statistics and other state) to be co-located under the same
>> structures.  The original discussions focused on applied configuration, =
but
>> when this was being discussed more recently the desire for a solution to
>> the co-located derived state was also discussed - which is why both
>> draft-schoenw-netmod-revised-datastores-01 and
>> draft-wilton-netmod-refined-datastores-01 propose solutions to this
>> problem.
>>
>
>
>> There are also benefits to merging this data:
>>
>> 1) Having co-located config and state data means that clients can easily
>> request config and state for a related object in a single request
>> 1b) Having co-located config and state makes it easier for clients to co=
de
>> - they don't need to unify data across two (potentially different
>> structures/indexes).
>> 1c) Having a single structure, means less copying of the same organizati=
on
>> structure into both config and state sub trees (which could be a source =
of
>> bugs)
>>
>> 2) Having a single root makes schema mount work more nicely, it avoids a
>> duplicate hierarchy.
>>
>> 3) Finally, I also agree with Kent, in that merging these makes the mode=
ls
>> easier to read and removes a historical wart.
>>
>>
>
> I don't agree with any of these "benefits".
> The protocol can be made to solve these problems. (1) is already solved.
> (1b) is pure speculation about implementation cost.
> (1c) also makes subjective implementation assumptions
> The new problems that are raised just make YANG worse and full of CLRs
> that confuse people trying to learn YANG.
>
>
>
>
>> Thanks,
>> Rob
>>
>>
>>
> Andy
>
>
>>
>>
>>
>> Andy
>>
>>
>> Hint: the first few edits are just nits...skip over the first few
>>> paragraphs until you start seeing large blocks of changed lines...
>>>
>>> Kent // as a contributor
>>>
>>>
>>>
>>> _______________________________________________
>>> 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 Aug 10 14:55: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 9F92612D151 for ; Wed, 10 Aug 2016 14:55:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-1.247, 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 qO1sM5Lxwgm3 for ; Wed, 10 Aug 2016 14:54:58 -0700 (PDT)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E32D912D145 for ; Wed, 10 Aug 2016 14:54:58 -0700 (PDT)
From: Alex Campbell 
To: Ladislav Lhotka 
Thread-Topic: [netmod] OpsState and Schema-Mount
Thread-Index: AQHR7NwrJNTrNdJHxEW1BGojdKmDiaA3Qd0AgAAlNwCAAKDWgIABEGmAgAAzOACABrN/AIAAGp2AgADz3wCAACFNgIABZIWAgAA2RxM=
Date: Wed, 10 Aug 2016 21:54:57 +0000
Message-ID: <1470866097387.66518@Aviatnet.com>
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <2e78a895-84d3-6381-ca34-f49a830f3bb0@cisco.com> ,
In-Reply-To: 
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] OpsState and 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, 10 Aug 2016 21:55:00 -0000

I think in this case it would make sense to implement both the hypothetical=
 standard module's state data (which would be device-agnostic, such as a bo=
olean value indicating whether each configured rule is active) and also a d=
evice-specific module providing access to the more detailed internal state.=
=0A=
=0A=
________________________________________=0A=
From: netmod  on behalf of Ladislav Lhotka =0A=
Sent: Wednesday, 10 August 2016 11:39 p.m.=0A=
To: Andy Bierman; Robert Wilton=0A=
Cc: netmod WG=0A=
Subject: Re: [netmod] OpsState and Schema-Mount=0A=
=0A=
Andy Bierman  writes:=0A=
=0A=
> On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton  wrote:=
=0A=
>=0A=
>> Hi Andy,=0A=
>> I don't properly understand the points that you are making, please see=
=0A=
>> clarifying comments/questions inline ...=0A=
>>=0A=
>> On 08/08/2016 22:51, Andy Bierman wrote:=0A=
>>=0A=
>>=0A=
>>=0A=
>> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  wrote:=
=0A=
>>=0A=
>>> Acee writes:=0A=
>>> >    Then I see no YANG language barriers in collapsing config and stat=
e=0A=
>>> trees=0A=
>>> >    - the model root just needs to be =93config true=94.=0A=
>>>=0A=
>>> Great, I think we=92re all agreed.  Can we now discuss the text I propo=
sed=0A=
>>> for 6087bis?  - here=92s the link to my proposal:=0A=
>>> https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0=
s.=0A=
>>>=0A=
>>>=0A=
>> IMO this effort to avoid 2 containers is not well thought out.=0A=
>> Some concerns:=0A=
>>=0A=
>> 1) modularity=0A=
>>     placing the monitoring objects within the configuration means the=0A=
>> monitoring=0A=
>>     cannot be used on its own=0A=
>>=0A=
>> If it is one module with two top level augments (foo and foo-state) then=
=0A=
>> this problem still exists.  Hence, please can you clarify why converging=
=0A=
>> them on a single root node means that monitoring cannot be used on it ow=
n?=0A=
>> Wouldn't a device need to use deviations in both cases to strip out the=
=0A=
>> config nodes that they are not supporting?=0A=
>>=0A=
>>=0A=
> Before the "rule" I can choose to place monitoring in its own module=0A=
> without any reliance on other modules.  If the monitoring does not=0A=
> share indexing, what value is there in putting it in the config tree?=0A=
> I see none except a poor attempt at model classification.=0A=
=0A=
Sometimes it may indeed make sense to keep configuration and state data=0A=
schemas in different modules. For instance, it may be useful (or even=0A=
necessary) to have common configuration but different state data for=0A=
different implementations, e.g. when devices use vastly different=0A=
internal architectures.=0A=
=0A=
One example are packet filters: while it may be possible to have a=0A=
common configuration for Linux nftables and Cisco ACLs, monitoring or=0A=
debugging either implementation requires access to what the system is=0A=
doing under the hood, i.e. system-specific state data and counters.=0A=
=0A=
Lada=0A=
=0A=
>=0A=
>=0A=
>=0A=
>>=0A=
>>=0A=
>> 2) access control=0A=
>>     placing the monitoring data within configuration means the=0A=
>> monitoring-only clients=0A=
>>     need write permission turned on for the nodes they can access for=0A=
>> read-only=0A=
>>     This relies on granular and complex NACM rules which require regular=
=0A=
>> maintenance.=0A=
>>=0A=
>> Again, I don't quite follow this, in the specific example that I have=0A=
>> regarding putting a RIB under a config true NP container, I would have=
=0A=
>> thought that NACM read access would have been sufficient for a=0A=
>> monitoring-only client.  Is that not the case?=0A=
>>=0A=
>=0A=
>=0A=
> If the monitoring is rooting under config=3Dtrue nodes, then those config=
=3Dtrue=0A=
> nodes need to be created somehow.  A client with write access is probably=
=0A=
> required.=0A=
>=0A=
>=0A=
>=0A=
>>=0A=
>>=0A=
>> 3) YANG conformance=0A=
>>     placing the monitoring data inside the configuration means the=0A=
>> configuration=0A=
>>     will be required for conformance; it is not likely to be just 1 NP=
=0A=
>> container.=0A=
>>=0A=
>> Similar to my response to the first question, I thought that conformance=
=0A=
>> was done on a per module base, not a per sub-tree basis.  So even if you=
=0A=
>> have top level 'foo' and 'foo-state' as part of the same module don't yo=
u=0A=
>> run into the same conformance problem?=0A=
>>=0A=
>>=0A=
>>=0A=
> Much easier to solve the conformance since /foo-state does not need any=
=0A=
> objects from /foo=0A=
> to exist first.  Creating the /foo container means that all config=3Dtrue=
=0A=
> requirements for=0A=
> that container must be implemented (or complex deviations used)=0A=
>=0A=
>=0A=
>>=0A=
>> 4) pointless;=0A=
>>    given that new RPC operations are needed to access applied config, th=
e=0A=
>> only data not=0A=
>>    affected (and moved under the config container anyway) is stuff that=
=0A=
>> does not share=0A=
>>    the same indexing, or counters which are not part of the opstate=0A=
>> problem.=0A=
>>=0A=
>> Sorry, I don't really follow this one.  The original opstate draft put=
=0A=
>> forward by OpenConfig was asking for both applied-configuration and deri=
ved=0A=
>> state (e.g. statistics and other state) to be co-located under the same=
=0A=
>> structures.  The original discussions focused on applied configuration, =
but=0A=
>> when this was being discussed more recently the desire for a solution to=
=0A=
>> the co-located derived state was also discussed - which is why both=0A=
>> draft-schoenw-netmod-revised-datastores-01 and=0A=
>> draft-wilton-netmod-refined-datastores-01 propose solutions to this=0A=
>> problem.=0A=
>>=0A=
>=0A=
>=0A=
>> There are also benefits to merging this data:=0A=
>>=0A=
>> 1) Having co-located config and state data means that clients can easily=
=0A=
>> request config and state for a related object in a single request=0A=
>> 1b) Having co-located config and state makes it easier for clients to co=
de=0A=
>> - they don't need to unify data across two (potentially different=0A=
>> structures/indexes).=0A=
>> 1c) Having a single structure, means less copying of the same organizati=
on=0A=
>> structure into both config and state sub trees (which could be a source =
of=0A=
>> bugs)=0A=
>>=0A=
>> 2) Having a single root makes schema mount work more nicely, it avoids a=
=0A=
>> duplicate hierarchy.=0A=
>>=0A=
>> 3) Finally, I also agree with Kent, in that merging these makes the mode=
ls=0A=
>> easier to read and removes a historical wart.=0A=
>>=0A=
>>=0A=
>=0A=
> I don't agree with any of these "benefits".=0A=
> The protocol can be made to solve these problems. (1) is already solved.=
=0A=
> (1b) is pure speculation about implementation cost.=0A=
> (1c) also makes subjective implementation assumptions=0A=
> The new problems that are raised just make YANG worse and full of CLRs=0A=
> that confuse people trying to learn YANG.=0A=
>=0A=
>=0A=
>=0A=
>=0A=
>> Thanks,=0A=
>> Rob=0A=
>>=0A=
>>=0A=
>>=0A=
> Andy=0A=
>=0A=
>=0A=
>>=0A=
>>=0A=
>>=0A=
>> Andy=0A=
>>=0A=
>>=0A=
>> Hint: the first few edits are just nits...skip over the first few=0A=
>>> paragraphs until you start seeing large blocks of changed lines...=0A=
>>>=0A=
>>> Kent // as a contributor=0A=
>>>=0A=
>>>=0A=
>>>=0A=
>>> _______________________________________________=0A=
>>> netmod mailing list=0A=
>>> netmod@ietf.org=0A=
>>> https://www.ietf.org/mailman/listinfo/netmod=0A=
>>>=0A=
>>=0A=
>>=0A=
>>=0A=
=0A=
--=0A=
Ladislav Lhotka, CZ.NIC Labs=0A=
PGP Key ID: E74E8C0C=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Thu Aug 11 00:02: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 C874F12D0C4 for ; Thu, 11 Aug 2016 00:02:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 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=-1.247] 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 hUyIY1VXfK_A for ; Thu, 11 Aug 2016 00:01:59 -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 0984C12B04F for ; Thu, 11 Aug 2016 00:01:59 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:a0b8:585b:a5a9:4ab8] (unknown [IPv6:2001:718:1a02:1:a0b8:585b:a5a9:4ab8]) by mail.nic.cz (Postfix) with ESMTPSA id 1DC2161385; Thu, 11 Aug 2016 09:01:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1470898917; bh=xLng3I65JeYzvB0LXkzSe67FD78eWZqEH4/r38cxsOc=; h=From:Date:To; b=d8jlYMD8/jIfJLKRD++RP2F5tO2T9x8x1vreonsM3wceimLVZAN9K1sc561KpEo/D E3I1Sslx6/2b/8PX41SfrFbdEmOfLEm/039junONF1tqf/ZUj/bsBJkB+8a6lrfSvC vQdQK+WipdKetOO1Sl6y8UvL4jdpDLIsrbsdCcbU=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <1470866097387.66518@Aviatnet.com>
Date: Thu, 11 Aug 2016 09:01:57 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <25CF405C-AE56-490F-84D6-BDDE076CBE7B@nic.cz>
References:  <5296754B-8178-4B1B-B4A6-FE228ABB8E7F@juniper.net> <9367f4b1-7814-e175-32e8-d518438b841d@cisco.com>   <552008CB-F216-4578-A709-AE0613C2EFB9@nic.cz> <12ed1a4d-44c5-9a51-b6d4-95e1620a24ee@cisco.com>    <20160729163220.GA3579@elstar.local> <68421198-703c-bb26-0fcc-f560e6fe108d@ericsson.com> <100B5D71-C23E-4C72-9EA2-2DB6574DEB87@nic.cz> <5153eab1-8d87-6e3c-3b54-441f683695e4@cisco.com>  <18066971-3353-b13f-04fa-e214a47ab9a7@cisco.com>  <3175490B-E8DA-4819-B294-C64D1A7D8A40@juniper.net>  <2e78a895-84d3-6381-ca34-f49a830f3bb0@cisco.com>   <1470866097387.66518@Aviatnet.com>
To: Alex Campbell 
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] OpsState and 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: Thu, 11 Aug 2016 07:02:02 -0000

> On 10 Aug 2016, at 23:54, Alex Campbell  =
wrote:
>=20
> I think in this case it would make sense to implement both the =
hypothetical standard module's state data (which would be =
device-agnostic, such as a boolean value indicating whether each =
configured rule is active) and also a device-specific module providing =
access to the more detailed internal state.

Right, that's one option, but for smaller devices (which could be, e.g., =
OpenWRT routers) it may be an overkill.

If standard state data are in a separate module, an implementor can =
choose to implement them or not.

Lada

>=20
> ________________________________________
> From: netmod  on behalf of Ladislav Lhotka =

> Sent: Wednesday, 10 August 2016 11:39 p.m.
> To: Andy Bierman; Robert Wilton
> Cc: netmod WG
> Subject: Re: [netmod] OpsState and Schema-Mount
>=20
> Andy Bierman  writes:
>=20
>> On Tue, Aug 9, 2016 at 5:24 AM, Robert Wilton  =
wrote:
>>=20
>>> Hi Andy,
>>> I don't properly understand the points that you are making, please =
see
>>> clarifying comments/questions inline ...
>>>=20
>>> On 08/08/2016 22:51, Andy Bierman wrote:
>>>=20
>>>=20
>>>=20
>>> On Mon, Aug 8, 2016 at 1:16 PM, Kent Watsen  =
wrote:
>>>=20
>>>> Acee writes:
>>>>>   Then I see no YANG language barriers in collapsing config and =
state
>>>> trees
>>>>>   - the model root just needs to be =93config true=94.
>>>>=20
>>>> Great, I think we=92re all agreed.  Can we now discuss the text I =
proposed
>>>> for 6087bis?  - here=92s the link to my proposal:
>>>> =
https://mailarchive.ietf.org/arch/msg/netmod/-zbXNhw2BJYMyrBT9nnCwoLAJ0s.
>>>>=20
>>>>=20
>>> IMO this effort to avoid 2 containers is not well thought out.
>>> Some concerns:
>>>=20
>>> 1) modularity
>>>    placing the monitoring objects within the configuration means the
>>> monitoring
>>>    cannot be used on its own
>>>=20
>>> If it is one module with two top level augments (foo and foo-state) =
then
>>> this problem still exists.  Hence, please can you clarify why =
converging
>>> them on a single root node means that monitoring cannot be used on =
it own?
>>> Wouldn't a device need to use deviations in both cases to strip out =
the
>>> config nodes that they are not supporting?
>>>=20
>>>=20
>> Before the "rule" I can choose to place monitoring in its own module
>> without any reliance on other modules.  If the monitoring does not
>> share indexing, what value is there in putting it in the config tree?
>> I see none except a poor attempt at model classification.
>=20
> Sometimes it may indeed make sense to keep configuration and state =
data
> schemas in different modules. For instance, it may be useful (or even
> necessary) to have common configuration but different state data for
> different implementations, e.g. when devices use vastly different
> internal architectures.
>=20
> One example are packet filters: while it may be possible to have a
> common configuration for Linux nftables and Cisco ACLs, monitoring or
> debugging either implementation requires access to what the system is
> doing under the hood, i.e. system-specific state data and counters.
>=20
> Lada
>=20
>>=20
>>=20
>>=20
>>>=20
>>>=20
>>> 2) access control
>>>    placing the monitoring data within configuration means the
>>> monitoring-only clients
>>>    need write permission turned on for the nodes they can access for
>>> read-only
>>>    This relies on granular and complex NACM rules which require =
regular
>>> maintenance.
>>>=20
>>> Again, I don't quite follow this, in the specific example that I =
have
>>> regarding putting a RIB under a config true NP container, I would =
have
>>> thought that NACM read access would have been sufficient for a
>>> monitoring-only client.  Is that not the case?
>>>=20
>>=20
>>=20
>> If the monitoring is rooting under config=3Dtrue nodes, then those =
config=3Dtrue
>> nodes need to be created somehow.  A client with write access is =
probably
>> required.
>>=20
>>=20
>>=20
>>>=20
>>>=20
>>> 3) YANG conformance
>>>    placing the monitoring data inside the configuration means the
>>> configuration
>>>    will be required for conformance; it is not likely to be just 1 =
NP
>>> container.
>>>=20
>>> Similar to my response to the first question, I thought that =
conformance
>>> was done on a per module base, not a per sub-tree basis.  So even if =
you
>>> have top level 'foo' and 'foo-state' as part of the same module =
don't you
>>> run into the same conformance problem?
>>>=20
>>>=20
>>>=20
>> Much easier to solve the conformance since /foo-state does not need =
any
>> objects from /foo
>> to exist first.  Creating the /foo container means that all =
config=3Dtrue
>> requirements for
>> that container must be implemented (or complex deviations used)
>>=20
>>=20
>>>=20
>>> 4) pointless;
>>>   given that new RPC operations are needed to access applied config, =
the
>>> only data not
>>>   affected (and moved under the config container anyway) is stuff =
that
>>> does not share
>>>   the same indexing, or counters which are not part of the opstate
>>> problem.
>>>=20
>>> Sorry, I don't really follow this one.  The original opstate draft =
put
>>> forward by OpenConfig was asking for both applied-configuration and =
derived
>>> state (e.g. statistics and other state) to be co-located under the =
same
>>> structures.  The original discussions focused on applied =
configuration, but
>>> when this was being discussed more recently the desire for a =
solution to
>>> the co-located derived state was also discussed - which is why both
>>> draft-schoenw-netmod-revised-datastores-01 and
>>> draft-wilton-netmod-refined-datastores-01 propose solutions to this
>>> problem.
>>>=20
>>=20
>>=20
>>> There are also benefits to merging this data:
>>>=20
>>> 1) Having co-located config and state data means that clients can =
easily
>>> request config and state for a related object in a single request
>>> 1b) Having co-located config and state makes it easier for clients =
to code
>>> - they don't need to unify data across two (potentially different
>>> structures/indexes).
>>> 1c) Having a single structure, means less copying of the same =
organization
>>> structure into both config and state sub trees (which could be a =
source of
>>> bugs)
>>>=20
>>> 2) Having a single root makes schema mount work more nicely, it =
avoids a
>>> duplicate hierarchy.
>>>=20
>>> 3) Finally, I also agree with Kent, in that merging these makes the =
models
>>> easier to read and removes a historical wart.
>>>=20
>>>=20
>>=20
>> I don't agree with any of these "benefits".
>> The protocol can be made to solve these problems. (1) is already =
solved.
>> (1b) is pure speculation about implementation cost.
>> (1c) also makes subjective implementation assumptions
>> The new problems that are raised just make YANG worse and full of =
CLRs
>> that confuse people trying to learn YANG.
>>=20
>>=20
>>=20
>>=20
>>> Thanks,
>>> Rob
>>>=20
>>>=20
>>>=20
>> Andy
>>=20
>>=20
>>>=20
>>>=20
>>>=20
>>> Andy
>>>=20
>>>=20
>>> Hint: the first few edits are just nits...skip over the first few
>>>> paragraphs until you start seeing large blocks of changed lines...
>>>>=20
>>>> Kent // as a contributor
>>>>=20
>>>>=20
>>>>=20
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>=20
>>>=20
>>>=20
>>>=20
>=20
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=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 Aug 11 02:06: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 B899E12D751 for ; Thu, 11 Aug 2016 02:06:44 -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 Gu9V8Wr25rTr for ; Thu, 11 Aug 2016 02:06:43 -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 E14BB12D6AF for ; Thu, 11 Aug 2016 02:06:43 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id CA4EA1E5A36; Thu, 11 Aug 2016 02:03:15 -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 5lA3Q3bR_ucx; Thu, 11 Aug 2016 02:03:15 -0700 (PDT)
Received: from [192.168.1.129] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id 44CDA1E5A34; Thu, 11 Aug 2016 02:03:15 -0700 (PDT)
From: William Lupton 
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Date: Thu, 11 Aug 2016 10:06:41 +0100
To: netmod@ietf.org
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Aug 2016 09:06:45 -0000

All,

The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems =
unclear:

"It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is =
re-posted=E2=80=9D

Assuming that the intent is that the revision statements in YANG models =
contained within IDs must be updated whenever the models are updated,  =
wouldn=E2=80=99t it be clearer if the parenthesised text "(i.e., =
Internet-Drafts)=E2=80=9D was deleted?

Thanks,
William=


From nobody Thu Aug 11 09:07: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 C4F1B12D7E6 for ; Thu, 11 Aug 2016 09:07:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 pIbCZ8SH5qJC for ; Thu, 11 Aug 2016 09:07:13 -0700 (PDT)
Received: from mail-pf0-f179.google.com (mail-pf0-f179.google.com [209.85.192.179]) (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 69AD812D7D9 for ; Thu, 11 Aug 2016 09:07:13 -0700 (PDT)
Received: by mail-pf0-f179.google.com with SMTP id x72so20174pfd.2 for ; Thu, 11 Aug 2016 09:07:13 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=rNH4YGMRmAH7yVL+KcZkARqxQa+dWdP3vQLNgpDq15E=; b=Ob+CoMZhNXqWXbIqsuum4Tv0ftrBsulDciBV4144SZ59/4DSozbwJhpTX/tkJQd0bM j9bcv1HQDHzGw0e8sMCfE6kcwoaBIZiR3nNzUrKXGIsqzhoATrQnMG5OhVdJGEIKEn9a SfaaBfZUju7T/dhsnmypgHqhby0dLs8y+uhNMj5V18JU+e8sqWNTIl4W2BE/aNkTLpzL pNvQAGHRliSELoe7rneZfEeVvh6bm47MNwv48UVUu1XQxOf0niRCQgFg6kUmm+y93awN SHDEKS+HADH8flT09EQyK2RcnHcxpcGZZVIJ5abnij8gVFjEdNyA/NTVKllmcfI1RRxO IG8g==
X-Gm-Message-State: AEkoousn8q2VMG/SvCdPNqkI9+v9BvSKy9qphiEassR6X0YJ2IMCnpNRHXisjsv6I0g9CZ1y
X-Received: by 10.98.94.6 with SMTP id s6mr18559420pfb.31.1470931632300; Thu, 11 Aug 2016 09:07:12 -0700 (PDT)
Received: from [127.0.0.1] (c-67-164-110-148.hsd1.ca.comcast.net. [67.164.110.148]) by smtp.gmail.com with ESMTPSA id l191sm6395726pfc.91.2016.08.11.09.07.10 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Aug 2016 09:07:11 -0700 (PDT)
To: netmod@ietf.org
References: 
From: Randy Presuhn 
Message-ID: <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu>
Date: Thu, 11 Aug 2016 09:07:09 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 160811-0, 08/10/2016), Outbound message
X-Antivirus-Status: Clean
Archived-At: 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Aug 2016 16:07:15 -0000

Hi -

The situation with Internet-Drafts is what motivated this text in the 
first place, so
I think it is important to retain that information.  However, it seems 
to me that
the "i.e." is too limiting, and should be replaced with an "e.g.".

Randy

On 8/11/2016 2:06 AM, William Lupton wrote:
> All,
>
> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems unclear:
>
> "It is acceptable to reuse the same revision statement within unpublished versions (i.e., Internet-Drafts), but the revision date MUST be updated to a higher value each time the Internet-Draft is re-posted”
>
> Assuming that the intent is that the revision statements in YANG models contained within IDs must be updated whenever the models are updated,  wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” was deleted?
>
> Thanks,
> William
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From nobody Thu Aug 11 09:17:37 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 5B08112D7FD for ; Thu, 11 Aug 2016 09:17:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 KMxcPNL8RDzO for ; Thu, 11 Aug 2016 09:17:34 -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 D2F0D12D7F6 for ; Thu, 11 Aug 2016 09:17:34 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 99F181E5D60; Thu, 11 Aug 2016 09:14:05 -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 Wn-6xmE1meGW; Thu, 11 Aug 2016 09:14:05 -0700 (PDT)
Received: from [192.168.1.127] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id B4FEE1E5A0C; Thu, 11 Aug 2016 09:14:04 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_D2A6FD9E-9BFE-4A35-B1FE-B06BC0FE67E5"
From: William Lupton 
In-Reply-To: <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu>
Date: Thu, 11 Aug 2016 17:17:31 +0100
Message-Id: <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org>
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu>
To: Randy Presuhn 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Aug 2016 16:17:36 -0000

--Apple-Mail=_D2A6FD9E-9BFE-4A35-B1FE-B06BC0FE67E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that =
wasn=E2=80=99t clear) is that this sentence seems to be contradictory. =
It says:
Unpublished versions, i.e IDs, can reuse revision statements.
IDs MUST update their revision dates each time they are re-posted.

My suggestion of removing the parenthesised text was to remove this =
contradiction. Right now I=E2=80=99m not clear that I can rely on =
revision dates in YANG modules contained within IDs.

William

PS, I think that the removal of this text removes the contradiction =
because in order to make sense of the sentence the reader will be forced =
to the conclusion that IDs are not regarded as being =E2=80=9Cunpublished=E2=
=80=9D.

> On 11 Aug 2016, at 17:07, Randy Presuhn =
 wrote:
>=20
> Hi -
>=20
> The situation with Internet-Drafts is what motivated this text in the =
first place, so
> I think it is important to retain that information.  However, it seems =
to me that
> the "i.e." is too limiting, and should be replaced with an "e.g.".
>=20
> Randy
>=20
> On 8/11/2016 2:06 AM, William Lupton wrote:
>> All,
>>=20
>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems =
unclear:
>>=20
>> "It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is =
re-posted=E2=80=9D
>>=20
>> Assuming that the intent is that the revision statements in YANG =
models contained within IDs must be updated whenever the models are =
updated,  wouldn=E2=80=99t it be clearer if the parenthesised text =
"(i.e., Internet-Drafts)=E2=80=9D was deleted?
>>=20
>> Thanks,
>> William
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
>=20
> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--Apple-Mail=_D2A6FD9E-9BFE-4A35-B1FE-B06BC0FE67E5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Thanks. e.g rather =
than i.e sounds good, BUT my point (sorry if that wasn=E2=80=99t clear) =
is that this sentence seems to be contradictory. It says:
  1. Unpublished =
versions, i.e IDs, can reuse revision statements.
  2. IDs =
MUST update their revision dates each time they are =
re-posted.

My suggestion of removing the parenthesised text was to =
remove this contradiction. Right now I=E2=80=99m not clear that I can =
rely on revision dates in YANG modules contained within IDs.

William

PS, I think that the =
removal of this text removes the contradiction because in order to make =
sense of the sentence the reader will be forced to the conclusion that =
IDs are not regarded as being =E2=80=9Cunpublished=E2=80=9D.

On 11 Aug =
2016, at 17:07, Randy Presuhn <randy_presuhn@alumni.stanford.edu> wrote:

Hi -

The =
situation with Internet-Drafts is what motivated this text in the first =
place, so
I think it is important to retain that =
information.  However, it seems to me that
the "i.e." =
is too limiting, and should be replaced with an "e.g.".

Randy

On 8/11/2016 2:06 AM, =
William Lupton wrote:
All,

The text at the bottom of =
RFC 6087bis (draft 07) Section 5.8 seems unclear:

"It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft =
is re-posted=E2=80=9D

Assuming that =
the intent is that the revision statements in YANG models contained =
within IDs must be updated whenever the models are updated, =
 wouldn=E2=80=99t it be clearer if the parenthesised =
text "(i.e., Internet-Drafts)=E2=80=9D was deleted?
Thanks,
William
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod


---
This email has been checked for viruses by Avast antivirus =
software.
https://www.avast.com/antivirus

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

=

--Apple-Mail=_D2A6FD9E-9BFE-4A35-B1FE-B06BC0FE67E5--


From nobody Thu Aug 11 09:18: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 E1E0212D7F5 for ; Thu, 11 Aug 2016 09:18:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4e3pY2ukrpb for ; Thu, 11 Aug 2016 09:18:49 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0134.outbound.protection.outlook.com [104.47.41.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C3ED312D7E6 for ; Thu, 11 Aug 2016 09:18:48 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KVEXRZZ3Z2qXv8aA2q3toiBDZYKoR4tvF/ZUu0EQoAg=; b=MEWek/pfSbQYpZFGlC/Pq+VwQ0CVrUmghnHIsNHHfy30TDlhR40aVjK3lxfcv6kbxOvo8Wkh7yLAGC2z8VXkVdYf3DxKPgZdaX0jLv5MHDVsqhXTfqWBb3chLMYU3KcAkc9QR9DBVQYHxx7kqvKvsVq9eSz62pX2v8WzjL11WxM=
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 (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Thu, 11 Aug 2016 16:18:46 +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.0557.009; Thu, 11 Aug 2016 16:18:46 +0000
From: Kent Watsen 
To: William Lupton , "netmod@ietf.org" 
Thread-Topic: [netmod] RFC 6087bis guidance re use of revision statements in drafts
Thread-Index: AQHR8+wIYRdZCgh14k6K57kYVT3EgA==
Date: Thu, 11 Aug 2016 16:18:45 +0000
Message-ID: <1FCABA4E-6BB0-4CCC-BA41-A1C2B56EA5FA@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/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-ms-office365-filtering-correlation-id: 130cf9d2-838d-4fc3-a96a-08d3c2032b8d
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1452; 6:06Xp1dqBqVcJ2gx1R79n5j2gOH/nHkAn+6ykHb3VzCXjpcIBS0sIURo1oim70HAZlHFojOXPRSDgy5EXYKgypytbGSeMY0PwNy9G+zzcKJ/xSr+m+BENIj5aHxPlH6BMIVtS9q2O0HGCgC0aOf46scIzHWHINbJpBBtStd1Ew09s3jXBoeKjjStCFi/V7Q00wVsjzslt7VCbsPaKwQwtC1NH84XHOJM7HIad911y/2DbstoLR6f0FdtxSNmor5o3G9tnLkxJv17HxLkhvoIZVAsyBJespL+w448Bf6blmTT+9ZxQI4cdVanAySqqGMBrXDaDatH3IIpPCszAbeEB0w==; 5:S9HnVci6Yc+leoqem3b6Kpkcuvnamz3LJpS4s7/twFzvzB9k1QQkl8QaaUuMR1zXmOofNP0WDR+HZ2ZywRqGVH5aMnIApy8Tu0ZwFHoQuGGjliDYmgOgPaNwcWJbHfytzzRArNaxO509A7BZDAch/w==; 24:v+PqWokCY5g4e2YYWjBmm/QkP891cBTEW1h4uwmOBpLxp5uWyFKMsfGxED5G4FOdkPVz+D5+9BMsF7Qf51sRIHrJlPg5/EnyDRt8pX3gvq4=; 7:U6i66ok3a0343lmUHl6fzh+AEquHRS9PgQocXSH5CXQFTuZiwVEZNUnORUWKxyx+/GBFHjlcPOyFxnDqJkgAtG0bPBt6AhemDOH8GaWzPqQcqJx6MAdAobl62Ed6l5SnAa2YbnC7L2cU9dS0Jt6Lo64DWUSEXZ+pI7vg09XMXtf1XwyHHAO+yJzYTxMpsnnZlGPQNic/BHDPCRC1mhHLs7UxqbSr/Imb9fMIsv0SWgMPt+ecRCyl7jZFOlU9iqZX
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:(6040171)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1452; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1452; 
x-forefront-prvs: 0031A0FFAF
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(377454003)(199003)(24454002)(105586002)(189998001)(50986999)(87936001)(36756003)(101416001)(2906002)(2501003)(54356999)(76176999)(7736002)(5001770100001)(4001350100001)(7846002)(97736004)(68736007)(10400500002)(5002640100001)(107886002)(11100500001)(2900100001)(305945005)(15975445007)(2950100001)(92566002)(99286002)(106356001)(83716003)(3660700001)(3280700002)(106116001)(66066001)(561944003)(122556002)(19580405001)(19580395003)(6116002)(3846002)(586003)(33656002)(86362001)(8676002)(77096005)(8936002)(82746002)(83506001)(81156014)(81166006)(102836003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1452; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Aug 2016 16:18:45.9275 (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: 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Aug 2016 16:18:53 -0000

DQpJIHRoaW5rIHRoZSBpc3N1ZSBpcyBhdCB0aGUgZW5kIG9mIHRoZSBzZW50ZW5jZSwgbXkgcHJv
cG9zYWw6DQoNCiAgICAtIHRoZSBJbnRlcm5ldC1EcmFmdCBpcyByZS1wb3N0ZWQuDQogICAgKyB0
aGUgd29yayBpcyBwdWJsaXNoZWQgKGUuZy4sIGl0IGJlY29tZXMgYW4gUkZDKS4NCg0KVGhhdCBz
YWlkLCBmb3IgSUVURiBkcmFmdHMgKG5vdCBvdGhlciBTRE9zKSwgbXkgdW5kZXJzdGFuZGluZyBp
cyB0aGF0IHRoZSByZXZpc2lvbiBzdGF0ZW1lbnTigJlzIGRhdGUgdmFsdWUgU0hPVUxEIGJlIHRo
ZSBkYXRlIHRoYXQgdGhlIEktRCBpcyB1cGxvYWRlZCB0byBJRVRGIGRhdGF0cmFja2VyLiAgQWxs
IG15IGRyYWZ0cyBhcmUgYnVpbHQgdXNpbmcgYSBNYWtlZmlsZSB0aGF0IGluY2x1ZGVzIGBzZWRg
IHByb2Nlc3NpbmcgaW5zdHJ1Y3Rpb25zIHRvIHNldCB0aGUgWUFORyBtb2R1bGUgZGF0ZXMgdG8g
dGhlIGN1cnJlbnQgZGF0ZSAtIGFuZCB0aGV5IGluY2x1ZGUgUkZDLUVkaXRvciBpbnN0cnVjdGlv
bnMgdG8gcmVzZXQgdGhlIHZhbHVlIGFnYWluIHRvIHRoZSBkYXRlIHRoZSBSRkMgaXMgcHVibGlz
aGVkLg0KDQpLZW50ICAgLy8gYXMgYSBjb250cmlidXRvcg0KDQoNCk9uIDgvMTEvMTYsIDU6MDYg
QU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIFdpbGxpYW0gTHVwdG9uIiA8bmV0bW9kLWJvdW5jZXNA
aWV0Zi5vcmcgb24gYmVoYWxmIG9mIHdsdXB0b25AYnJvYWRiYW5kLWZvcnVtLm9yZz4gd3JvdGU6
DQoNCiAgICBBbGwsDQogICAgDQogICAgVGhlIHRleHQgYXQgdGhlIGJvdHRvbSBvZiBSRkMgNjA4
N2JpcyAoZHJhZnQgMDcpIFNlY3Rpb24gNS44IHNlZW1zIHVuY2xlYXI6DQogICAgDQogICAgIkl0
IGlzIGFjY2VwdGFibGUgdG8gcmV1c2UgdGhlIHNhbWUgcmV2aXNpb24gc3RhdGVtZW50IHdpdGhp
biB1bnB1Ymxpc2hlZCB2ZXJzaW9ucyAoaS5lLiwgSW50ZXJuZXQtRHJhZnRzKSwgYnV0IHRoZSBy
ZXZpc2lvbiBkYXRlIE1VU1QgYmUgdXBkYXRlZCB0byBhIGhpZ2hlciB2YWx1ZSBlYWNoIHRpbWUg
dGhlIEludGVybmV0LURyYWZ0IGlzIHJlLXBvc3RlZOKAnQ0KICAgIA0KICAgIEFzc3VtaW5nIHRo
YXQgdGhlIGludGVudCBpcyB0aGF0IHRoZSByZXZpc2lvbiBzdGF0ZW1lbnRzIGluIFlBTkcgbW9k
ZWxzIGNvbnRhaW5lZCB3aXRoaW4gSURzIG11c3QgYmUgdXBkYXRlZCB3aGVuZXZlciB0aGUgbW9k
ZWxzIGFyZSB1cGRhdGVkLCAgd291bGRu4oCZdCBpdCBiZSBjbGVhcmVyIGlmIHRoZSBwYXJlbnRo
ZXNpc2VkIHRleHQgIihpLmUuLCBJbnRlcm5ldC1EcmFmdHMp4oCdIHdhcyBkZWxldGVkPw0KICAg
IA0KICAgIFRoYW5rcywNCiAgICBXaWxsaWFtDQogICAgX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX18NCiAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgbmV0
bW9kQGlldGYub3JnDQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u
ZXRtb2QNCiAgICANCg0K


From nobody Thu Aug 11 09:26: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 4B02112D7C2 for ; Thu, 11 Aug 2016 09:26:28 -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 PoroR1PR556n for ; Thu, 11 Aug 2016 09:26:26 -0700 (PDT)
Received: from mail-pa0-f50.google.com (mail-pa0-f50.google.com [209.85.220.50]) (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 8E74B12D7D9 for ; Thu, 11 Aug 2016 09:26:26 -0700 (PDT)
Received: by mail-pa0-f50.google.com with SMTP id fi15so149056pac.1 for ; Thu, 11 Aug 2016 09:26:26 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=Uxuz9JT/KpWWV4We8cWQzFoM52sv9DURjl+abSl/7EQ=; b=LVt4kBsYDrt6Mj9krPBeXE1e/aOu42zv2ANBdCfDpQ7o6aVLHccHz1qFN6FCAbJqKy 0u6E8iiAziGNehG/vuvNCQLiCGDsB8uHmAX288LioWP2pQV6RXGl0D7nJSdZ7dGO1Um8 ANiFJDlMALhoVqn6bOyBq0XPxKaLW4Nh76PNoFEK3IIxxrfUYb7dcH7ZXZtXKk6/eX80 kttX3H3+GhnMmJbJ0drPJ+OrDJ1nrxkcBHQnvuV/G4WwhjbAzk7l67T71coUxKVW+ipH E+WETdLEBYRE0AH0vk7wRyg29dRpNAGvf3M/0zAVSTAR7yYW5Am398eFdrIkzXpMjq/v 5dew==
X-Gm-Message-State: AEkoousO8DSglbMI7JPN7vNzopnxxXNd4erAk97pseCro1zULhxg16kiMlhQ203w2ZLstIDG
X-Received: by 10.66.232.37 with SMTP id tl5mr18518982pac.13.1470932785621; Thu, 11 Aug 2016 09:26:25 -0700 (PDT)
Received: from [127.0.0.1] (c-67-164-110-148.hsd1.ca.comcast.net. [67.164.110.148]) by smtp.gmail.com with ESMTPSA id p75sm6494250pfa.71.2016.08.11.09.26.24 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 11 Aug 2016 09:26:25 -0700 (PDT)
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org>
To: netmod@ietf.org
From: Randy Presuhn 
Message-ID: <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu>
Date: Thu, 11 Aug 2016 09:26:23 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 160811-0, 08/10/2016), Outbound message
X-Antivirus-Status: Clean
Archived-At: 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Aug 2016 16:26:28 -0000

Hi -

I read the text as intended to make a distinction between the *date* 
portion and the rest

of the revision statement.  When a module is under development, 
retaining a history

of specific incremental changes isn't terribly helpful, but changing the 
date is essential

to helping tools decide among the versions floating around in the lab.


Randy (experimenting with mail readers, please forgive formatting anomalies)


On 8/11/2016 9:17 AM, William Lupton wrote:
> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that 
> wasn’t clear) is that this sentence seems to be contradictory. It says:
>
>  1. Unpublished versions, i.e IDs, can reuse revision statements.
>  2. IDs MUST update their revision dates each time they are re-posted.
>
>
> My suggestion of removing the parenthesised text was to remove this 
> contradiction. Right now I’m not clear that I can rely on revision 
> dates in YANG modules contained within IDs.
>
> William
>
> PS, I think that the removal of this text removes the contradiction 
> because in order to make sense of the sentence the reader will be 
> forced to the conclusion that IDs are not regarded as being “unpublished”.
>
>> On 11 Aug 2016, at 17:07, Randy Presuhn 
>> > > wrote:
>>
>> Hi -
>>
>> The situation with Internet-Drafts is what motivated this text in the 
>> first place, so
>> I think it is important to retain that information.  However, it 
>> seems to me that
>> the "i.e." is too limiting, and should be replaced with an "e.g.".
>>
>> Randy
>>
>> On 8/11/2016 2:06 AM, William Lupton wrote:
>>> All,
>>>
>>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems 
>>> unclear:
>>>
>>> "It is acceptable to reuse the same revision statement within 
>>> unpublished versions (i.e., Internet-Drafts), but the revision date 
>>> MUST be updated to a higher value each time the Internet-Draft 
>>> is re-posted”
>>>
>>> Assuming that the intent is that the revision statements in YANG 
>>> models contained within IDs must be updated whenever the models are 
>>> updated,  wouldn’t it be clearer if the parenthesised text "(i.e., 
>>> Internet-Drafts)” was deleted?
>>>
>>> Thanks,
>>> William
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>> ---
>> This email has been checked for viruses by Avast antivirus software.
>> https://www.avast.com/antivirus
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From nobody Thu Aug 11 10:15: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 8626512D615 for ; Thu, 11 Aug 2016 10:15:03 -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 hGvYzvLM26VM for ; Thu, 11 Aug 2016 10:15:02 -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 4D18912D08F for ; Thu, 11 Aug 2016 10:15:02 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id E672A1E5D71; Thu, 11 Aug 2016 10:11:32 -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 bw0bfqSwaaVH; Thu, 11 Aug 2016 10:11:32 -0700 (PDT)
Received: from [192.168.1.129] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id 38CA21E5A45; Thu, 11 Aug 2016 10:11:32 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: William Lupton 
In-Reply-To: <1FCABA4E-6BB0-4CCC-BA41-A1C2B56EA5FA@juniper.net>
Date: Thu, 11 Aug 2016 18:14:59 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <605F1AAC-DB2B-4404-9C61-E41E592A9001@broadband-forum.org>
References:  <1FCABA4E-6BB0-4CCC-BA41-A1C2B56EA5FA@juniper.net>
To: Kent Watsen 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 11 Aug 2016 17:15:03 -0000

Ideally I=E2=80=99d like a stronger guarantee than that, e.g that all =
YANG modules in WG-adopted IDs MUST have revision dates that reflect the =
most recent change to that YANG (*). The key point is that other SDOs =
(such as BBF!) will often develop YANG modules that (during the =
development phase) depend on YANG modules from IDs, so it=E2=80=99s =
important to be able to rely on their revision dates.

(*) Or the ID publication date if you prefer, but 6087bis already says =
=E2=80=9CThe revision date does not need to be updated if the module =
contents do not change in the new document revision=E2=80=9D. Is this =
intended to apply to IDs?

> On 11 Aug 2016, at 17:18, Kent Watsen  wrote:
>=20
> I think the issue is at the end of the sentence, my proposal:
>=20
>    - the Internet-Draft is re-posted.
>    + the work is published (e.g., it becomes an RFC).
>=20
> That said, for IETF drafts (not other SDOs), my understanding is that =
the revision statement=E2=80=99s date value SHOULD be the date that the =
I-D is uploaded to IETF datatracker.  All my drafts are built using a =
Makefile that includes `sed` processing instructions to set the YANG =
module dates to the current date - and they include RFC-Editor =
instructions to reset the value again to the date the RFC is published.
>=20
> Kent   // as a contributor
>=20
>=20
> On 8/11/16, 5:06 AM, "netmod on behalf of William Lupton" =
 =
wrote:
>=20
>    All,
>=20
>    The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems =
unclear:
>=20
>    "It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is =
re-posted=E2=80=9D
>=20
>    Assuming that the intent is that the revision statements in YANG =
models contained within IDs must be updated whenever the models are =
updated,  wouldn=E2=80=99t it be clearer if the parenthesised text =
"(i.e., Internet-Drafts)=E2=80=9D was deleted?
>=20
>    Thanks,
>    William
>    _______________________________________________
>    netmod mailing list
>    netmod@ietf.org
>    https://www.ietf.org/mailman/listinfo/netmod
>=20
>=20


From nobody Mon Aug 15 04:31: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 19A5112DBAA for ; Mon, 15 Aug 2016 04:31:28 -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 NYDlt4fi1a8K for ; Mon, 15 Aug 2016 04:31:26 -0700 (PDT)
Received: from mail.amsl.com (c8a.amsl.com [4.31.198.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACDC112DBA9 for ; Mon, 15 Aug 2016 04:31:26 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 1E9D21E5A0B; Mon, 15 Aug 2016 04:27:43 -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 C9cqkUMvReqs; Mon, 15 Aug 2016 04:27:43 -0700 (PDT)
Received: from [192.168.1.127] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id 664101E5A0A; Mon, 15 Aug 2016 04:27:42 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: William Lupton 
In-Reply-To: <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu>
Date: Mon, 15 Aug 2016 12:31:23 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org>
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu>
To: Randy Presuhn 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Aug 2016 11:31:28 -0000

Ah! Re-reading it I think that you are correct. In this spirit I propose =
the change shown below. I believe that all this does is (a) generalise, =
and (b) clarify. I don=E2=80=99t believe that it changes the intended =
meaning.

OLD:

It is acceptable to reuse the same revision statement within unpublished =
versions (i.e., Internet-Drafts), but the revision date MUST be updated =
to a higher value each time the Internet-Draft is re-posted.

NEW:

It is acceptable to reuse the same revision statement within unpublished =
versions (e.g., Internet-Drafts), but the revision date (i.e., the =
revision statement=E2=80=99s argument) MUST be updated to a higher value =
each time a new version (e.g., of the Internet-Draft) is posted.

=E2=80=94=E2=80=94

Comments?

> On 11 Aug 2016, at 17:26, Randy Presuhn =
 wrote:
>=20
> Hi -
>=20
> I read the text as intended to make a distinction between the *date* =
portion and the rest
>=20
> of the revision statement.  When a module is under development, =
retaining a history
>=20
> of specific incremental changes isn't terribly helpful, but changing =
the date is essential
>=20
> to helping tools decide among the versions floating around in the lab.
>=20
>=20
> Randy (experimenting with mail readers, please forgive formatting =
anomalies)
>=20
>=20
> On 8/11/2016 9:17 AM, William Lupton wrote:
>> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that =
wasn=E2=80=99t clear) is that this sentence seems to be contradictory. =
It says:
>>=20
>> 1. Unpublished versions, i.e IDs, can reuse revision statements.
>> 2. IDs MUST update their revision dates each time they are re-posted.
>>=20
>> My suggestion of removing the parenthesised text was to remove this =
contradiction. Right now I=E2=80=99m not clear that I can rely on =
revision dates in YANG modules contained within IDs.
>>=20
>> William
>>=20
>> PS, I think that the removal of this text removes the contradiction =
because in order to make sense of the sentence the reader will be forced =
to the conclusion that IDs are not regarded as being =E2=80=9Cunpublished=E2=
=80=9D.
>>=20
>>> On 11 Aug 2016, at 17:07, Randy Presuhn =
> wrote:
>>>=20
>>> Hi -
>>>=20
>>> The situation with Internet-Drafts is what motivated this text in =
the first place, so
>>> I think it is important to retain that information.  However, it =
seems to me that
>>> the "i.e." is too limiting, and should be replaced with an "e.g.".
>>>=20
>>> Randy
>>>=20
>>> On 8/11/2016 2:06 AM, William Lupton wrote:
>>>> All,
>>>>=20
>>>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems =
unclear:
>>>>=20
>>>> "It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is =
re-posted=E2=80=9D
>>>>=20
>>>> Assuming that the intent is that the revision statements in YANG =
models contained within IDs must be updated whenever the models are =
updated,  wouldn=E2=80=99t it be clearer if the parenthesised text =
"(i.e., Internet-Drafts)=E2=80=9D was deleted?
>>>>=20
>>>> Thanks,
>>>> William


From nobody Mon Aug 15 04:44: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 A63F5128E18 for ; Mon, 15 Aug 2016 04:44:53 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 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=-1.247] 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 GkrGBc3kcH7g for ; Mon, 15 Aug 2016 04:44:51 -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 6BBEA12DBD6 for ; Mon, 15 Aug 2016 04:44:51 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:dda1:c3e1:a1bc:51cc] (unknown [IPv6:2001:718:1a02:1:dda1:c3e1:a1bc:51cc]) by mail.nic.cz (Postfix) with ESMTPSA id E0801612E5; Mon, 15 Aug 2016 13:44:49 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471261489; bh=KdERbG1tWGgexbgAemfS4X1VbleDS+z1wvVJ7u3gDmc=; h=From:Date:To; b=W7X/jBuUEThuCpwQqaLThFRA93hkqrJQi4T2Ruaz9ufTNrk2z7B+ztJYIf+g4RcPC O/pCRN/irVpL+qI/8269VeHDpNVxDRgVrZSogDEjsduQohBimQK7ooseonmBmYNgg9 4vza9uVyfXaJb1JsP658JsOZ2j8GnX7j84wvALPs=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org>
Date: Mon, 15 Aug 2016 13:44:54 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz>
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org>
To: William Lupton 
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] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Aug 2016 11:44:54 -0000

> On 15 Aug 2016, at 13:31, William Lupton  =
wrote:
>=20
> Ah! Re-reading it I think that you are correct. In this spirit I =
propose the change shown below. I believe that all this does is (a) =
generalise, and (b) clarify. I don=E2=80=99t believe that it changes the =
intended meaning.
>=20
> OLD:
>=20
> It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is re-posted.
>=20
> NEW:
>=20
> It is acceptable to reuse the same revision statement within =
unpublished versions (e.g., Internet-Drafts), but the revision date =
(i.e., the revision statement=E2=80=99s argument) MUST be updated to a =
higher value each time a new version (e.g., of the Internet-Draft) is =
posted.

It seems strange to talk about reusing the revision statement and, in =
the same sentence, require to change its argument. What about this:

NEW

It is not required to keep the revision history of unpublished versions =
(e.g., Internet-Drafts). That is, within a sequence of unpublished =
versions, only the most recent revision MAY be recorded in the module or =
submodule. However, the revision date of the most recent revision MUST =
be updated to a higher value each time a new version (e.g., of the =
Internet-Draft) is posted.

Lada

>=20
> =E2=80=94=E2=80=94
>=20
> Comments?
>=20
>> On 11 Aug 2016, at 17:26, Randy Presuhn =
 wrote:
>>=20
>> Hi -
>>=20
>> I read the text as intended to make a distinction between the *date* =
portion and the rest
>>=20
>> of the revision statement.  When a module is under development, =
retaining a history
>>=20
>> of specific incremental changes isn't terribly helpful, but changing =
the date is essential
>>=20
>> to helping tools decide among the versions floating around in the =
lab.
>>=20
>>=20
>> Randy (experimenting with mail readers, please forgive formatting =
anomalies)
>>=20
>>=20
>> On 8/11/2016 9:17 AM, William Lupton wrote:
>>> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that =
wasn=E2=80=99t clear) is that this sentence seems to be contradictory. =
It says:
>>>=20
>>> 1. Unpublished versions, i.e IDs, can reuse revision statements.
>>> 2. IDs MUST update their revision dates each time they are =
re-posted.
>>>=20
>>> My suggestion of removing the parenthesised text was to remove this =
contradiction. Right now I=E2=80=99m not clear that I can rely on =
revision dates in YANG modules contained within IDs.
>>>=20
>>> William
>>>=20
>>> PS, I think that the removal of this text removes the contradiction =
because in order to make sense of the sentence the reader will be forced =
to the conclusion that IDs are not regarded as being =E2=80=9Cunpublished=E2=
=80=9D.
>>>=20
>>>> On 11 Aug 2016, at 17:07, Randy Presuhn =
> wrote:
>>>>=20
>>>> Hi -
>>>>=20
>>>> The situation with Internet-Drafts is what motivated this text in =
the first place, so
>>>> I think it is important to retain that information.  However, it =
seems to me that
>>>> the "i.e." is too limiting, and should be replaced with an "e.g.".
>>>>=20
>>>> Randy
>>>>=20
>>>> On 8/11/2016 2:06 AM, William Lupton wrote:
>>>>> All,
>>>>>=20
>>>>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems =
unclear:
>>>>>=20
>>>>> "It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is =
re-posted=E2=80=9D
>>>>>=20
>>>>> Assuming that the intent is that the revision statements in YANG =
models contained within IDs must be updated whenever the models are =
updated,  wouldn=E2=80=99t it be clearer if the parenthesised text =
"(i.e., Internet-Drafts)=E2=80=9D was deleted?
>>>>>=20
>>>>> Thanks,
>>>>> William
>=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 Aug 15 05:23: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 7EA9412DCCF for ; Mon, 15 Aug 2016 05:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level: 
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=hansfords.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 XZOuGZnwiL3R for ; Mon, 15 Aug 2016 05:23:27 -0700 (PDT)
Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (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 1436112DCCE for ; Mon, 15 Aug 2016 05:23:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:References:In-Reply-To:Date: Subject:From:Cc:To:MIME-Version:Sender:Reply-To:Message-ID: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=A3mq/zNLd6T7cQsLE9o5shjEXpUNMdasOSnNDgHQVbo=; b=lowDoLU5oPYFmpc42fWlHUVL7 +qZmwpEta+0JQWMlgBk0UONIOiiNahqEF500UUyopq2g/qmm/ntHpsky+BkCjWrt5u+2P+YGvYA5v LNhMacGJNvilTGzBBzHP3ZcQDn+gjJr3fhPcLHaT9tnYGubhW+VofG7fkRWUY7ltDci1YWDhkwqKH ADk57pssyN68sPCM58dbBrKgUXitMZUV52J3ZVFG5SQQGDfFGysFqmNTtPD7CvpKhJjkC3Ovo9peT QJKeLZvevxIyfoL5Y2FahqdV+V4YThqachF7ZN4o/koL0DK5ef+9GIN/BD9eErKssN11IYEg0oWW6 /2OtemiFg==;
Received: from host-92-19-235-91.static.as13285.net ([92.19.235.91]:49774 helo=[IPv6:::ffff:192.168.1.137]) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bZGvK-000UAs-FO; Mon, 15 Aug 2016 13:23:24 +0100
MIME-Version: 1.0
To: Ladislav Lhotka ,  William Lupton 
From: Jonathan Hansford 
Date: Mon, 15 Aug 2016 13:23:52 +0100
Importance: normal
X-Priority: 3
In-Reply-To: <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz>
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz>
Content-Type: multipart/alternative; boundary="_175AF81F-942C-4161-A0A1-680ED030868B_"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net
Message-Id: <20160815122327.1436112DCCE@ietfa.amsl.com>
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements indrafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Aug 2016 12:23:29 -0000

--_175AF81F-942C-4161-A0A1-680ED030868B_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

Should it be a MAY or a MUST? And why is it =E2=80=9Ce.g. of the Internet-D=
raft=E2=80=9D? Isn=E2=80=99t it more =E2=80=9Ceach time a new version is po=
sted (e.g. in a new version of the Internet-Draft)=E2=80=9D? Shouldn=E2=80=
=99t the revision statement reflect changes to the module or submodule rath=
er than to the Internet-Draft in which they are published?

Jonathan

From: Ladislav Lhotka=

--_175AF81F-942C-4161-A0A1-680ED030868B_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"


Should it be a MAY or a MUST? And wh=
y is it =E2=80=9Ce.g. of the Internet-Draft=E2=80=9D? Isn=E2=80=99t it more=
 =E2=80=9Ceach time a new version is posted (e.g. in a new version of the I=
nternet-Draft)=E2=80=9D? Shouldn=E2=80=99t the revision statement reflect c=
hanges to the module or submodule rather than to the Internet-Draft in whic=
h they are published?

Jonathan
 
From: Ladislav Lhotka
Sent: 15 August =
2016 12:44
To: Wil=
liam Lupton
Cc: netmod@iet=
f.org
Subject: Re: [netmod] RFC 6087bis guidance re use of re=
vision statements indrafts
 =

 
> On =
15 Aug 2016, at 13:31, William Lupton <wlupton@broadband-forum.org> w=
rote:
> 
> Ah! Re-rea=
ding it I think that you are correct. In this spirit I propose the change s=
hown below. I believe that all this does is (a) generalise, and (b) clarify=
. I don=E2=80=99t believe that it changes the intended meaning.
> 
> OLD:
> 
> It is acceptable to reuse the same rev=
ision statement within unpublished versions (i.e., Internet-Drafts), but th=
e revision date MUST be updated to a higher value each time the Internet-Dr=
aft is re-posted.
> 
>=
; NEW:
> 
> It is acc=
eptable to reuse the same revision statement within unpublished versions (e=
.g., Internet-Drafts), but the revision date (i.e., the revision statement=
=E2=80=99s argument) MUST be updated to a higher value each time a new vers=
ion (e.g., of the Internet-Draft) is posted.
&=
nbsp;
It seems strange to talk about reusing =
the revision statement and, in the same sentence, require to change its arg=
ument. What about this:
 
NEW
 
It is not required to keep the revision history of unpublished ve=
rsions (e.g., Internet-Drafts). That is, within a sequence of unpublished v=
ersions, only the most recent revision MAY be recorded in the module or sub=
module. However, the revision date of the most recent revision MUST be upda=
ted to a higher value each time a new version (e.g., of the Internet-Draft)=
 is posted.
 
Lada
 
&=
gt; 
> =E2=80=94=E2=80=94
> 
> Comments?
>=
 
>> On 11 Aug 2016, at 17:26, Randy Presuhn =
<randy_presuhn@alumni.stanford.edu> wrote:
&g=
t;> 
>> Hi -
>&=
gt; 
>> I read the text as intended to make a=
 distinction between the *date* portion and the rest
>> 
>> of the revision statement.=C2=
=A0 When a module is under development, retaining a history
>> 
>> of specific incremental=
 changes isn't terribly helpful, but changing the date is essential
>> 
>> to helping tool=
s decide among the versions floating around in the lab.
>> 
>> 
&g=
t;> Randy (experimenting with mail readers, please forgive formatting an=
omalies)
>> 
>>=
 
>> On 8/11/2016 9:17 AM, William Lupton wro=
te:
>>> Thanks. e.g rather than i.e sounds=
 good, BUT my point (sorry if that wasn=E2=80=99t clear) is that this sente=
nce seems to be contradictory. It says:
>>>=
; 
>>> 1. Unpublished versions, i.e IDs, c=
an reuse revision statements.
>>> 2. IDs M=
UST update their revision dates each time they are re-posted.
>>> 
>>> My suggesti=
on of removing the parenthesised text was to remove this contradiction. Rig=
ht now I=E2=80=99m not clear that I can rely on revision dates in YANG modu=
les contained within IDs.
>>> 
>>> William
>>> 
=

>>> PS, I think that the removal of this text=
 removes the contradiction because in order to make sense of the sentence t=
he reader will be forced to the conclusion that IDs are not regarded as bei=
ng =E2=80=9Cunpublished=E2=80=9D.
>>> 
=

>>>> On 11 Aug 2016, at 17:07, Randy Presu=
hn <randy_presuhn@alumni.stanford.edu <mailto:randy_presuhn@alumni.st=
anford.edu>> wrote:
>>>> 
>>>> Hi -
>>>=
> 
>>>> The situation with Internet-=
Drafts is what motivated this text in the first place, so
>>>> I think it is important to retain that information.=
=C2=A0 However, it seems to me that
>>>>=
; the "i.e." is too limiting, and should be replaced with an &quo=
t;e.g.".
>>>> 
>>>> Randy
>>>> 
>>>> On 8/11/2016 2:06 AM, William Lupton wr=
ote:
>>>>> All,
>>>>> 
>>>>> The =
text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems unclear:
=

>>>>> 
>>=
>>> "It is acceptable to reuse the same revision statement wi=
thin unpublished versions (i.e., Internet-Drafts), but the revision date MU=
ST be updated to a higher value each time the Internet-Draft is re-posted=
=E2=80=9D
>>>>> 
>>>>> Assuming that the intent is that the revision sta=
tements in YANG models contained within IDs must be updated whenever the mo=
dels are updated,=C2=A0 wouldn=E2=80=99t it be clearer if the parenthesised=
 text "(i.e., Internet-Drafts)=E2=80=9D was deleted?
>>>>> 
>>>>> T=
hanks,
>>>>> William
> 
> _______________________________=
________________
> netmod mailing list
> netmod@ietf.org
> https://ww=
w.ietf.org/mailman/listinfo/netmod
 
--
Ladislav Lhotka, CZ.NI=
C Labs
PGP Key ID: E74E8C0C
 
 
 
 
_______________________________________________
netmod mailing list
netmod@ietf.org=

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

--_175AF81F-942C-4161-A0A1-680ED030868B_--


From nobody Mon Aug 15 05:35: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 16B8712DD02 for ; Mon, 15 Aug 2016 05:35:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 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=-1.247] 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 avmjeUayLf4m for ; Mon, 15 Aug 2016 05:35:53 -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 E37E012DCED for ; Mon, 15 Aug 2016 05:35:52 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:dda1:c3e1:a1bc:51cc] (unknown [IPv6:2001:718:1a02:1:dda1:c3e1:a1bc:51cc]) by mail.nic.cz (Postfix) with ESMTPSA id 39E706180E; Mon, 15 Aug 2016 14:35:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471264551; bh=zI0xqKeRzO/zAhkdVBZB4341P9wH5e58T7OW3xfsdzk=; h=From:Date:To; b=hNKfWCg1yIK9ZaH3dbKcs34q6CFu612vtNPt6+bGG8DJl6a4B8n6eTvsDpSNBHZCO eTuLjazrlw+sDG/b3KHlDjyTKnfYGGYj1hWIwiBPEr1I6MODvYXFzloYZfKijkpxlj +v6I1gINBWrUJzi4tw6MCF4WBTJYJ4Zi8D2pAP7s=
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: 
Date: Mon, 15 Aug 2016 14:35:56 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <881E397C-178F-4A05-9F57-CA334556D3DF@nic.cz>
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> 
To: Jonathan Hansford 
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] RFC 6087bis guidance re use of revision statements indrafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Aug 2016 12:35:55 -0000

> On 15 Aug 2016, at 14:23, Jonathan Hansford  =
wrote:
>=20
> Should it be a MAY or a MUST? And why is it =E2=80=9Ce.g. of the =
Internet-Draft=E2=80=9D? Isn=E2=80=99t it more =E2=80=9Ceach time a new =
version is posted (e.g. in a new version of the Internet-Draft)=E2=80=9D? =
Shouldn=E2=80=99t the revision statement reflect changes to the module =
or submodule rather than to the Internet-Draft in which they are =
published?

It would indeed be useful if the revision date is bumped only after the =
module itself has been changed - except when the module is published in =
an RFC.

Lada

>=20
> Jonathan
> =20
> From: Ladislav Lhotka
> Sent: 15 August 2016 12:44
> To: William Lupton
> Cc: netmod@ietf.org
> Subject: Re: [netmod] RFC 6087bis guidance re use of revision =
statements indrafts
> =20
> =20
> > On 15 Aug 2016, at 13:31, William Lupton =
 wrote:
> >=20
> > Ah! Re-reading it I think that you are correct. In this spirit I =
propose the change shown below. I believe that all this does is (a) =
generalise, and (b) clarify. I don=E2=80=99t believe that it changes the =
intended meaning.
> >=20
> > OLD:
> >=20
> > It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is re-posted.
> >=20
> > NEW:
> >=20
> > It is acceptable to reuse the same revision statement within =
unpublished versions (e.g., Internet-Drafts), but the revision date =
(i.e., the revision statement=E2=80=99s argument) MUST be updated to a =
higher value each time a new version (e.g., of the Internet-Draft) is =
posted.
> =20
> It seems strange to talk about reusing the revision statement and, in =
the same sentence, require to change its argument. What about this:
> =20
> NEW
> =20
> It is not required to keep the revision history of unpublished =
versions (e.g., Internet-Drafts). That is, within a sequence of =
unpublished versions, only the most recent revision MAY be recorded in =
the module or submodule. However, the revision date of the most recent =
revision MUST be updated to a higher value each time a new version =
(e.g., of the Internet-Draft) is posted.
> =20
> Lada
> =20
> >=20
> > =E2=80=94=E2=80=94
> >=20
> > Comments?
> >=20
> >> On 11 Aug 2016, at 17:26, Randy Presuhn =
 wrote:
> >>=20
> >> Hi -
> >>=20
> >> I read the text as intended to make a distinction between the =
*date* portion and the rest
> >>=20
> >> of the revision statement.  When a module is under development, =
retaining a history
> >>=20
> >> of specific incremental changes isn't terribly helpful, but =
changing the date is essential
> >>=20
> >> to helping tools decide among the versions floating around in the =
lab.
> >>=20
> >>=20
> >> Randy (experimenting with mail readers, please forgive formatting =
anomalies)
> >>=20
> >>=20
> >> On 8/11/2016 9:17 AM, William Lupton wrote:
> >>> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if =
that wasn=E2=80=99t clear) is that this sentence seems to be =
contradictory. It says:
> >>>=20
> >>> 1. Unpublished versions, i.e IDs, can reuse revision statements.
> >>> 2. IDs MUST update their revision dates each time they are =
re-posted.
> >>>=20
> >>> My suggestion of removing the parenthesised text was to remove =
this contradiction. Right now I=E2=80=99m not clear that I can rely on =
revision dates in YANG modules contained within IDs.
> >>>=20
> >>> William
> >>>=20
> >>> PS, I think that the removal of this text removes the =
contradiction because in order to make sense of the sentence the reader =
will be forced to the conclusion that IDs are not regarded as being =
=E2=80=9Cunpublished=E2=80=9D.
> >>>=20
> >>>> On 11 Aug 2016, at 17:07, Randy Presuhn =
> wrote:
> >>>>=20
> >>>> Hi -
> >>>>=20
> >>>> The situation with Internet-Drafts is what motivated this text in =
the first place, so
> >>>> I think it is important to retain that information.  However, it =
seems to me that
> >>>> the "i.e." is too limiting, and should be replaced with an =
"e.g.".
> >>>>=20
> >>>> Randy
> >>>>=20
> >>>> On 8/11/2016 2:06 AM, William Lupton wrote:
> >>>>> All,
> >>>>>=20
> >>>>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 =
seems unclear:
> >>>>>=20
> >>>>> "It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is =
re-posted=E2=80=9D
> >>>>>=20
> >>>>> Assuming that the intent is that the revision statements in YANG =
models contained within IDs must be updated whenever the models are =
updated,  wouldn=E2=80=99t it be clearer if the parenthesised text =
"(i.e., Internet-Drafts)=E2=80=9D was deleted?
> >>>>>=20
> >>>>> Thanks,
> >>>>> William
> >=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

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





From nobody Mon Aug 15 12:14: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 3043912D0F8 for ; Mon, 15 Aug 2016 12:14:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 DNrtzg05C_rM for ; Mon, 15 Aug 2016 12:14:21 -0700 (PDT)
Received: from mail-pf0-f177.google.com (mail-pf0-f177.google.com [209.85.192.177]) (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 AE84312B034 for ; Mon, 15 Aug 2016 12:14:21 -0700 (PDT)
Received: by mail-pf0-f177.google.com with SMTP id y134so19345336pfg.0 for ; Mon, 15 Aug 2016 12:14:21 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=HwszyGdfs9XG7u3wcVi/ACj6szkebGmjvZS0+1pIDWM=; b=e5PjzIofLeGXkvOJ6y8EJTO2jqDVTdjZEAYs6B8qhi38nx2gQQVxVTBS0j/sXFF5cW ZFFqrU5izgSnhLZ+6NhDQLNFth4fvHsKryZ47O29GNiENejXrKpJw1r7R8kIQUlwAmBV 5bB0JAGIZDt3C4g4IapyvWsDO2AE9V0CeQCy4xYh7C4vsVhRe2dFzpw5na40Q0cUJUv8 fPS8sqTHYWp7QXbk2AhYzjwDPFy9NKqijoH4VCnn0bum4TSOvXkA+49wDLpBI2/Ra3/5 hVZZNPDX+89VR9I17W9jbfdC41AN9ko47q0CB35zTZ5A+UrDEkyB/y+Iz2MD9A2r844I y+ag==
X-Gm-Message-State: AEkoousDGsimvtVqn/uiTc6rTqH1g8Qpa/pqu5cC5/HCNp33ZD6Ddh07hJTtiOAy68bukaUq
X-Received: by 10.98.60.217 with SMTP id b86mr4442915pfk.129.1471288460826; Mon, 15 Aug 2016 12:14:20 -0700 (PDT)
Received: from [127.0.0.1] (c-67-164-110-148.hsd1.ca.comcast.net. [67.164.110.148]) by smtp.gmail.com with ESMTPSA id y184sm33222699pfg.94.2016.08.15.12.14.19 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Aug 2016 12:14:20 -0700 (PDT)
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org>
To: netmod@ietf.org
From: Randy Presuhn 
Message-ID: <91146100-4933-5ec9-442d-3deeae81c30a@alumni.stanford.edu>
Date: Mon, 15 Aug 2016 12:14:18 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 160815-2, 08/15/2016), Outbound message
X-Antivirus-Status: Clean
Archived-At: 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Aug 2016 19:14:23 -0000

Hi -


The new text works for me.


Randy

On 8/15/2016 4:31 AM, William Lupton wrote:
> Ah! Re-reading it I think that you are correct. In this spirit I propose the change shown below. I believe that all this does is (a) generalise, and (b) clarify. I don’t believe that it changes the intended meaning.
>
> OLD:
>
> It is acceptable to reuse the same revision statement within unpublished versions (i.e., Internet-Drafts), but the revision date MUST be updated to a higher value each time the Internet-Draft is re-posted.
>
> NEW:
>
> It is acceptable to reuse the same revision statement within unpublished versions (e.g., Internet-Drafts), but the revision date (i.e., the revision statement’s argument) MUST be updated to a higher value each time a new version (e.g., of the Internet-Draft) is posted.
>
> ——
>
> Comments?
>
>> On 11 Aug 2016, at 17:26, Randy Presuhn  wrote:
>>
>> Hi -
>>
>> I read the text as intended to make a distinction between the *date* portion and the rest
>>
>> of the revision statement.  When a module is under development, retaining a history
>>
>> of specific incremental changes isn't terribly helpful, but changing the date is essential
>>
>> to helping tools decide among the versions floating around in the lab.
>>
>>
>> Randy (experimenting with mail readers, please forgive formatting anomalies)
>>
>>
>> On 8/11/2016 9:17 AM, William Lupton wrote:
>>> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that wasn’t clear) is that this sentence seems to be contradictory. It says:
>>>
>>> 1. Unpublished versions, i.e IDs, can reuse revision statements.
>>> 2. IDs MUST update their revision dates each time they are re-posted.
>>>
>>> My suggestion of removing the parenthesised text was to remove this contradiction. Right now I’m not clear that I can rely on revision dates in YANG modules contained within IDs.
>>>
>>> William
>>>
>>> PS, I think that the removal of this text removes the contradiction because in order to make sense of the sentence the reader will be forced to the conclusion that IDs are not regarded as being “unpublished”.
>>>
>>>> On 11 Aug 2016, at 17:07, Randy Presuhn > wrote:
>>>>
>>>> Hi -
>>>>
>>>> The situation with Internet-Drafts is what motivated this text in the first place, so
>>>> I think it is important to retain that information.  However, it seems to me that
>>>> the "i.e." is too limiting, and should be replaced with an "e.g.".
>>>>
>>>> Randy
>>>>
>>>> On 8/11/2016 2:06 AM, William Lupton wrote:
>>>>> All,
>>>>>
>>>>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems unclear:
>>>>>
>>>>> "It is acceptable to reuse the same revision statement within unpublished versions (i.e., Internet-Drafts), but the revision date MUST be updated to a higher value each time the Internet-Draft is re-posted”
>>>>>
>>>>> Assuming that the intent is that the revision statements in YANG models contained within IDs must be updated whenever the models are updated,  wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” was deleted?
>>>>>
>>>>> Thanks,
>>>>> William


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From nobody Mon Aug 15 12:17: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 B316212B034 for ; Mon, 15 Aug 2016 12:17:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level: 
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-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 ViKZbufNubPa for ; Mon, 15 Aug 2016 12:17:47 -0700 (PDT)
Received: from mail-pf0-f175.google.com (mail-pf0-f175.google.com [209.85.192.175]) (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 C419412B019 for ; Mon, 15 Aug 2016 12:17:47 -0700 (PDT)
Received: by mail-pf0-f175.google.com with SMTP id x72so19404105pfd.2 for ; Mon, 15 Aug 2016 12:17:47 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:subject:references:to:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=WAwtvAd7d5Hn91T/GBYU1CdUiWgziDg9J95yEBh2Xos=; b=b8mtqLjDXhnvO2knwSqhaaLiwhX7Rp27/vUh9TJcjhGF598f49gOqgX+LoyT0o7RS4 /1uyNHkPcp4nPJ/S+zwf0Bzpl+R3bzmYb9ZXqoKijkSr9k6DJCoAKmZ/pd/zJif9cTEu C/jTN+k82IFmZgWxrlAwQGPm5epcMaWWyP3+GarUag/KVEX5P70b+2M8lpMTqO85TOSL hm0Mwp9tEVlcU7ZYoq0BopaU9H/gMfbdljt3YUceY6uI5JUF34/r1UHowfu7hv6plXoI jjM/8i2zwD96rx07tDnVqFuwdbVDwK3AbAfrg2qixhH+pffnrQ5KOWYKqFgmJRjHyS8L sYXg==
X-Gm-Message-State: AEkoousq/k3w4mDmnBLnKPuPoKr3uMgUJ+8abJfPFKFwYQ64G6gwon7swy+GMnqYLWw16M8w
X-Received: by 10.98.213.130 with SMTP id d124mr2457325pfg.118.1471288666886;  Mon, 15 Aug 2016 12:17:46 -0700 (PDT)
Received: from [127.0.0.1] (c-67-164-110-148.hsd1.ca.comcast.net. [67.164.110.148]) by smtp.gmail.com with ESMTPSA id ad15sm33320176pac.33.2016.08.15.12.17.45 for  (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Aug 2016 12:17:46 -0700 (PDT)
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz>
To: netmod@ietf.org
From: Randy Presuhn 
Message-ID: <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu>
Date: Mon, 15 Aug 2016 12:17:44 -0700
User-Agent: Mozilla/5.0 (Windows NT 6.0; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Antivirus: avast! (VPS 160815-2, 08/15/2016), Outbound message
X-Antivirus-Status: Clean
Archived-At: 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Aug 2016 19:17:50 -0000

Hi -

This also works for me, but I'd replace the odd "MAY" with the word "need".

(The semantics of "only" and of "MAY" don't quite mesh.)

Randy

On 8/15/2016 4:44 AM, Ladislav Lhotka wrote:
>> On 15 Aug 2016, at 13:31, William Lupton  wrote:
>>
>> Ah! Re-reading it I think that you are correct. In this spirit I propose the change shown below. I believe that all this does is (a) generalise, and (b) clarify. I don’t believe that it changes the intended meaning.
>>
>> OLD:
>>
>> It is acceptable to reuse the same revision statement within unpublished versions (i.e., Internet-Drafts), but the revision date MUST be updated to a higher value each time the Internet-Draft is re-posted.
>>
>> NEW:
>>
>> It is acceptable to reuse the same revision statement within unpublished versions (e.g., Internet-Drafts), but the revision date (i.e., the revision statement’s argument) MUST be updated to a higher value each time a new version (e.g., of the Internet-Draft) is posted.
> It seems strange to talk about reusing the revision statement and, in the same sentence, require to change its argument. What about this:
>
> NEW
>
> It is not required to keep the revision history of unpublished versions (e.g., Internet-Drafts). That is, within a sequence of unpublished versions, only the most recent revision MAY be recorded in the module or submodule. However, the revision date of the most recent revision MUST be updated to a higher value each time a new version (e.g., of the Internet-Draft) is posted.
>
> Lada
>
>> ——
>>
>> Comments?
>>
>>> On 11 Aug 2016, at 17:26, Randy Presuhn  wrote:
>>>
>>> Hi -
>>>
>>> I read the text as intended to make a distinction between the *date* portion and the rest
>>>
>>> of the revision statement.  When a module is under development, retaining a history
>>>
>>> of specific incremental changes isn't terribly helpful, but changing the date is essential
>>>
>>> to helping tools decide among the versions floating around in the lab.
>>>
>>>
>>> Randy (experimenting with mail readers, please forgive formatting anomalies)
>>>
>>>
>>> On 8/11/2016 9:17 AM, William Lupton wrote:
>>>> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if that wasn’t clear) is that this sentence seems to be contradictory. It says:
>>>>
>>>> 1. Unpublished versions, i.e IDs, can reuse revision statements.
>>>> 2. IDs MUST update their revision dates each time they are re-posted.
>>>>
>>>> My suggestion of removing the parenthesised text was to remove this contradiction. Right now I’m not clear that I can rely on revision dates in YANG modules contained within IDs.
>>>>
>>>> William
>>>>
>>>> PS, I think that the removal of this text removes the contradiction because in order to make sense of the sentence the reader will be forced to the conclusion that IDs are not regarded as being “unpublished”.
>>>>
>>>>> On 11 Aug 2016, at 17:07, Randy Presuhn > wrote:
>>>>>
>>>>> Hi -
>>>>>
>>>>> The situation with Internet-Drafts is what motivated this text in the first place, so
>>>>> I think it is important to retain that information.  However, it seems to me that
>>>>> the "i.e." is too limiting, and should be replaced with an "e.g.".
>>>>>
>>>>> Randy
>>>>>
>>>>> On 8/11/2016 2:06 AM, William Lupton wrote:
>>>>>> All,
>>>>>>
>>>>>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 seems unclear:
>>>>>>
>>>>>> "It is acceptable to reuse the same revision statement within unpublished versions (i.e., Internet-Drafts), but the revision date MUST be updated to a higher value each time the Internet-Draft is re-posted”
>>>>>>
>>>>>> Assuming that the intent is that the revision statements in YANG models contained within IDs must be updated whenever the models are updated,  wouldn’t it be clearer if the parenthesised text "(i.e., Internet-Drafts)” was deleted?
>>>>>>
>>>>>> Thanks,
>>>>>> William
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>


---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus


From nobody Mon Aug 15 12:40: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 DBB6712D0FB for ; Mon, 15 Aug 2016 12:40:06 -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 Z-ZVvRKp120x for ; Mon, 15 Aug 2016 12:40:04 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0098.outbound.protection.outlook.com [104.47.40.98]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8B6312D0F8 for ; Mon, 15 Aug 2016 12:40:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=p7prbUeK3EYDY1WKb5ky6+Jj9YWz/7B+e8Pso7ZtBYM=; b=IcXll4dpVpBeqDnMZ5ELQnOOPMWYA0004tFijtUfreHhtWI2UNUexH6BANuBnNiRsVI8GE0+U8ncyLscKHy7yoCwaMqLnoRqMNhtHgVNbLJIzxSq/HbflKqNvlnjbYNY6k1/Yu2WU00ZqT5oDp2/GznsMZGYGinRke/z8WMC+uE=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Mon, 15 Aug 2016 19:40:02 +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.0557.009; Mon, 15 Aug 2016 19:40:02 +0000
From: Kent Watsen 
To: Randy Presuhn , "netmod@ietf.org" 
Thread-Topic: [netmod] RFC 6087bis guidance re use of revision statements in drafts
Thread-Index: AQHR8+pveoloFBy3lEe/DmhYdxEvH6BD7+OAgAACe4CABfbngIAAA8cAgAB+hQD//8MtAA==
Date: Mon, 15 Aug 2016 19:40:02 +0000
Message-ID: <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu>
In-Reply-To: <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 98487c5e-de66-4456-8512-08d3c543f31d
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1455; 6:v/kPVcQ/h7n1sWYSia0XwI42+ikQdOMLAQGqYzEaNgihPGk4YQCXHnBQOzZQRQB/EOrMbVLIKlaKqQCgbCaHpc3vxhG5tUcK7b43qYE35RBL74e1QojlaB0IeaIETN35VVHn2dtOkggJJ5sj3MXRhw/e3DQidakbvTx6gmCH4QFqQUYvRDtYWrLBmW6lJvmEGW9TEpMYQvvpewURhQCdGkkQ6kls11Y5Mcg4YCq5um8TYcsTawklJHp5fclgdq54jaO4CdsVZ7hGpSzg+Re1CxZgyf7bfO07OMcPHGuR1TI3Zq9OgdCDE5PF+aVblukFwRLE98+mSCznKiuO7XaqKA==; 5:lT1HNQQtfaptFtZ2NcA3HhbVqAa1jnpyQM/gU139gHiqA3g5DK7Am3uOzgGzbpwzZDpsQOJWcdMJagHW/cq+3+TbeeOHR0zj58ylGHUHFIHiP6lubcbFX7yhdASHm/zanR930ZgMjkaK3i+A0ij8JQ==; 24:3jbBY1gvcuorSGrYCdG0VEBG5o3y+6ICgc6MvDqiwMW9+fo7oa17+OeRPW0LRVxROndo/9FqNy4qQVCRg2hMCCns7liG9vjuiamnI7iuSj8=; 7:US+w0KCzNJXHT1ANNuiOTLZBgLikytZHHFAXCkJS351QhXJf9upGKkDB9mcxYiSqVYzxsYVE8RWexjw4X/bE990lDHi17SDjfg6m7Xn2XnVEgzRaNRKXgALmhdBFSdYEyF/ReRHDsBY/sWvRQMDv5VaYbCgh2RLkx7dqNyH+kewARGY53ZtB+ZNEycJrw2zkXlK/osGIZedxoHis5n8TfhVgwdvt0RCXifsOHFmGlCvXlpLVkQTbSUVv0rVXr2cV
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1455;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:DM2PR0501MB1455; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1455; 
x-forefront-prvs: 0035B15214
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(24454002)(51444003)(189002)(199003)(377454003)(7736002)(106356001)(106116001)(586003)(19580405001)(305945005)(99286002)(105586002)(11100500001)(102836003)(82746002)(19580395003)(2900100001)(15975445007)(7846002)(4001350100001)(76176999)(92566002)(81166006)(97736004)(81156014)(101416001)(122556002)(8936002)(8676002)(10400500002)(93886004)(54356999)(50986999)(5002640100001)(5001770100001)(6116002)(83506001)(86362001)(77096005)(107886002)(83716003)(189998001)(2501003)(3660700001)(3846002)(575784001)(2950100001)(2171001)(66066001)(87936001)(33656002)(2906002)(36756003)(3280700002)(68736007)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1455; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2016 19:40:02.0940 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1455
Archived-At: 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Aug 2016 19:40:07 -0000

Tml0czoNCg0KMS4gRmlyc3QgaXQgc2F5cyDigJx1bnB1Ymxpc2hlZOKAnSB0aGVuIGl0IHNheXMg
4oCccG9zdGVk4oCdLCBJIHRoaW5rIGl0IGJldHRlciB0byByZXBsYWNlIHRoZSBsYXR0ZXIgd2l0
aCDigJxwdWJsaXNoZWTigJ0gc28gdGhlIHRlcm1zIGFyZSBjb25zaXN0ZW50Lg0KDQoyLiDigJx1
bnB1Ymxpc2hlZOKAnSBpcyB1bmNsZWFyLiAgQXQgbGVhc3QgSSBjb25zaWRlciBzdWJtaXR0aW5n
IGFuIEktRCB0byBkYXRhdHJhY2tlciBhcyBhIGZvcm0gb2YgcHVibGlzaGluZy4gIEkgdGhpbmsg
aXQgbWlnaHQgYmUgYmV0dGVyIGhlcmUgdG8gcmVmZXIgdG8gc29tZXRoaW5nIGxpa2Ug4oCcd29y
a3MgaW4gcHJvZ3Jlc3PigJ0uDQoNCjMuIEluc3RlYWQgb2Ygc2F5aW5nIOKAnHdoZW4gYSBuZXcg
dmVyc2lvbiAob2YgdGhlIEktRCkgaXMgcG9zdGVk4oCdLCBpdCB3b3VsZCBiZSBjbGVhcmVyIHRv
IHNheSDigJx3aGVuIGEgbmV3IHZlcnNpb24gaXMgcG9zdGVkIChlLmcuLCBpdCBiZWNvbWVzIGFu
IFJGQynigJ0uDQoNCktlbnQgIC8vIGFzIGEgY29udHJpYnV0b3INCg0KDQoNCg0KT24gOC8xNS8x
NiwgMzoxNyBQTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgUmFuZHkgUHJlc3VobiIgPG5ldG1vZC1i
b3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiByYW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9y
ZC5lZHU+IHdyb3RlOg0KDQogICAgSGkgLQ0KICAgIA0KICAgIFRoaXMgYWxzbyB3b3JrcyBmb3Ig
bWUsIGJ1dCBJJ2QgcmVwbGFjZSB0aGUgb2RkICJNQVkiIHdpdGggdGhlIHdvcmQgIm5lZWQiLg0K
ICAgIA0KICAgIChUaGUgc2VtYW50aWNzIG9mICJvbmx5IiBhbmQgb2YgIk1BWSIgZG9uJ3QgcXVp
dGUgbWVzaC4pDQogICAgDQogICAgUmFuZHkNCiAgICANCiAgICBPbiA4LzE1LzIwMTYgNDo0NCBB
TSwgTGFkaXNsYXYgTGhvdGthIHdyb3RlOg0KICAgID4+IE9uIDE1IEF1ZyAyMDE2LCBhdCAxMzoz
MSwgV2lsbGlhbSBMdXB0b24gPHdsdXB0b25AYnJvYWRiYW5kLWZvcnVtLm9yZz4gd3JvdGU6DQog
ICAgPj4NCiAgICA+PiBBaCEgUmUtcmVhZGluZyBpdCBJIHRoaW5rIHRoYXQgeW91IGFyZSBjb3Jy
ZWN0LiBJbiB0aGlzIHNwaXJpdCBJIHByb3Bvc2UgdGhlIGNoYW5nZSBzaG93biBiZWxvdy4gSSBi
ZWxpZXZlIHRoYXQgYWxsIHRoaXMgZG9lcyBpcyAoYSkgZ2VuZXJhbGlzZSwgYW5kIChiKSBjbGFy
aWZ5LiBJIGRvbuKAmXQgYmVsaWV2ZSB0aGF0IGl0IGNoYW5nZXMgdGhlIGludGVuZGVkIG1lYW5p
bmcuDQogICAgPj4NCiAgICA+PiBPTEQ6DQogICAgPj4NCiAgICA+PiBJdCBpcyBhY2NlcHRhYmxl
IHRvIHJldXNlIHRoZSBzYW1lIHJldmlzaW9uIHN0YXRlbWVudCB3aXRoaW4gdW5wdWJsaXNoZWQg
dmVyc2lvbnMgKGkuZS4sIEludGVybmV0LURyYWZ0cyksIGJ1dCB0aGUgcmV2aXNpb24gZGF0ZSBN
VVNUIGJlIHVwZGF0ZWQgdG8gYSBoaWdoZXIgdmFsdWUgZWFjaCB0aW1lIHRoZSBJbnRlcm5ldC1E
cmFmdCBpcyByZS1wb3N0ZWQuDQogICAgPj4NCiAgICA+PiBORVc6DQogICAgPj4NCiAgICA+PiBJ
dCBpcyBhY2NlcHRhYmxlIHRvIHJldXNlIHRoZSBzYW1lIHJldmlzaW9uIHN0YXRlbWVudCB3aXRo
aW4gdW5wdWJsaXNoZWQgdmVyc2lvbnMgKGUuZy4sIEludGVybmV0LURyYWZ0cyksIGJ1dCB0aGUg
cmV2aXNpb24gZGF0ZSAoaS5lLiwgdGhlIHJldmlzaW9uIHN0YXRlbWVudOKAmXMgYXJndW1lbnQp
IE1VU1QgYmUgdXBkYXRlZCB0byBhIGhpZ2hlciB2YWx1ZSBlYWNoIHRpbWUgYSBuZXcgdmVyc2lv
biAoZS5nLiwgb2YgdGhlIEludGVybmV0LURyYWZ0KSBpcyBwb3N0ZWQuDQogICAgPiBJdCBzZWVt
cyBzdHJhbmdlIHRvIHRhbGsgYWJvdXQgcmV1c2luZyB0aGUgcmV2aXNpb24gc3RhdGVtZW50IGFu
ZCwgaW4gdGhlIHNhbWUgc2VudGVuY2UsIHJlcXVpcmUgdG8gY2hhbmdlIGl0cyBhcmd1bWVudC4g
V2hhdCBhYm91dCB0aGlzOg0KICAgID4NCiAgICA+IE5FVw0KICAgID4NCiAgICA+IEl0IGlzIG5v
dCByZXF1aXJlZCB0byBrZWVwIHRoZSByZXZpc2lvbiBoaXN0b3J5IG9mIHVucHVibGlzaGVkIHZl
cnNpb25zIChlLmcuLCBJbnRlcm5ldC1EcmFmdHMpLiBUaGF0IGlzLCB3aXRoaW4gYSBzZXF1ZW5j
ZSBvZiB1bnB1Ymxpc2hlZCB2ZXJzaW9ucywgb25seSB0aGUgbW9zdCByZWNlbnQgcmV2aXNpb24g
TUFZIGJlIHJlY29yZGVkIGluIHRoZSBtb2R1bGUgb3Igc3VibW9kdWxlLiBIb3dldmVyLCB0aGUg
cmV2aXNpb24gZGF0ZSBvZiB0aGUgbW9zdCByZWNlbnQgcmV2aXNpb24gTVVTVCBiZSB1cGRhdGVk
IHRvIGEgaGlnaGVyIHZhbHVlIGVhY2ggdGltZSBhIG5ldyB2ZXJzaW9uIChlLmcuLCBvZiB0aGUg
SW50ZXJuZXQtRHJhZnQpIGlzIHBvc3RlZC4NCiAgICA+DQogICAgPiBMYWRhDQogICAgPg0KICAg
ID4+IOKAlOKAlA0KICAgID4+DQogICAgPj4gQ29tbWVudHM/DQogICAgPj4NCiAgICA+Pj4gT24g
MTEgQXVnIDIwMTYsIGF0IDE3OjI2LCBSYW5keSBQcmVzdWhuIDxyYW5keV9wcmVzdWhuQGFsdW1u
aS5zdGFuZm9yZC5lZHU+IHdyb3RlOg0KICAgID4+Pg0KICAgID4+PiBIaSAtDQogICAgPj4+DQog
ICAgPj4+IEkgcmVhZCB0aGUgdGV4dCBhcyBpbnRlbmRlZCB0byBtYWtlIGEgZGlzdGluY3Rpb24g
YmV0d2VlbiB0aGUgKmRhdGUqIHBvcnRpb24gYW5kIHRoZSByZXN0DQogICAgPj4+DQogICAgPj4+
IG9mIHRoZSByZXZpc2lvbiBzdGF0ZW1lbnQuICBXaGVuIGEgbW9kdWxlIGlzIHVuZGVyIGRldmVs
b3BtZW50LCByZXRhaW5pbmcgYSBoaXN0b3J5DQogICAgPj4+DQogICAgPj4+IG9mIHNwZWNpZmlj
IGluY3JlbWVudGFsIGNoYW5nZXMgaXNuJ3QgdGVycmlibHkgaGVscGZ1bCwgYnV0IGNoYW5naW5n
IHRoZSBkYXRlIGlzIGVzc2VudGlhbA0KICAgID4+Pg0KICAgID4+PiB0byBoZWxwaW5nIHRvb2xz
IGRlY2lkZSBhbW9uZyB0aGUgdmVyc2lvbnMgZmxvYXRpbmcgYXJvdW5kIGluIHRoZSBsYWIuDQog
ICAgPj4+DQogICAgPj4+DQogICAgPj4+IFJhbmR5IChleHBlcmltZW50aW5nIHdpdGggbWFpbCBy
ZWFkZXJzLCBwbGVhc2UgZm9yZ2l2ZSBmb3JtYXR0aW5nIGFub21hbGllcykNCiAgICA+Pj4NCiAg
ICA+Pj4NCiAgICA+Pj4gT24gOC8xMS8yMDE2IDk6MTcgQU0sIFdpbGxpYW0gTHVwdG9uIHdyb3Rl
Og0KICAgID4+Pj4gVGhhbmtzLiBlLmcgcmF0aGVyIHRoYW4gaS5lIHNvdW5kcyBnb29kLCBCVVQg
bXkgcG9pbnQgKHNvcnJ5IGlmIHRoYXQgd2FzbuKAmXQgY2xlYXIpIGlzIHRoYXQgdGhpcyBzZW50
ZW5jZSBzZWVtcyB0byBiZSBjb250cmFkaWN0b3J5LiBJdCBzYXlzOg0KICAgID4+Pj4NCiAgICA+
Pj4+IDEuIFVucHVibGlzaGVkIHZlcnNpb25zLCBpLmUgSURzLCBjYW4gcmV1c2UgcmV2aXNpb24g
c3RhdGVtZW50cy4NCiAgICA+Pj4+IDIuIElEcyBNVVNUIHVwZGF0ZSB0aGVpciByZXZpc2lvbiBk
YXRlcyBlYWNoIHRpbWUgdGhleSBhcmUgcmUtcG9zdGVkLg0KICAgID4+Pj4NCiAgICA+Pj4+IE15
IHN1Z2dlc3Rpb24gb2YgcmVtb3ZpbmcgdGhlIHBhcmVudGhlc2lzZWQgdGV4dCB3YXMgdG8gcmVt
b3ZlIHRoaXMgY29udHJhZGljdGlvbi4gUmlnaHQgbm93IEnigJltIG5vdCBjbGVhciB0aGF0IEkg
Y2FuIHJlbHkgb24gcmV2aXNpb24gZGF0ZXMgaW4gWUFORyBtb2R1bGVzIGNvbnRhaW5lZCB3aXRo
aW4gSURzLg0KICAgID4+Pj4NCiAgICA+Pj4+IFdpbGxpYW0NCiAgICA+Pj4+DQogICAgPj4+PiBQ
UywgSSB0aGluayB0aGF0IHRoZSByZW1vdmFsIG9mIHRoaXMgdGV4dCByZW1vdmVzIHRoZSBjb250
cmFkaWN0aW9uIGJlY2F1c2UgaW4gb3JkZXIgdG8gbWFrZSBzZW5zZSBvZiB0aGUgc2VudGVuY2Ug
dGhlIHJlYWRlciB3aWxsIGJlIGZvcmNlZCB0byB0aGUgY29uY2x1c2lvbiB0aGF0IElEcyBhcmUg
bm90IHJlZ2FyZGVkIGFzIGJlaW5nIOKAnHVucHVibGlzaGVk4oCdLg0KICAgID4+Pj4NCiAgICA+
Pj4+PiBPbiAxMSBBdWcgMjAxNiwgYXQgMTc6MDcsIFJhbmR5IFByZXN1aG4gPHJhbmR5X3ByZXN1
aG5AYWx1bW5pLnN0YW5mb3JkLmVkdSA8bWFpbHRvOnJhbmR5X3ByZXN1aG5AYWx1bW5pLnN0YW5m
b3JkLmVkdT4+IHdyb3RlOg0KICAgID4+Pj4+DQogICAgPj4+Pj4gSGkgLQ0KICAgID4+Pj4+DQog
ICAgPj4+Pj4gVGhlIHNpdHVhdGlvbiB3aXRoIEludGVybmV0LURyYWZ0cyBpcyB3aGF0IG1vdGl2
YXRlZCB0aGlzIHRleHQgaW4gdGhlIGZpcnN0IHBsYWNlLCBzbw0KICAgID4+Pj4+IEkgdGhpbmsg
aXQgaXMgaW1wb3J0YW50IHRvIHJldGFpbiB0aGF0IGluZm9ybWF0aW9uLiAgSG93ZXZlciwgaXQg
c2VlbXMgdG8gbWUgdGhhdA0KICAgID4+Pj4+IHRoZSAiaS5lLiIgaXMgdG9vIGxpbWl0aW5nLCBh
bmQgc2hvdWxkIGJlIHJlcGxhY2VkIHdpdGggYW4gImUuZy4iLg0KICAgID4+Pj4+DQogICAgPj4+
Pj4gUmFuZHkNCiAgICA+Pj4+Pg0KICAgID4+Pj4+IE9uIDgvMTEvMjAxNiAyOjA2IEFNLCBXaWxs
aWFtIEx1cHRvbiB3cm90ZToNCiAgICA+Pj4+Pj4gQWxsLA0KICAgID4+Pj4+Pg0KICAgID4+Pj4+
PiBUaGUgdGV4dCBhdCB0aGUgYm90dG9tIG9mIFJGQyA2MDg3YmlzIChkcmFmdCAwNykgU2VjdGlv
biA1Ljggc2VlbXMgdW5jbGVhcjoNCiAgICA+Pj4+Pj4NCiAgICA+Pj4+Pj4gIkl0IGlzIGFjY2Vw
dGFibGUgdG8gcmV1c2UgdGhlIHNhbWUgcmV2aXNpb24gc3RhdGVtZW50IHdpdGhpbiB1bnB1Ymxp
c2hlZCB2ZXJzaW9ucyAoaS5lLiwgSW50ZXJuZXQtRHJhZnRzKSwgYnV0IHRoZSByZXZpc2lvbiBk
YXRlIE1VU1QgYmUgdXBkYXRlZCB0byBhIGhpZ2hlciB2YWx1ZSBlYWNoIHRpbWUgdGhlIEludGVy
bmV0LURyYWZ0IGlzIHJlLXBvc3RlZOKAnQ0KICAgID4+Pj4+Pg0KICAgID4+Pj4+PiBBc3N1bWlu
ZyB0aGF0IHRoZSBpbnRlbnQgaXMgdGhhdCB0aGUgcmV2aXNpb24gc3RhdGVtZW50cyBpbiBZQU5H
IG1vZGVscyBjb250YWluZWQgd2l0aGluIElEcyBtdXN0IGJlIHVwZGF0ZWQgd2hlbmV2ZXIgdGhl
IG1vZGVscyBhcmUgdXBkYXRlZCwgIHdvdWxkbuKAmXQgaXQgYmUgY2xlYXJlciBpZiB0aGUgcGFy
ZW50aGVzaXNlZCB0ZXh0ICIoaS5lLiwgSW50ZXJuZXQtRHJhZnRzKeKAnSB3YXMgZGVsZXRlZD8N
CiAgICA+Pj4+Pj4NCiAgICA+Pj4+Pj4gVGhhbmtzLA0KICAgID4+Pj4+PiBXaWxsaWFtDQogICAg
Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+
PiBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgPj4gbmV0bW9kQGlldGYub3JnDQogICAgPj4gaHR0
cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+IC0tDQogICAg
PiBMYWRpc2xhdiBMaG90a2EsIENaLk5JQyBMYWJzDQogICAgPiBQR1AgS2V5IElEOiBFNzRFOEMw
Qw0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICANCiAgICANCiAgICAtLS0NCiAgICBU
aGlzIGVtYWlsIGhhcyBiZWVuIGNoZWNrZWQgZm9yIHZpcnVzZXMgYnkgQXZhc3QgYW50aXZpcnVz
IHNvZnR3YXJlLg0KICAgIGh0dHBzOi8vd3d3LmF2YXN0LmNvbS9hbnRpdmlydXMNCiAgICANCiAg
ICBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgIG5l
dG1vZCBtYWlsaW5nIGxpc3QNCiAgICBuZXRtb2RAaWV0Zi5vcmcNCiAgICBodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0KDQo=


From nobody Mon Aug 15 13:30: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 E8D7912D133 for ; Mon, 15 Aug 2016 13:30:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Level: 
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 c-PlagT2dgtD for ; Mon, 15 Aug 2016 13:30: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 9860912D0BD for ; Mon, 15 Aug 2016 13:30:36 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 00070E4D; Mon, 15 Aug 2016 22:30:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qoNuspeJRLj7; Mon, 15 Aug 2016 22:30:32 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 15 Aug 2016 22:30:32 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6A3F9200A5; Mon, 15 Aug 2016 22:30:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8ro9wPFexaZY; Mon, 15 Aug 2016 22:30:31 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 2F502200A3; Mon, 15 Aug 2016 22:30:31 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 135C83C1EE99; Mon, 15 Aug 2016 22:30:30 +0200 (CEST)
Date: Mon, 15 Aug 2016 22:30:30 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20160815203030.GA463@elstar.local>
Mail-Followup-To: Kent Watsen , Randy Presuhn , "netmod@ietf.org" 
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
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, 15 Aug 2016 20:30:39 -0000

On Mon, Aug 15, 2016 at 07:40:02PM +0000, Kent Watsen wrote:

> 2. “unpublished” is unclear.  At least I consider submitting an I-D to datatracker as a form of publishing.  I think it might be better here to refer to something like “works in progress”.

Perhaps this is what authors think these days but RFC 2026 makes a
clear distinction between 'publish' and 'made available'. See section
2.2 for more details. Uploading a document to a server really is not
the same as publishing in the traditional sense (and clearly not for
people with an academic background).

Yes, uploading some text to a server makes the text publicly
accessible (make avaliable in RFC 2016 terms) but there is a big
difference between a formally published document in a certain series
that exercises some sort of quality control according to the rules of
the series and simply making something public.

Perhaps we should make it clear that 'publish' is meant in the
traditional RFC 2026 sense.

/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 Aug 15 13:47: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 76B3012B025 for ; Mon, 15 Aug 2016 13:47:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5aIGRL4LNYgK for ; Mon, 15 Aug 2016 13:47:49 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0126.outbound.protection.outlook.com [104.47.33.126]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AC05B127077 for ; Mon, 15 Aug 2016 13:47:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4DllMBcwxZTRApuNvHP+cGiK40Jy8pFKGqp0cS+HQCk=; b=CG6QRGoKwh60A+f1EzKyivgvIXcqlvM2a+1GURj062YjpLbjJhKZSAIU1ZSOrPxYIPVrqPQJQ4oYWVJmEvy2JLmBpbSx2ahYYiqCh/ePvG/h9SgNc+NCKTW9gBnFI5stqIcBtCjl5yZucpm5yW3t3oUM+z0HnEg6ageaDAzLzSc=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1454.namprd05.prod.outlook.com (10.161.224.151) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Mon, 15 Aug 2016 20:47:46 +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.0557.009; Mon, 15 Aug 2016 20:47:46 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
Thread-Topic: [netmod] RFC 6087bis guidance re use of revision statements in drafts
Thread-Index: AQHR8+pveoloFBy3lEe/DmhYdxEvH6BD7+OAgAACe4CABfbngIAAA8cAgAB+hQD//8MtAIAAUScA///BxoA=
Date: Mon, 15 Aug 2016 20:47:46 +0000
Message-ID: 
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net> <20160815203030.GA463@elstar.local>
In-Reply-To: <20160815203030.GA463@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: fee4660f-b7d0-407d-762c-08d3c54d69cd
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1454; 6:yozzy0I6kNNzT3O6r5V4JGUxU6huH87/GzGh1nalkCmLnSrcq5xxy5f7t3So6nU5EztoMNNXq/CWT6nYGBDnP1ky01dkGD4Ps845jzLPB95iBjqjV1x5bHQJsFVZQKaVJjsbwvXMSV3KqABkzdLSEkf/Y8LFXuVg2sD09chbk6w68B+C2xrEOQ/oa/mtQ57xmrTUE1XKM3/isIE7K3IfvvbV7vrinMI4oB4PMKQifsPy65m5KkwLmcS2jbYM1V1eOrBaFInDDxNiy03MC6deYlF8QNUWwwU9or/c+kh10ImlzZzQpSsgfYVoSaF3b/e6o3fYkoGK5EyG0KK5O3TKpA==; 5:WRJC6nXqPCl1RDHUmqUOb/9LLN8pwVMDz7LmIP3HRB05G3yxISbbuTl6e67NGIRaknLLgtdY3iFi7ZsK1+x8TD7JCNzlm3CPvtHbe8nYelZRHJvc/OoLNzydIjQkcD361vhedMjVYRg71IO2tAZXgw==; 24:obZ6LSTOt2e6MEwaWvzzpwyzvImYlvX9zODUkyeY/y3j8ghVqzpHRTIfjf6/irSCMkflam922z1bMbBoUkFTuqdsID7VNXXcFY/HjOVTyOE=; 7:rg9Ty577etVtzvQS7GAFHVOdsW3ZsXVsmc54/XX3tfQwb9BqKcytKRdkoVat3lbQO8wSrqxiCJWpFm/qNVzX2l4h+8mjO0dyKIkT3DCcCDy9DKFJ45ONevFPk+J4tbrBM4+4FZ5CCEof/wiUp+GW4BXirFBcwITaxA7qBrcPT56TLGHOrNzCDxwpywoatnSlOUycYLccGM0Z8fD7zgBoOZ5Vqr2oQz35jjcTyxbaEBC/m5Ia50gVr4NixtMf+CQy
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1454;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM2PR0501MB1454; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1454; 
x-forefront-prvs: 0035B15214
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51444003)(199003)(189002)(36756003)(33656002)(3846002)(7736002)(50986999)(93886004)(11100500001)(4326007)(77096005)(7846002)(10400500002)(54356999)(87936001)(101416001)(76176999)(2900100001)(4001350100001)(2950100001)(83506001)(66066001)(189998001)(3280700002)(122556002)(92566002)(86362001)(97736004)(110136002)(3660700001)(106116001)(6116002)(81166006)(5002640100001)(83716003)(68736007)(81156014)(8936002)(102836003)(305945005)(586003)(2906002)(105586002)(82746002)(99286002)(8676002)(106356001)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1454; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <7B61C8788FA27F4DABCCF2880CE00CD8@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Aug 2016 20:47:46.5887 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1454
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 15 Aug 2016 20:47:51 -0000

PiAgICBQZXJoYXBzIHdlIHNob3VsZCBtYWtlIGl0IGNsZWFyIHRoYXQgJ3B1Ymxpc2gnIGlzIG1l
YW50IGluIHRoZQ0KPiAgICB0cmFkaXRpb25hbCBSRkMgMjAyNiBzZW5zZS4NCg0KV2UgY291bGQg
YWRkIGEgcmVmZXJlbmNlIHRvIFJGQyAyMDI2LCBidXQgSSB0aGluayB0aGF0IGl04oCZcyBlYXN5
IGVub3VnaCB0byBtYWtlIHRoZSB0ZXh0IHVuZGVyc3RhbmRhYmxlIHRvIGFueSByZWFkZXIsIHJl
Z2FyZGxlc3MgdGhlaXIgZmFtaWxpYXJpdHkgd2l0aCBJRVRGIHByb2Nlc3MuICAgSSBsaWtlIHRo
YXQgd2XigJl2ZSBtb3ZlZCBJRVRGLXNwZWNpZmljIHRleHQgaW50byBwYXJlbnRoZXNlcywgYW5k
IGhlbmNlIGhvcGluZyB0byBhdm9pZCBhbnkgSUVURi1sb2FkZWQgd29yZHMgb3V0c2lkZSBwYXJl
bnRoZXNlcyB3aGVyZSBwb3NzaWJsZS4NCg0KS2VudA0KIA0KDQo=


From nobody Mon Aug 15 13:54: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 4C68C12D763 for ; Mon, 15 Aug 2016 13:54:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Level: 
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 4Z7mCTGO1xnR for ; Mon, 15 Aug 2016 13:54: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 D525B12D50E for ; Mon, 15 Aug 2016 13:54:47 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8691CCDA; Mon, 15 Aug 2016 22:54:46 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id FHdX5swngGtU; Mon, 15 Aug 2016 22:54:44 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 15 Aug 2016 22:54:45 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3FB91200A3; Mon, 15 Aug 2016 22:54:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id vHTdib1CZZX7; Mon, 15 Aug 2016 22:54:42 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 346162009B; Mon, 15 Aug 2016 22:54:41 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2B3013C1EF27; Mon, 15 Aug 2016 22:54:41 +0200 (CEST)
Date: Mon, 15 Aug 2016 22:54:41 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20160815205441.GA511@elstar.local>
Mail-Followup-To: Kent Watsen , Randy Presuhn , "netmod@ietf.org" 
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net> <20160815203030.GA463@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
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, 15 Aug 2016 20:54:49 -0000

On Mon, Aug 15, 2016 at 08:47:46PM +0000, Kent Watsen wrote:
> >    Perhaps we should make it clear that 'publish' is meant in the
> >    traditional RFC 2026 sense.
> 
> We could add a reference to RFC 2026, but I think that it’s easy enough to make the text understandable to any reader, regardless their familiarity with IETF process.   I like that we’ve moved IETF-specific text into parentheses, and hence hoping to avoid any IETF-loaded words outside parentheses where possible.
>

Whatever the wording is, I believe there is a fundamental difference
between someone simply making something available and something that
becomes accessible (persistently) after having gone through a review
and quality ensurance process.

/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 Aug 16 05: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 EC14112D7C6 for ; Tue, 16 Aug 2016 05:11:36 -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 0_mmIWpcDFQS for ; Tue, 16 Aug 2016 05:11:34 -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 4EB7112DA9C for ; Tue, 16 Aug 2016 04:57:48 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id D62E11E5A35; Tue, 16 Aug 2016 04:54:00 -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 7vWRUSiwEJFQ; Tue, 16 Aug 2016 04:54:00 -0700 (PDT)
Received: from [192.168.1.127] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id D145A1E5A34; Tue, 16 Aug 2016 04:53:59 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: William Lupton 
In-Reply-To: <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>
Date: Tue, 16 Aug 2016 12:57:45 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>
To: Kent Watsen 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Aug 2016 12:11:37 -0000

Kent,

A couple of your comments have suggested that you feel that the =E2=80=9Cn=
ew version is posted=E2=80=9D language should be clarified in the =
direction (for IETF YANG) of =E2=80=9CID becomes RFC=E2=80=9D. That=E2=80=99=
s not how I read the original or how I read most of the discussion, and =
it=E2=80=99s also not the clarification that I was hoping for!

Regardless of the discussion about =E2=80=9Cpublished=E2=80=9D, other =
organisations may be planning to use YANG modules that are currently =
within IDs. Obviously it=E2=80=99s vastly preferable if such IDs become =
RFCs before these other organisations publish any specifications or data =
models that use such draft IETF YANG, but it might occasionally be =
necessary to reference a draft model (hopefully one that has already =
been sent for AD review) in a published standard. This is why I would =
like the clarification to cover IDs (at least WG-adopted ones)!

Thanks,
William

> On 15 Aug 2016, at 20:40, Kent Watsen  wrote:
>=20
> Nits:
>=20
> 1. First it says =E2=80=9Cunpublished=E2=80=9D then it says =
=E2=80=9Cposted=E2=80=9D, I think it better to replace the latter with =
=E2=80=9Cpublished=E2=80=9D so the terms are consistent.
>=20
> 2. =E2=80=9Cunpublished=E2=80=9D is unclear.  At least I consider =
submitting an I-D to datatracker as a form of publishing.  I think it =
might be better here to refer to something like =E2=80=9Cworks in =
progress=E2=80=9D.
>=20
> 3. Instead of saying =E2=80=9Cwhen a new version (of the I-D) is =
posted=E2=80=9D, it would be clearer to say =E2=80=9Cwhen a new version =
is posted (e.g., it becomes an RFC)=E2=80=9D.
>=20
> Kent  // as a contributor
>=20
>=20
>=20
>=20
> On 8/15/16, 3:17 PM, "netmod on behalf of Randy Presuhn" =
 =
wrote:
>=20
>    Hi -
>=20
>    This also works for me, but I'd replace the odd "MAY" with the word =
"need".
>=20
>    (The semantics of "only" and of "MAY" don't quite mesh.)
>=20
>    Randy
>=20
>    On 8/15/2016 4:44 AM, Ladislav Lhotka wrote:
>>> On 15 Aug 2016, at 13:31, William Lupton =
 wrote:
>>>=20
>>> Ah! Re-reading it I think that you are correct. In this spirit I =
propose the change shown below. I believe that all this does is (a) =
generalise, and (b) clarify. I don=E2=80=99t believe that it changes the =
intended meaning.
>>>=20
>>> OLD:
>>>=20
>>> It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is re-posted.
>>>=20
>>> NEW:
>>>=20
>>> It is acceptable to reuse the same revision statement within =
unpublished versions (e.g., Internet-Drafts), but the revision date =
(i.e., the revision statement=E2=80=99s argument) MUST be updated to a =
higher value each time a new version (e.g., of the Internet-Draft) is =
posted.
>> It seems strange to talk about reusing the revision statement and, in =
the same sentence, require to change its argument. What about this:
>>=20
>> NEW
>>=20
>> It is not required to keep the revision history of unpublished =
versions (e.g., Internet-Drafts). That is, within a sequence of =
unpublished versions, only the most recent revision MAY be recorded in =
the module or submodule. However, the revision date of the most recent =
revision MUST be updated to a higher value each time a new version =
(e.g., of the Internet-Draft) is posted.
>>=20
>> Lada
>>=20
>>> =E2=80=94=E2=80=94
>>>=20
>>> Comments?
>>>=20
>>>> On 11 Aug 2016, at 17:26, Randy Presuhn =
 wrote:
>>>>=20
>>>> Hi -
>>>>=20
>>>> I read the text as intended to make a distinction between the =
*date* portion and the rest
>>>>=20
>>>> of the revision statement.  When a module is under development, =
retaining a history
>>>>=20
>>>> of specific incremental changes isn't terribly helpful, but =
changing the date is essential
>>>>=20
>>>> to helping tools decide among the versions floating around in the =
lab.
>>>>=20
>>>>=20
>>>> Randy (experimenting with mail readers, please forgive formatting =
anomalies)
>>>>=20
>>>>=20
>>>> On 8/11/2016 9:17 AM, William Lupton wrote:
>>>>> Thanks. e.g rather than i.e sounds good, BUT my point (sorry if =
that wasn=E2=80=99t clear) is that this sentence seems to be =
contradictory. It says:
>>>>>=20
>>>>> 1. Unpublished versions, i.e IDs, can reuse revision statements.
>>>>> 2. IDs MUST update their revision dates each time they are =
re-posted.
>>>>>=20
>>>>> My suggestion of removing the parenthesised text was to remove =
this contradiction. Right now I=E2=80=99m not clear that I can rely on =
revision dates in YANG modules contained within IDs.
>>>>>=20
>>>>> William
>>>>>=20
>>>>> PS, I think that the removal of this text removes the =
contradiction because in order to make sense of the sentence the reader =
will be forced to the conclusion that IDs are not regarded as being =
=E2=80=9Cunpublished=E2=80=9D.
>>>>>=20
>>>>>> On 11 Aug 2016, at 17:07, Randy Presuhn =
> wrote:
>>>>>>=20
>>>>>> Hi -
>>>>>>=20
>>>>>> The situation with Internet-Drafts is what motivated this text in =
the first place, so
>>>>>> I think it is important to retain that information.  However, it =
seems to me that
>>>>>> the "i.e." is too limiting, and should be replaced with an =
"e.g.".
>>>>>>=20
>>>>>> Randy
>>>>>>=20
>>>>>> On 8/11/2016 2:06 AM, William Lupton wrote:
>>>>>>> All,
>>>>>>>=20
>>>>>>> The text at the bottom of RFC 6087bis (draft 07) Section 5.8 =
seems unclear:
>>>>>>>=20
>>>>>>> "It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is =
re-posted=E2=80=9D
>>>>>>>=20
>>>>>>> Assuming that the intent is that the revision statements in YANG =
models contained within IDs must be updated whenever the models are =
updated,  wouldn=E2=80=99t it be clearer if the parenthesised text =
"(i.e., Internet-Drafts)=E2=80=9D was deleted?
>>>>>>>=20
>>>>>>> Thanks,
>>>>>>> William
>>> _______________________________________________
>>> 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
>=20
>=20
>    ---
>    This email has been checked for viruses by Avast antivirus =
software.
>    https://www.avast.com/antivirus
>=20
>    _______________________________________________
>    netmod mailing list
>    netmod@ietf.org
>    https://www.ietf.org/mailman/listinfo/netmod
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Tue Aug 16 05:13:57 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 65FB312D868 for ; Tue, 16 Aug 2016 05:13:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.247
X-Spam-Level: 
X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9YQU78TxP_PX for ; Tue, 16 Aug 2016 05:13:54 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0A72512DB66 for ; Tue, 16 Aug 2016 05:01:56 -0700 (PDT)
Received: from [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360] (unknown [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 5B35A20014 for ; Tue, 16 Aug 2016 14:01:54 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1471348914; bh=zcA+yP6KoLcW2FoIVtwPL5VmTbboalU2jsLyvDhlQek=; h=From:Subject:To:Date; b=p73sZUnVJVKdHLma/maAiYjKgEnQvtCn3FygvpTvUIHHuLNaHsOTwHpO7KINbz1bX 8Bf1V6cEIMoYK5/ZKxefUL2HTDaNzNJZEtXVfIG5ZzebBdV477dLYgrRu436RPNfq6 gYU+j9uUfVsGSX+9dUpdc9x5JrisX2GqHCnzhYv8=
From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= 
To: "netmod@ietf.org" 
Message-ID: <76f5738b-f973-94e3-6db4-da68ab5ec0c8@cesnet.cz>
Date: Tue, 16 Aug 2016 14:01:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: [netmod] clarification of default values in leaf-list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Aug 2016 12:13:56 -0000

Hi all,
I'm not sure what is actually the default value in leaf-list if there are=
 multiple default statements. Is it each of the values defined as default=
 or the set of default values together? My point is, in case of NETCONF w=
ith-defaults capability, when the leaf-list instance is supposed to be ma=
rked as default (report-all-tagged retrieval mode) - when it contains one=
 of the values defined as default or only when there is a complete set of=
 default values (and in case of user-ordered leaf-list, when they are in =
correct order)?

Regards,
Radek Krejci


From nobody Tue Aug 16 05:37: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 5A32012D104 for ; Tue, 16 Aug 2016 05:37:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 7Zh5RWp8DuVn for ; Tue, 16 Aug 2016 05:37:54 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E91A512D147 for ; Tue, 16 Aug 2016 05:37:52 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 1F1AD1AE02BC; Tue, 16 Aug 2016 14:37:52 +0200 (CEST)
Date: Tue, 16 Aug 2016 14:36:58 +0200 (CEST)
Message-Id: <20160816.143658.158624020963729615.mbj@tail-f.com>
To: rkrejci@cesnet.cz
From: Martin Bjorklund 
In-Reply-To: <76f5738b-f973-94e3-6db4-da68ab5ec0c8@cesnet.cz>
References: <76f5738b-f973-94e3-6db4-da68ab5ec0c8@cesnet.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=utf-8
Content-Transfer-Encoding: base64
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] clarification of default values in leaf-list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Aug 2016 12:37:55 -0000

UmFkZWsgS3JlasSNw60gPHJrcmVqY2lAY2VzbmV0LmN6PiB3cm90ZToNCj4gSGkgYWxsLA0KPiBJ
J20gbm90IHN1cmUgd2hhdCBpcyBhY3R1YWxseSB0aGUgZGVmYXVsdCB2YWx1ZSBpbiBsZWFmLWxp
c3QgaWYgdGhlcmUNCj4gYXJlIG11bHRpcGxlIGRlZmF1bHQgc3RhdGVtZW50cy4gIElzIGl0IGVh
Y2ggb2YgdGhlIHZhbHVlcyBkZWZpbmVkIGFzDQo+IGRlZmF1bHQgb3IgdGhlIHNldCBvZiBkZWZh
dWx0IHZhbHVlcyB0b2dldGhlcj8gTXkgcG9pbnQgaXMsIGluIGNhc2Ugb2YNCj4gTkVUQ09ORiB3
aXRoLWRlZmF1bHRzIGNhcGFiaWxpdHksIHdoZW4gdGhlIGxlYWYtbGlzdCBpbnN0YW5jZSBpcw0K
PiBzdXBwb3NlZCB0byBiZSBtYXJrZWQgYXMgZGVmYXVsdCAocmVwb3J0LWFsbC10YWdnZWQgcmV0
cmlldmFsIG1vZGUpIC0NCj4gd2hlbiBpdCBjb250YWlucyBvbmUgb2YgdGhlIHZhbHVlcyBkZWZp
bmVkIGFzIGRlZmF1bHQgb3Igb25seSB3aGVuDQo+IHRoZXJlIGlzIGEgY29tcGxldGUgc2V0IG9m
IGRlZmF1bHQgdmFsdWVzIChhbmQgaW4gY2FzZSBvZiB1c2VyLW9yZGVyZWQNCj4gbGVhZi1saXN0
LCB3aGVuIHRoZXkgYXJlIGluIGNvcnJlY3Qgb3JkZXIpPw0KDQoNCjYwMjBiaXMgc2F5czoNCg0K
ICBJZiBhIGxlYWYtbGlzdCBoYXMgb25lIG9yIG1vcmUgImRlZmF1bHQiIHN0YXRlbWVudCwgdGhl
IGxlYWYtbGlzdCdzDQogIGRlZmF1bHQgdmFsdWVzIGFyZSB0aGUgdmFsdWVzIG9mIHRoZSAiZGVm
YXVsdCIgc3RhdGVtZW50cywgYW5kIGlmIHRoZQ0KICBsZWFmLWxpc3QgaXMgdXNlci1vcmRlcmVk
LCB0aGUgZGVmYXVsdCB2YWx1ZXMgYXJlIHVzZWQgaW4gdGhlIG9yZGVyIG9mDQogIHRoZSAiZGVm
YXVsdCIgc3RhdGVtZW50cy4NCg0KRG9lc24ndCB0aGlzIGFuc3dlciB5b3VyIHF1ZXN0aW9ucz8N
Cg0KDQovbWFydGluDQo=


From nobody Tue Aug 16 05:55: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 9A2FC12D7BD for ; Tue, 16 Aug 2016 05:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.247
X-Spam-Level: 
X-Spam-Status: No, score=-3.247 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.247] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cesnet.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6l-bKwOu2bXa for ; Tue, 16 Aug 2016 05:55:20 -0700 (PDT)
Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AA2412D5F8 for ; Tue, 16 Aug 2016 05:55:20 -0700 (PDT)
Received: from [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360] (unknown [IPv6:2001:67c:1220:80c:921b:eff:fe59:4360]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by office2.cesnet.cz (Postfix) with ESMTPSA id 3418420014; Tue, 16 Aug 2016 14:55:18 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1471352118; bh=UCdcxsaxLjLNAyRDuHCm6T35kCCsvrmKhbQv3mwE8kk=; h=Subject:To:References:Cc:From:Date:In-Reply-To; b=Q6HwAV67Y/ou5gtEgUOrQTTnADTmx5bB09YqDalPMTL4UA0LFmB6b5/AruR32nMcQ LwdR+BDVAR/PTs37QxBBY1QXCVejLKAzVjKiDLnWSkzYec1GIu3rPGipl7EWuT8Nhq 6eYISVSLO5UV2UvLm0WPo0ezqp65it7H0MxbeaQs=
To: Martin Bjorklund 
References: <76f5738b-f973-94e3-6db4-da68ab5ec0c8@cesnet.cz> <20160816.143658.158624020963729615.mbj@tail-f.com>
From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= 
Message-ID: <5ecf4a8c-5b27-e3f6-6c88-0d5fbb1e4866@cesnet.cz>
Date: Tue, 16 Aug 2016 14:54:26 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2
MIME-Version: 1.0
In-Reply-To: <20160816.143658.158624020963729615.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] clarification of default values in leaf-list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Aug 2016 12:55:22 -0000

Dne 16.8.2016 v 14:36 Martin Bjorklund napsal(a):
> Radek Krej=C4=8D=C3=AD  wrote:
>> Hi all,
>> I'm not sure what is actually the default value in leaf-list if there
>> are multiple default statements.  Is it each of the values defined as
>> default or the set of default values together? My point is, in case of=

>> NETCONF with-defaults capability, when the leaf-list instance is
>> supposed to be marked as default (report-all-tagged retrieval mode) -
>> when it contains one of the values defined as default or only when
>> there is a complete set of default values (and in case of user-ordered=

>> leaf-list, when they are in correct order)?
>
> 6020bis says:
>
>   If a leaf-list has one or more "default" statement, the leaf-list's
>   default values are the values of the "default" statements, and if the=

>   leaf-list is user-ordered, the default values are used in the order o=
f
>   the "default" statements.
>
> Doesn't this answer your questions?

no, it doesn't - the "leaf-list's default values are" indicates that ther=
e can be multiple default values for the leaf-list. So each of the defaul=
t statement defines one of the leaf-list's default values. But the second=
 part refers to the default values to be used together, as a set. I think=
 that it makes better sense to use the leaf-list's default value as a set=
, but that first sentence confuses me.

Radek

>
> /martin



From nobody Tue Aug 16 08:32: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 C181F12D168 for ; Tue, 16 Aug 2016 08:32:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 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=-1.247] autolearn=unavailable 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 RPVj5PoC8GZb for ; Tue, 16 Aug 2016 08:32:05 -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 3972E12D887 for ; Tue, 16 Aug 2016 08:25:49 -0700 (PDT)
Received: from birdie.labs.nic.cz (unknown [195.113.220.110]) by mail.nic.cz (Postfix) with ESMTPSA id 90024607D1; Tue, 16 Aug 2016 17:25:47 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471361147; bh=P/aiF3zbIOnq2fxvvfFJck07rWJaq5NhjCkXGelSPZ8=; h=From:Date:To; b=WhJbB4JWU7D9H8us8gYxLE33VArJ+JDq6i5aXwpad1Ey9gDa54/4FevIu8DfQFf2p QiYcLmFdFew3DegPVVSLqETW82UwBBkwVo353R7fmU+fn6AIxUjZkylcYYMtvX+iC7 aEQmfB0XxVK6sODW71BSo0U8wpckkY3pXuqiP8d8=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <5ecf4a8c-5b27-e3f6-6c88-0d5fbb1e4866@cesnet.cz>
Date: Tue, 16 Aug 2016 17:25:49 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <76f5738b-f973-94e3-6db4-da68ab5ec0c8@cesnet.cz> <20160816.143658.158624020963729615.mbj@tail-f.com> <5ecf4a8c-5b27-e3f6-6c88-0d5fbb1e4866@cesnet.cz>
To: =?utf-8?Q?Radek_Krej=C4=8D=C3=AD?= 
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] clarification of default values in leaf-list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Aug 2016 15:32:06 -0000

> On 16 Aug 2016, at 14:54, Radek Krej=C4=8D=C3=AD  =
wrote:
>=20
> Dne 16.8.2016 v 14:36 Martin Bjorklund napsal(a):
>> Radek Krej=C4=8D=C3=AD  wrote:
>>> Hi all,
>>> I'm not sure what is actually the default value in leaf-list if =
there
>>> are multiple default statements.  Is it each of the values defined =
as
>>> default or the set of default values together? My point is, in case =
of
>>> NETCONF with-defaults capability, when the leaf-list instance is
>>> supposed to be marked as default (report-all-tagged retrieval mode) =
-
>>> when it contains one of the values defined as default or only when
>>> there is a complete set of default values (and in case of =
user-ordered
>>> leaf-list, when they are in correct order)?
>>=20
>> 6020bis says:
>>=20
>>  If a leaf-list has one or more "default" statement, the leaf-list's
>>  default values are the values of the "default" statements, and if =
the
>>  leaf-list is user-ordered, the default values are used in the order =
of
>>  the "default" statements.
>>=20
>> Doesn't this answer your questions?
>=20
> no, it doesn't - the "leaf-list's default values are" indicates that =
there can be multiple default values for the leaf-list. So each of the =
default statement defines one of the leaf-list's default values. But the =
second part refers to the default values to be used together, as a set. =
I think that it makes better sense to use the leaf-list's default value =
as a set, but that first sentence confuses me.

leaf-list foo {
    type string;
    default "zig";
    default "zag";
}

The default content is the sequence of values taken from all "default" =
statements, i.e. in JSON encoding it is

"foo": ["zig", "zag"]

Lada

>=20
> Radek
>=20
>>=20
>> /martin
>=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 Tue Aug 16 10:11: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 8947012D8F4; Tue, 16 Aug 2016 10:11:12 -0700 (PDT)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Meeting Session Request Tool\"" 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147136747253.22911.11351876026326451336.idtracker@ietfa.amsl.com>
Date: Tue, 16 Aug 2016 10:11:12 -0700
Archived-At: 
Cc: netmod-chairs@ietf.org, netmod@ietf.org
Subject: [netmod] netmod - New Meeting Session Request for IETF 97
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: Tue, 16 Aug 2016 17:11:12 -0000

A new meeting session request has just been submitted by Lou Berger, a Chair of the netmod working group.


---------------------------------------------------------
Working Group Name: NETCONF Data Modeling Language
Area Name: Operations and Management Area
Session Requester: Lou Berger

Number of Sessions: 2
Length of Session(s):  2.5 Hours, 1 Hour
Number of Attendees: 100
Conflicts to Avoid: 
 First Priority: netconf rtgwg 
 Second Priority: i2rs anima isis ospf
 Third Priority: saag


Special Requests:
  
---------------------------------------------------------


From nobody Tue Aug 16 11:02: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 39F14127058 for ; Tue, 16 Aug 2016 11:02:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ylQQIGhiWBfp for ; Tue, 16 Aug 2016 11:02:23 -0700 (PDT)
Received: from NAM03-CO1-obe.outbound.protection.outlook.com (mail-co1nam03on0105.outbound.protection.outlook.com [104.47.40.105]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BDDA12D0EE for ; Tue, 16 Aug 2016 11:02:22 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=PvKvqnrikrLeG6oCy6V7kN1skKcU2dIwoxIhzLJcmwI=; b=SiHH30IsTRRYqupjkeNkJZGYlXLcNd/EZ7QzdJeyv6G0TYPIVgitongqQ5kYLP+t9yAMhbg3uTT9cFEDKt2f6LiiCDUeMOvL5hYRoObSbxdttcFXlpLzCAaUh7I2k0E+VJuJYi8Xz5lVeryBt3dHin16FpJIcCBEKe6pEIZmi/w=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.557.8; Tue, 16 Aug 2016 18:02:20 +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.0557.009; Tue, 16 Aug 2016 18:02:20 +0000
From: Kent Watsen 
To: William Lupton 
Thread-Topic: [netmod] RFC 6087bis guidance re use of revision statements in drafts
Thread-Index: AQHR8+pveoloFBy3lEe/DmhYdxEvH6BD7+OAgAACe4CABfbngIAAA8cAgAB+hQD//8MtAIABVDmAgAAizwA=
Date: Tue, 16 Aug 2016 18:02:20 +0000
Message-ID: <0E8E72CF-1928-4AB9-A804-338069004B5E@juniper.net>
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 777e89bd-a6a8-4bca-c61e-08d3c5ff77a6
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1455; 6:WgANXQpB8mM5+l4l1Y24orLh4lN3PEWLBN8SKntOyJGzq9Tlj7C0rPtygxYxjetGPBOhcGX5WeY1lbQpTgTkMYj1Mau/LdPlzTEznR6jLdCerCXobXaQ/d7EH7jOv4FzDbl7Ihr9h39yBevG5OXz9NoLouatt6woeeM/ORlAXOiX6JyIdrxTC6BobjD5g2riERx+PaZ5rV61lgpL3eqlggCRFt+DSYPsHfrzJYUXUnS/TI+X6LnUE3kEp0gFp8r1zjQnBHnKi5FK+PVKwEIcUPiRk7nCjXpvNKqhI4goQwkpKcQQDk8yy6DVHM76GZ8X+yT6t/PM0IpojEOQca0OkA==; 5:BOZ5NjirOoCKdKwjtfvWqxXJ2VxMIsQeD27UJe48ebhQhJPjk9oTOjiWHRzqvh82AXj30CopCAXKKyJrpzGPW2NOGyllCtVla0qCda+ljlvHbImoRo9A/4Y2F05HNfdyAEAljB9t8iKLDvwB1G2lwQ==; 24:1AU1C3TDOra4/Zf13ygMDzPS1mVpFOiak26pRLKdFS/vHNiXni+24Vs0ApRbIhmP+i4gdnlPQgsJmptLA+LJEkZPl1JERKCqc9syHxhXtzI=; 7:YIoiLsexoxzMIwQDUrQziFU9xsFqoXxFNSfs6D7FtwUhy4qrad9zXkaEJnG++1RRtf3622HYRv64M5R1Onn91Yy2RnC0+UWhzGf+3yziXpu7iNeHqP2AJx209l8jXqHcW3GvRaw9kRSnO6zXiemd4PJbcGgM33HbEtHKg9ojoCGWed0f79tYybWqepQXhsZ0PwGCYLglsQpjEiKV0IwyX1XtlY67CULN7KpJgf4XvOk27lVde7I0gKhnTGmXeCgH
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1455;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(138986009662008)(788757137089);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM2PR0501MB1455; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1455; 
x-forefront-prvs: 0036736630
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(51444003)(24454002)(189002)(199003)(377454003)(106116001)(7736002)(2950100001)(19580405001)(105586002)(305945005)(82746002)(586003)(2900100001)(19580395003)(102836003)(11100500001)(4001350100001)(15975445007)(7846002)(76176999)(81166006)(97736004)(81156014)(8936002)(99286002)(122556002)(106356001)(8676002)(93886004)(92566002)(54356999)(10400500002)(101416001)(83716003)(50986999)(5002640100001)(6116002)(83506001)(77096005)(110136002)(86362001)(3660700001)(575784001)(66066001)(3846002)(33656002)(3280700002)(4326007)(2906002)(87936001)(189998001)(68736007)(36756003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1455; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <804BD44ECA9A2046AB765E3B5E8E725E@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 16 Aug 2016 18:02:20.2591 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1455
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 16 Aug 2016 18:02:26 -0000

SGkgV2lsbGlhbSwNCg0KRG8geW91IHdhbnQgdG8gdGFrZSBhIHN0YWIgb24gY29uc29saWRhdGlu
ZyBvbiB0aGUgY29tbWVudHMgaW50byBuZXcgcHJvcG9zZWQgZHJhZnQtdGV4dD8gIC0gdGhlcmUg
d2VyZSB0d28gcHJvcG9zYWxzIHB1dCBvdXQgYmVmb3JlLCBhbmQgYSBudW1iZXIgb2YgcmVmaW5l
bWVudHMgc2luY2UsIGJ1dCBJ4oCZbSB1bnN1cmUgd2hpY2ggd2VyZSBwaWNrZWQgdXAgb3Igbm90
LiAgU2luY2UgeW91IHJhaXNlZCB0aGlzIGlzc3VlIG9yaWdpbmFsbHksIGlmIHdvdWxkIGJlIGhl
bHBmdWwgdG8gZ2V0IHlvdXIgY3VycmVudCB0YWtlIG9uIGl0Lg0KDQpUaGFua3MsDQpLZW50DQoN
Cg0KT24gOC8xNi8xNiwgNzo1NyBBTSwgIldpbGxpYW0gTHVwdG9uIiA8d2x1cHRvbkBicm9hZGJh
bmQtZm9ydW0ub3JnPiB3cm90ZToNCg0KICAgIEtlbnQsDQogICAgDQogICAgQSBjb3VwbGUgb2Yg
eW91ciBjb21tZW50cyBoYXZlIHN1Z2dlc3RlZCB0aGF0IHlvdSBmZWVsIHRoYXQgdGhlIOKAnG5l
dyB2ZXJzaW9uIGlzIHBvc3RlZOKAnSBsYW5ndWFnZSBzaG91bGQgYmUgY2xhcmlmaWVkIGluIHRo
ZSBkaXJlY3Rpb24gKGZvciBJRVRGIFlBTkcpIG9mIOKAnElEIGJlY29tZXMgUkZD4oCdLiBUaGF0
4oCZcyBub3QgaG93IEkgcmVhZCB0aGUgb3JpZ2luYWwgb3IgaG93IEkgcmVhZCBtb3N0IG9mIHRo
ZSBkaXNjdXNzaW9uLCBhbmQgaXTigJlzIGFsc28gbm90IHRoZSBjbGFyaWZpY2F0aW9uIHRoYXQg
SSB3YXMgaG9waW5nIGZvciENCiAgICANCiAgICBSZWdhcmRsZXNzIG9mIHRoZSBkaXNjdXNzaW9u
IGFib3V0IOKAnHB1Ymxpc2hlZOKAnSwgb3RoZXIgb3JnYW5pc2F0aW9ucyBtYXkgYmUgcGxhbm5p
bmcgdG8gdXNlIFlBTkcgbW9kdWxlcyB0aGF0IGFyZSBjdXJyZW50bHkgd2l0aGluIElEcy4gT2J2
aW91c2x5IGl04oCZcyB2YXN0bHkgcHJlZmVyYWJsZSBpZiBzdWNoIElEcyBiZWNvbWUgUkZDcyBi
ZWZvcmUgdGhlc2Ugb3RoZXIgb3JnYW5pc2F0aW9ucyBwdWJsaXNoIGFueSBzcGVjaWZpY2F0aW9u
cyBvciBkYXRhIG1vZGVscyB0aGF0IHVzZSBzdWNoIGRyYWZ0IElFVEYgWUFORywgYnV0IGl0IG1p
Z2h0IG9jY2FzaW9uYWxseSBiZSBuZWNlc3NhcnkgdG8gcmVmZXJlbmNlIGEgZHJhZnQgbW9kZWwg
KGhvcGVmdWxseSBvbmUgdGhhdCBoYXMgYWxyZWFkeSBiZWVuIHNlbnQgZm9yIEFEIHJldmlldykg
aW4gYSBwdWJsaXNoZWQgc3RhbmRhcmQuIFRoaXMgaXMgd2h5IEkgd291bGQgbGlrZSB0aGUgY2xh
cmlmaWNhdGlvbiB0byBjb3ZlciBJRHMgKGF0IGxlYXN0IFdHLWFkb3B0ZWQgb25lcykhDQogICAg
DQogICAgVGhhbmtzLA0KICAgIFdpbGxpYW0NCiAgICANCiAgICA+IE9uIDE1IEF1ZyAyMDE2LCBh
dCAyMDo0MCwgS2VudCBXYXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KICAgID4g
DQogICAgPiBOaXRzOg0KICAgID4gDQogICAgPiAxLiBGaXJzdCBpdCBzYXlzIOKAnHVucHVibGlz
aGVk4oCdIHRoZW4gaXQgc2F5cyDigJxwb3N0ZWTigJ0sIEkgdGhpbmsgaXQgYmV0dGVyIHRvIHJl
cGxhY2UgdGhlIGxhdHRlciB3aXRoIOKAnHB1Ymxpc2hlZOKAnSBzbyB0aGUgdGVybXMgYXJlIGNv
bnNpc3RlbnQuDQogICAgPiANCiAgICA+IDIuIOKAnHVucHVibGlzaGVk4oCdIGlzIHVuY2xlYXIu
ICBBdCBsZWFzdCBJIGNvbnNpZGVyIHN1Ym1pdHRpbmcgYW4gSS1EIHRvIGRhdGF0cmFja2VyIGFz
IGEgZm9ybSBvZiBwdWJsaXNoaW5nLiAgSSB0aGluayBpdCBtaWdodCBiZSBiZXR0ZXIgaGVyZSB0
byByZWZlciB0byBzb21ldGhpbmcgbGlrZSDigJx3b3JrcyBpbiBwcm9ncmVzc+KAnS4NCiAgICA+
IA0KICAgID4gMy4gSW5zdGVhZCBvZiBzYXlpbmcg4oCcd2hlbiBhIG5ldyB2ZXJzaW9uIChvZiB0
aGUgSS1EKSBpcyBwb3N0ZWTigJ0sIGl0IHdvdWxkIGJlIGNsZWFyZXIgdG8gc2F5IOKAnHdoZW4g
YSBuZXcgdmVyc2lvbiBpcyBwb3N0ZWQgKGUuZy4sIGl0IGJlY29tZXMgYW4gUkZDKeKAnS4NCiAg
ICA+IA0KICAgID4gS2VudCAgLy8gYXMgYSBjb250cmlidXRvcg0KICAgID4gDQogICAgPiANCiAg
ICA+IA0KICAgID4gDQogICAgPiBPbiA4LzE1LzE2LCAzOjE3IFBNLCAibmV0bW9kIG9uIGJlaGFs
ZiBvZiBSYW5keSBQcmVzdWhuIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmcgb24gYmVoYWxmIG9m
IHJhbmR5X3ByZXN1aG5AYWx1bW5pLnN0YW5mb3JkLmVkdT4gd3JvdGU6DQogICAgPiANCiAgICA+
ICAgIEhpIC0NCiAgICA+IA0KICAgID4gICAgVGhpcyBhbHNvIHdvcmtzIGZvciBtZSwgYnV0IEkn
ZCByZXBsYWNlIHRoZSBvZGQgIk1BWSIgd2l0aCB0aGUgd29yZCAibmVlZCIuDQogICAgPiANCiAg
ICA+ICAgIChUaGUgc2VtYW50aWNzIG9mICJvbmx5IiBhbmQgb2YgIk1BWSIgZG9uJ3QgcXVpdGUg
bWVzaC4pDQogICAgPiANCiAgICA+ICAgIFJhbmR5DQogICAgPiANCiAgICA+ICAgIE9uIDgvMTUv
MjAxNiA0OjQ0IEFNLCBMYWRpc2xhdiBMaG90a2Egd3JvdGU6DQogICAgPj4+IE9uIDE1IEF1ZyAy
MDE2LCBhdCAxMzozMSwgV2lsbGlhbSBMdXB0b24gPHdsdXB0b25AYnJvYWRiYW5kLWZvcnVtLm9y
Zz4gd3JvdGU6DQogICAgPj4+IA0KICAgID4+PiBBaCEgUmUtcmVhZGluZyBpdCBJIHRoaW5rIHRo
YXQgeW91IGFyZSBjb3JyZWN0LiBJbiB0aGlzIHNwaXJpdCBJIHByb3Bvc2UgdGhlIGNoYW5nZSBz
aG93biBiZWxvdy4gSSBiZWxpZXZlIHRoYXQgYWxsIHRoaXMgZG9lcyBpcyAoYSkgZ2VuZXJhbGlz
ZSwgYW5kIChiKSBjbGFyaWZ5LiBJIGRvbuKAmXQgYmVsaWV2ZSB0aGF0IGl0IGNoYW5nZXMgdGhl
IGludGVuZGVkIG1lYW5pbmcuDQogICAgPj4+IA0KICAgID4+PiBPTEQ6DQogICAgPj4+IA0KICAg
ID4+PiBJdCBpcyBhY2NlcHRhYmxlIHRvIHJldXNlIHRoZSBzYW1lIHJldmlzaW9uIHN0YXRlbWVu
dCB3aXRoaW4gdW5wdWJsaXNoZWQgdmVyc2lvbnMgKGkuZS4sIEludGVybmV0LURyYWZ0cyksIGJ1
dCB0aGUgcmV2aXNpb24gZGF0ZSBNVVNUIGJlIHVwZGF0ZWQgdG8gYSBoaWdoZXIgdmFsdWUgZWFj
aCB0aW1lIHRoZSBJbnRlcm5ldC1EcmFmdCBpcyByZS1wb3N0ZWQuDQogICAgPj4+IA0KICAgID4+
PiBORVc6DQogICAgPj4+IA0KICAgID4+PiBJdCBpcyBhY2NlcHRhYmxlIHRvIHJldXNlIHRoZSBz
YW1lIHJldmlzaW9uIHN0YXRlbWVudCB3aXRoaW4gdW5wdWJsaXNoZWQgdmVyc2lvbnMgKGUuZy4s
IEludGVybmV0LURyYWZ0cyksIGJ1dCB0aGUgcmV2aXNpb24gZGF0ZSAoaS5lLiwgdGhlIHJldmlz
aW9uIHN0YXRlbWVudOKAmXMgYXJndW1lbnQpIE1VU1QgYmUgdXBkYXRlZCB0byBhIGhpZ2hlciB2
YWx1ZSBlYWNoIHRpbWUgYSBuZXcgdmVyc2lvbiAoZS5nLiwgb2YgdGhlIEludGVybmV0LURyYWZ0
KSBpcyBwb3N0ZWQuDQogICAgPj4gSXQgc2VlbXMgc3RyYW5nZSB0byB0YWxrIGFib3V0IHJldXNp
bmcgdGhlIHJldmlzaW9uIHN0YXRlbWVudCBhbmQsIGluIHRoZSBzYW1lIHNlbnRlbmNlLCByZXF1
aXJlIHRvIGNoYW5nZSBpdHMgYXJndW1lbnQuIFdoYXQgYWJvdXQgdGhpczoNCiAgICA+PiANCiAg
ICA+PiBORVcNCiAgICA+PiANCiAgICA+PiBJdCBpcyBub3QgcmVxdWlyZWQgdG8ga2VlcCB0aGUg
cmV2aXNpb24gaGlzdG9yeSBvZiB1bnB1Ymxpc2hlZCB2ZXJzaW9ucyAoZS5nLiwgSW50ZXJuZXQt
RHJhZnRzKS4gVGhhdCBpcywgd2l0aGluIGEgc2VxdWVuY2Ugb2YgdW5wdWJsaXNoZWQgdmVyc2lv
bnMsIG9ubHkgdGhlIG1vc3QgcmVjZW50IHJldmlzaW9uIE1BWSBiZSByZWNvcmRlZCBpbiB0aGUg
bW9kdWxlIG9yIHN1Ym1vZHVsZS4gSG93ZXZlciwgdGhlIHJldmlzaW9uIGRhdGUgb2YgdGhlIG1v
c3QgcmVjZW50IHJldmlzaW9uIE1VU1QgYmUgdXBkYXRlZCB0byBhIGhpZ2hlciB2YWx1ZSBlYWNo
IHRpbWUgYSBuZXcgdmVyc2lvbiAoZS5nLiwgb2YgdGhlIEludGVybmV0LURyYWZ0KSBpcyBwb3N0
ZWQuDQogICAgPj4gDQogICAgPj4gTGFkYQ0KICAgID4+IA0KICAgID4+PiDigJTigJQNCiAgICA+
Pj4gDQogICAgPj4+IENvbW1lbnRzPw0KICAgID4+PiANCiAgICA+Pj4+IE9uIDExIEF1ZyAyMDE2
LCBhdCAxNzoyNiwgUmFuZHkgUHJlc3VobiA8cmFuZHlfcHJlc3VobkBhbHVtbmkuc3RhbmZvcmQu
ZWR1PiB3cm90ZToNCiAgICA+Pj4+IA0KICAgID4+Pj4gSGkgLQ0KICAgID4+Pj4gDQogICAgPj4+
PiBJIHJlYWQgdGhlIHRleHQgYXMgaW50ZW5kZWQgdG8gbWFrZSBhIGRpc3RpbmN0aW9uIGJldHdl
ZW4gdGhlICpkYXRlKiBwb3J0aW9uIGFuZCB0aGUgcmVzdA0KICAgID4+Pj4gDQogICAgPj4+PiBv
ZiB0aGUgcmV2aXNpb24gc3RhdGVtZW50LiAgV2hlbiBhIG1vZHVsZSBpcyB1bmRlciBkZXZlbG9w
bWVudCwgcmV0YWluaW5nIGEgaGlzdG9yeQ0KICAgID4+Pj4gDQogICAgPj4+PiBvZiBzcGVjaWZp
YyBpbmNyZW1lbnRhbCBjaGFuZ2VzIGlzbid0IHRlcnJpYmx5IGhlbHBmdWwsIGJ1dCBjaGFuZ2lu
ZyB0aGUgZGF0ZSBpcyBlc3NlbnRpYWwNCiAgICA+Pj4+IA0KICAgID4+Pj4gdG8gaGVscGluZyB0
b29scyBkZWNpZGUgYW1vbmcgdGhlIHZlcnNpb25zIGZsb2F0aW5nIGFyb3VuZCBpbiB0aGUgbGFi
Lg0KICAgID4+Pj4gDQogICAgPj4+PiANCiAgICA+Pj4+IFJhbmR5IChleHBlcmltZW50aW5nIHdp
dGggbWFpbCByZWFkZXJzLCBwbGVhc2UgZm9yZ2l2ZSBmb3JtYXR0aW5nIGFub21hbGllcykNCiAg
ICA+Pj4+IA0KICAgID4+Pj4gDQogICAgPj4+PiBPbiA4LzExLzIwMTYgOToxNyBBTSwgV2lsbGlh
bSBMdXB0b24gd3JvdGU6DQogICAgPj4+Pj4gVGhhbmtzLiBlLmcgcmF0aGVyIHRoYW4gaS5lIHNv
dW5kcyBnb29kLCBCVVQgbXkgcG9pbnQgKHNvcnJ5IGlmIHRoYXQgd2FzbuKAmXQgY2xlYXIpIGlz
IHRoYXQgdGhpcyBzZW50ZW5jZSBzZWVtcyB0byBiZSBjb250cmFkaWN0b3J5LiBJdCBzYXlzOg0K
ICAgID4+Pj4+IA0KICAgID4+Pj4+IDEuIFVucHVibGlzaGVkIHZlcnNpb25zLCBpLmUgSURzLCBj
YW4gcmV1c2UgcmV2aXNpb24gc3RhdGVtZW50cy4NCiAgICA+Pj4+PiAyLiBJRHMgTVVTVCB1cGRh
dGUgdGhlaXIgcmV2aXNpb24gZGF0ZXMgZWFjaCB0aW1lIHRoZXkgYXJlIHJlLXBvc3RlZC4NCiAg
ICA+Pj4+PiANCiAgICA+Pj4+PiBNeSBzdWdnZXN0aW9uIG9mIHJlbW92aW5nIHRoZSBwYXJlbnRo
ZXNpc2VkIHRleHQgd2FzIHRvIHJlbW92ZSB0aGlzIGNvbnRyYWRpY3Rpb24uIFJpZ2h0IG5vdyBJ
4oCZbSBub3QgY2xlYXIgdGhhdCBJIGNhbiByZWx5IG9uIHJldmlzaW9uIGRhdGVzIGluIFlBTkcg
bW9kdWxlcyBjb250YWluZWQgd2l0aGluIElEcy4NCiAgICA+Pj4+PiANCiAgICA+Pj4+PiBXaWxs
aWFtDQogICAgPj4+Pj4gDQogICAgPj4+Pj4gUFMsIEkgdGhpbmsgdGhhdCB0aGUgcmVtb3ZhbCBv
ZiB0aGlzIHRleHQgcmVtb3ZlcyB0aGUgY29udHJhZGljdGlvbiBiZWNhdXNlIGluIG9yZGVyIHRv
IG1ha2Ugc2Vuc2Ugb2YgdGhlIHNlbnRlbmNlIHRoZSByZWFkZXIgd2lsbCBiZSBmb3JjZWQgdG8g
dGhlIGNvbmNsdXNpb24gdGhhdCBJRHMgYXJlIG5vdCByZWdhcmRlZCBhcyBiZWluZyDigJx1bnB1
Ymxpc2hlZOKAnS4NCiAgICA+Pj4+PiANCiAgICA+Pj4+Pj4gT24gMTEgQXVnIDIwMTYsIGF0IDE3
OjA3LCBSYW5keSBQcmVzdWhuIDxyYW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5lZHUgPG1h
aWx0bzpyYW5keV9wcmVzdWhuQGFsdW1uaS5zdGFuZm9yZC5lZHU+PiB3cm90ZToNCiAgICA+Pj4+
Pj4gDQogICAgPj4+Pj4+IEhpIC0NCiAgICA+Pj4+Pj4gDQogICAgPj4+Pj4+IFRoZSBzaXR1YXRp
b24gd2l0aCBJbnRlcm5ldC1EcmFmdHMgaXMgd2hhdCBtb3RpdmF0ZWQgdGhpcyB0ZXh0IGluIHRo
ZSBmaXJzdCBwbGFjZSwgc28NCiAgICA+Pj4+Pj4gSSB0aGluayBpdCBpcyBpbXBvcnRhbnQgdG8g
cmV0YWluIHRoYXQgaW5mb3JtYXRpb24uICBIb3dldmVyLCBpdCBzZWVtcyB0byBtZSB0aGF0DQog
ICAgPj4+Pj4+IHRoZSAiaS5lLiIgaXMgdG9vIGxpbWl0aW5nLCBhbmQgc2hvdWxkIGJlIHJlcGxh
Y2VkIHdpdGggYW4gImUuZy4iLg0KICAgID4+Pj4+PiANCiAgICA+Pj4+Pj4gUmFuZHkNCiAgICA+
Pj4+Pj4gDQogICAgPj4+Pj4+IE9uIDgvMTEvMjAxNiAyOjA2IEFNLCBXaWxsaWFtIEx1cHRvbiB3
cm90ZToNCiAgICA+Pj4+Pj4+IEFsbCwNCiAgICA+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4gVGhlIHRl
eHQgYXQgdGhlIGJvdHRvbSBvZiBSRkMgNjA4N2JpcyAoZHJhZnQgMDcpIFNlY3Rpb24gNS44IHNl
ZW1zIHVuY2xlYXI6DQogICAgPj4+Pj4+PiANCiAgICA+Pj4+Pj4+ICJJdCBpcyBhY2NlcHRhYmxl
IHRvIHJldXNlIHRoZSBzYW1lIHJldmlzaW9uIHN0YXRlbWVudCB3aXRoaW4gdW5wdWJsaXNoZWQg
dmVyc2lvbnMgKGkuZS4sIEludGVybmV0LURyYWZ0cyksIGJ1dCB0aGUgcmV2aXNpb24gZGF0ZSBN
VVNUIGJlIHVwZGF0ZWQgdG8gYSBoaWdoZXIgdmFsdWUgZWFjaCB0aW1lIHRoZSBJbnRlcm5ldC1E
cmFmdCBpcyByZS1wb3N0ZWTigJ0NCiAgICA+Pj4+Pj4+IA0KICAgID4+Pj4+Pj4gQXNzdW1pbmcg
dGhhdCB0aGUgaW50ZW50IGlzIHRoYXQgdGhlIHJldmlzaW9uIHN0YXRlbWVudHMgaW4gWUFORyBt
b2RlbHMgY29udGFpbmVkIHdpdGhpbiBJRHMgbXVzdCBiZSB1cGRhdGVkIHdoZW5ldmVyIHRoZSBt
b2RlbHMgYXJlIHVwZGF0ZWQsICB3b3VsZG7igJl0IGl0IGJlIGNsZWFyZXIgaWYgdGhlIHBhcmVu
dGhlc2lzZWQgdGV4dCAiKGkuZS4sIEludGVybmV0LURyYWZ0cynigJ0gd2FzIGRlbGV0ZWQ/DQog
ICAgPj4+Pj4+PiANCiAgICA+Pj4+Pj4+IFRoYW5rcywNCiAgICA+Pj4+Pj4+IFdpbGxpYW0NCiAg
ICA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg
ICA+Pj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgID4+PiBuZXRtb2RAaWV0Zi5vcmcNCiAgICA+
Pj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+PiAt
LQ0KICAgID4+IExhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCiAgICA+PiBQR1AgS2V5IElE
OiBFNzRFOEMwQw0KICAgID4+IA0KICAgID4+IA0KICAgID4+IA0KICAgID4+IA0KICAgID4gDQog
ICAgPiANCiAgICA+ICAgIC0tLQ0KICAgID4gICAgVGhpcyBlbWFpbCBoYXMgYmVlbiBjaGVja2Vk
IGZvciB2aXJ1c2VzIGJ5IEF2YXN0IGFudGl2aXJ1cyBzb2Z0d2FyZS4NCiAgICA+ICAgIGh0dHBz
Oi8vd3d3LmF2YXN0LmNvbS9hbnRpdmlydXMNCiAgICA+IA0KICAgID4gICAgX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+ICAgIG5ldG1vZCBtYWls
aW5nIGxpc3QNCiAgICA+ICAgIG5ldG1vZEBpZXRmLm9yZw0KICAgID4gICAgaHR0cHM6Ly93d3cu
aWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+IA0KICAgID4gDQogICAgPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gbmV0
bW9kIG1haWxpbmcgbGlzdA0KICAgID4gbmV0bW9kQGlldGYub3JnDQogICAgPiBodHRwczovL3d3
dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZA0KICAgIA0KICAgIA0KDQo=


From nobody Tue Aug 16 20:30: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 B23C912D10E for ; Tue, 16 Aug 2016 20:29:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id iyRSC7kpB-60 for ; Tue, 16 Aug 2016 20:29:58 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 E7E6312B005 for ; Tue, 16 Aug 2016 20:29:57 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id 74so153816794uau.0 for ; Tue, 16 Aug 2016 20:29:57 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=HWJ4a0g9LQz2svEnQgURo1NLsJDMxeDm4ye54OEgiT8=; b=nEPlNmZ9n3MZvR4vzVAgmYRQSwH640b9+XtX+xqvSiS1YGaGzWAfY024qIXJxTSW0T EEXQZz1nBiLOGJ6HX7DOmtNrJR2cU+JWYA/XVoI+tYd7uZ1J0PTFa3i48ZXBGT23nAih 36/1vHMfGFvD9UFaYHD8agn2TNZ3OoW9+EpQ1v+7PcKWdcZPgklAkCZQOdT4dNPD4GoP R3xGHIZwN4a7UowrxmRfhDuNLlqJHV46cnasGnEz+wJVOrh1GIRAWc4KTk50hsu+rpvF ZWYJCkbmhodua5GslbGkW+AM7qq5/7SZCIDXgMEO/h9tgYtinj0IfMxwUBLAmh4fhwbV rP6w==
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:from:date :message-id:subject:to:cc; bh=HWJ4a0g9LQz2svEnQgURo1NLsJDMxeDm4ye54OEgiT8=; b=iZkYm5qgNMKEdktb01qXYbeqnb6r89mrmplvb6ybcRqm4ktbyaZyRPQ6LXaCg0vdXx 0eL12wK8VJ4gr7VzTUUbFfNiT1PBF4jJ81ggah0uTh+jgMUxlIfe5fR1PVczaLAXND4H 4n79Z8CtbzXEKiZi6VEkoQu7+F6Na3jwOnU6ZsLmv7PCDBzTtZI21wxT47vRGIhkaPvi etYyMfy5PsYKfPM7kNPEoSGZJVsCrsookyHBv9WTAsj4MtoTciUW4mgn3caRdjV6LKtt 478kpV6Ch1lD45Hrt4JOSEIQWASCfKtJaIvbVZxiZIVysJFOVjPcqBMSUZUXXlYjNvIu Tcog==
X-Gm-Message-State: AEkoouuQ2Md1t+g6hOvzh6mFQbDSCYQ0srvbzTXyb2NiiPrDLCdwsARBZpaGfxnMfjAxcfj0EunON6qLm/2rGg==
X-Received: by 10.31.9.67 with SMTP id 64mr18139183vkj.89.1471404596942; Tue, 16 Aug 2016 20:29:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Tue, 16 Aug 2016 20:29:56 -0700 (PDT)
In-Reply-To: 
References: <76f5738b-f973-94e3-6db4-da68ab5ec0c8@cesnet.cz> <20160816.143658.158624020963729615.mbj@tail-f.com> <5ecf4a8c-5b27-e3f6-6c88-0d5fbb1e4866@cesnet.cz> 
From: Andy Bierman 
Date: Tue, 16 Aug 2016 20:29:56 -0700
Message-ID: 
To: Ladislav Lhotka 
Content-Type: multipart/alternative; boundary=001a11440ef45273dc053a3c1428
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] clarification of default values in leaf-list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Aug 2016 03:30:00 -0000

--001a11440ef45273dc053a3c1428
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Tue, Aug 16, 2016 at 8:25 AM, Ladislav Lhotka  wrote:

>
> > On 16 Aug 2016, at 14:54, Radek Krej=C4=8D=C3=AD  wr=
ote:
> >
> > Dne 16.8.2016 v 14:36 Martin Bjorklund napsal(a):
> >> Radek Krej=C4=8D=C3=AD  wrote:
> >>> Hi all,
> >>> I'm not sure what is actually the default value in leaf-list if there
> >>> are multiple default statements.  Is it each of the values defined as
> >>> default or the set of default values together? My point is, in case o=
f
> >>> NETCONF with-defaults capability, when the leaf-list instance is
> >>> supposed to be marked as default (report-all-tagged retrieval mode) -
> >>> when it contains one of the values defined as default or only when
> >>> there is a complete set of default values (and in case of user-ordere=
d
> >>> leaf-list, when they are in correct order)?
> >>
> >> 6020bis says:
> >>
> >>  If a leaf-list has one or more "default" statement, the leaf-list's
> >>  default values are the values of the "default" statements, and if the
> >>  leaf-list is user-ordered, the default values are used in the order o=
f
> >>  the "default" statements.
> >>
> >> Doesn't this answer your questions?
> >
> > no, it doesn't - the "leaf-list's default values are" indicates that
> there can be multiple default values for the leaf-list. So each of the
> default statement defines one of the leaf-list's default values. But the
> second part refers to the default values to be used together, as a set. I
> think that it makes better sense to use the leaf-list's default value as =
a
> set, but that first sentence confuses me.
>
> leaf-list foo {
>     type string;
>     default "zig";
>     default "zag";
> }
>
> The default content is the sequence of values taken from all "default"
> statements, i.e. in JSON encoding it is
>
> "foo": ["zig", "zag"]
>
>
Or the server could return ["zag", "zig"] because this is an ordered-by
system leaf-list.

Let's say the client sets foo to the value "zag".
If the server basic-mode=3Dexplicit, then foo =3D [ "zag" ] and foo is not =
a
default.
But if the basic-mode=3Dtrim, then there was no node created, so foo is sti=
ll
a default ["zig", "zag"].

Is this correct? What matches the YANG default for this node in
with-defaults trim mode?

1)
   ["zig", "zag"]

2)
   ["zig"] and ["zag"]



Andy







> Lada
>
> >
> > Radek
> >
> >>
> >> /martin
> >
> >
> > _______________________________________________
> > 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
>

--001a11440ef45273dc053a3c1428
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Tue, Aug 16, 2016 at 8:25 AM, Ladislav Lhotka <=
lhotka@nic.cz> wrote:


> On 16 Aug 2016, at 14:54, Radek Krej=C4=8D=C3=AD <rkrejci@cesnet.cz> wrote:

>

> Dne 16.8.2016 v 14:36 Martin Bjorklund napsal(a):

>> Radek Krej=C4=8D=C3=AD <rk=
rejci@cesnet.cz> wrote:

>>> Hi all,

>>> I'm not sure what is actually the default value in leaf-li=
st if there

>>> are multiple default statements.=C2=A0 Is it each of the value=
s defined as

>>> default or the set of default values together? My point is, in=
 case of

>>> NETCONF with-defaults capability, when the leaf-list instance =
is

>>> supposed to be marked as default (report-all-tagged retrieval =
mode) -

>>> when it contains one of the values defined as default or only =
when

>>> there is a complete set of default values (and in case of user=
-ordered

>>> leaf-list, when they are in correct order)?

>>

>> 6020bis says:

>>

>>=C2=A0 If a leaf-list has one or more "default" statement=
, the leaf-list's

>>=C2=A0 default values are the values of the "default" sta=
tements, and if the

>>=C2=A0 leaf-list is user-ordered, the default values are used in th=
e order of

>>=C2=A0 the "default" statements.

>>

>> Doesn't this answer your questions?

>

> no, it doesn't - the "leaf-list's default values are"=
; indicates that there can be multiple default values for the leaf-list. So=
 each of the default statement defines one of the leaf-list's default v=
alues. But the second part refers to the default values to be used together=
, as a set. I think that it makes better sense to use the leaf-list's d=
efault value as a set, but that first sentence confuses me.



leaf-list foo {

=C2=A0 =C2=A0 type string;

=C2=A0 =C2=A0 default "zig";

=C2=A0 =C2=A0 default "zag";

}



The default content is the sequence of values taken from all "default&=
quot; statements, i.e. in JSON encoding it is



"foo": ["zig", "zag"]



Or the server could return ["zag&=
quot;, "zig"] because this is an ordered-by system leaf-list.

Let's say the client sets foo to the value "=
zag".
If the server basic-mode=3Dexplicit, then foo =3D [ &q=
uot;zag" ] and foo is not a default.
But if the basic-mode=
=3Dtrim, then there was no node created, so foo is still
a defaul=
t ["zig", "zag"].

Is this corr=
ect? What matches the YANG default for this node in with-defaults trim mode=
?

1)
=C2=A0 =C2=A0["zig", &quo=
t;zag"]

2)
=C2=A0 =C2=A0["zig&=
quot;] and ["zag"]
=C2=A0


=

Andy




=


=C2=A0

Lada



>

> Radek

>

>>

>> /martin

>

>

> _______________________________________________

> 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




--001a11440ef45273dc053a3c1428--


From nobody Tue Aug 16 23:21: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 B168E12B043 for ; Tue, 16 Aug 2016 23:21:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 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=-1.247] 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 C-rdQN8FbDvX for ; Tue, 16 Aug 2016 23:21:32 -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 74BA3127077 for ; Tue, 16 Aug 2016 23:21:32 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9560:5d13:3f9e:910c] (unknown [IPv6:2001:718:1a02:1:9560:5d13:3f9e:910c]) by mail.nic.cz (Postfix) with ESMTPSA id 4F04B60B6E; Wed, 17 Aug 2016 08:21:30 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471414890; bh=OhGtGfHrGAVWKT3ixWPckpodWKlh5LM824ewAInvdtk=; h=From:Date:To; b=pgk3g7WG9OrKIgNEjsAFokDgaiDdvYOvNvPdJgwqmVsrRrE5/c05iS6uUAJPhRAzk JFfM5YyThHG3KwZLXG6qsnlKqoTCDFB05+yjGsTWMU2F6yu/YEjsHrqGNJ7RS2eVYu zXsYhzgJsKnb7Wstmv5NNK9DLY7P71licQ+px/lk=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 17 Aug 2016 08:21:34 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <440CC84C-5506-4EBC-8585-55589D184FEE@nic.cz>
References: <76f5738b-f973-94e3-6db4-da68ab5ec0c8@cesnet.cz> <20160816.143658.158624020963729615.mbj@tail-f.com> <5ecf4a8c-5b27-e3f6-6c88-0d5fbb1e4866@cesnet.cz>  
To: Andy Bierman 
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] clarification of default values in leaf-list
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Aug 2016 06:21:35 -0000

> On 17 Aug 2016, at 05:29, Andy Bierman  wrote:
>=20
>=20
>=20
> On Tue, Aug 16, 2016 at 8:25 AM, Ladislav Lhotka  =
wrote:
>=20
> > On 16 Aug 2016, at 14:54, Radek Krej=C4=8D=C3=AD  =
wrote:
> >
> > Dne 16.8.2016 v 14:36 Martin Bjorklund napsal(a):
> >> Radek Krej=C4=8D=C3=AD  wrote:
> >>> Hi all,
> >>> I'm not sure what is actually the default value in leaf-list if =
there
> >>> are multiple default statements.  Is it each of the values defined =
as
> >>> default or the set of default values together? My point is, in =
case of
> >>> NETCONF with-defaults capability, when the leaf-list instance is
> >>> supposed to be marked as default (report-all-tagged retrieval =
mode) -
> >>> when it contains one of the values defined as default or only when
> >>> there is a complete set of default values (and in case of =
user-ordered
> >>> leaf-list, when they are in correct order)?
> >>
> >> 6020bis says:
> >>
> >>  If a leaf-list has one or more "default" statement, the =
leaf-list's
> >>  default values are the values of the "default" statements, and if =
the
> >>  leaf-list is user-ordered, the default values are used in the =
order of
> >>  the "default" statements.
> >>
> >> Doesn't this answer your questions?
> >
> > no, it doesn't - the "leaf-list's default values are" indicates that =
there can be multiple default values for the leaf-list. So each of the =
default statement defines one of the leaf-list's default values. But the =
second part refers to the default values to be used together, as a set. =
I think that it makes better sense to use the leaf-list's default value =
as a set, but that first sentence confuses me.
>=20
> leaf-list foo {
>     type string;
>     default "zig";
>     default "zag";
> }
>=20
> The default content is the sequence of values taken from all "default" =
statements, i.e. in JSON encoding it is
>=20
> "foo": ["zig", "zag"]
>=20
>=20
> Or the server could return ["zag", "zig"] because this is an =
ordered-by system leaf-list.

Yes.

>=20
> Let's say the client sets foo to the value "zag".
> If the server basic-mode=3Dexplicit, then foo =3D [ "zag" ] and foo is =
not a default.
> But if the basic-mode=3Dtrim, then there was no node created, so foo =
is still
> a default ["zig", "zag"].
>=20
> Is this correct? What matches the YANG default for this node in =
with-defaults trim mode?

This is not how I understand it - the default value should be the list =
en bloc, so if the client sets the value to "zag", the default should be =
always replaced by the new value ["zag"], which is different from =
["zig", "zag"].

But: when we say "client sets", does the edit operation matter? If it is =
"merge", should the new value be ["zig", "zag"] (=3D the original =
default content merged with the new value)?

Lada

>=20
> 1)
>    ["zig", "zag"]
>=20
> 2)
>    ["zig"] and ["zag"]
> =20
>=20
>=20
> Andy
>=20
>=20
>=20
>=20
>=20
> =20
> Lada
>=20
> >
> > Radek
> >
> >>
> >> /martin
> >
> >
> > _______________________________________________
> > 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

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





From nobody Wed Aug 17 05:35: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 AB71512D738 for ; Wed, 17 Aug 2016 05:35:48 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 9biSiZyzouoO for ; Wed, 17 Aug 2016 05:35:47 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DEB3112D73A for ; Wed, 17 Aug 2016 05:35:46 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 1690C1AE03CA; Wed, 17 Aug 2016 14:35:44 +0200 (CEST)
Date: Wed, 17 Aug 2016 14:34:48 +0200 (CEST)
Message-Id: <20160817.143448.390340936867222304.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: <04F63698-5EA2-4A75-81EF-62BB5DCC2DC6@nic.cz>
References:  <57FC9BC0-DAC4-4671-AB6D-D45B6D1E7710@broadband-forum.org> <04F63698-5EA2-4A75-81EF-62BB5DCC2DC6@nic.cz>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1: XML naming restriction
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Aug 2016 12:35:49 -0000

Ladislav Lhotka  wrote:
> 
> > On 01 Aug 2016, at 10:15, William Lupton 
> > wrote:
> > 
> > But the errata at https://www.w3.org/XML/xml-V10-5e-errata say the
> > following. There are also related changes to Section 2.6 (processing
> > instructions) and Section 3 (logical structures). W.
> > Section 2.3 Common Syntactic Constructs
> > Delete the following paragraph:
> > 
> > Names beginning with the string "xml", or with any string which would
> > match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
> > standardization in this or future versions of this specification.
> 
> Good catch!

Indeed!

> What this erratum means for YANG is that only "xml" prefix
> needs to be forbidden.

Actually, as Dale Worley pointed out, not even this is required, since
the prefix is not required to be used in the XML encoding.

I suggest we simply remove the line:

;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))

The document is now in AUTH48 so we can actually make this change.

Juergen, and/or Benoit, do you think we can make this change to the
document?  If we do, we should also mention this in section 1.1.


Eventually the type yang-identifier from RFC 6991 should be revised as
well.


/martin



> 
> If it is still possible, it would IMO make a good sense to remove that
> comment from the ABNF in 6020bis, and make this change in sec. 7.1.4:
> 
> OLD
> 
>    A prefix is an identifier (see Section 6.2).
> 
> NEW
> 
>    A prefix is an identifier (see Section 6.2), and it MUST NOT be the
>    string "xml".
> 
> Lada 
> 
> > 
> >> On 1 Aug 2016, at 04:22, Andy Bierman  wrote:
> >> 
> >> 
> >> OK -- sorry -- must have read it wrong
> >> 
> >> 
> >> Andy
> >> 
> >> 
> >> 
> >> On Sun, Jul 31, 2016 at 6:57 PM, Dale R. Worley 
> >> wrote:
> >> Andy Bierman  writes:
> >> > The YANG 1.1 ABNF says:
> >> >
> >> >    ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
> >> >    identifier          = (ALPHA / "_")
> >> >                          *(ALPHA / DIGIT / "_" / "-" / ".")
> >> >
> >> >
> >> > There is no explanation given why.
> >> > The same restriction was copied to RESTCONF, also without explanation.
> >> > Supposedly, XML does not allow identifiers to start with XML.
> >> >
> >> > Looks like this restriction only applies to the PITarget [17], not
> >> > Name [5]
> >> > https://www.w3.org/TR/REC-xml/#sec-pi
> >> >
> >> > We have been applying this restriction to element names
> >> > but it only applies to processing instructions.
> >> >
> >> > IMO it should be removed.
> >> > It confuses people when they get an error for naming a data node
> >> > with a string that matches.
> >> 
> >> Eh?  Looking at "Extensible Markup Lanuage (XML) 1.0 (Fifth Edition)",
> >> section 3.1 (http://www.w3.org/TR/xml/#sec-starttags) says that the
> >> element name of a start in end tag is a "Name".  Looking at section
> >> 2.3
> >> (http://www.w3.org/TR/xml/#sec-common-syn), I see
> >> 
> >>     Names beginning with the string "xml", or with any string which
> >>     would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
> >>     standardization in this or future versions of this specification.
> >> 
> >> And since Yang data node names can appear as XML element names, Yang
> >> has
> >> to forbid node names that start with "XML".
> >> 
> >> Dale
> >> 
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> --
> 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 Aug 17 05:50: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 8037412D74C for ; Wed, 17 Aug 2016 05:50:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 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=-1.247] 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 QjnFKGWCCdxT for ; Wed, 17 Aug 2016 05:50: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 504D412D671 for ; Wed, 17 Aug 2016 05:50:08 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9560:5d13:3f9e:910c] (unknown [IPv6:2001:718:1a02:1:9560:5d13:3f9e:910c]) by mail.nic.cz (Postfix) with ESMTPSA id D1A3260829; Wed, 17 Aug 2016 14:50:06 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471438206; bh=6hY5xYWvX6IuFVEdjNFe5dgSXqhRwOiFHwjzZPdu4kw=; h=From:Date:To; b=UobMyg3PxJ/lMyn/jFjww4+OO1LFlpUFY2ZRtDOnAPkQ/FhF7zi76AuV4eCTZ647q Nf4BFcMFWwm2s1PR2DjLagiVOGirlLwJ4QqtpBRu8jiBRyHuSuVzY87sSjQPMBAWOB WckfJPmIuX1RGBxNEbICcZPED4amvv2pt93R2rHc=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160817.143448.390340936867222304.mbj@tail-f.com>
Date: Wed, 17 Aug 2016 14:50:11 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References:  <57FC9BC0-DAC4-4671-AB6D-D45B6D1E7710@broadband-forum.org> <04F63698-5EA2-4A75-81EF-62BB5DCC2DC6@nic.cz> <20160817.143448.390340936867222304.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
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] YANG 1.1: XML naming restriction
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Aug 2016 12:50:11 -0000

> On 17 Aug 2016, at 14:34, Martin Bjorklund  wrote:
> 
> Ladislav Lhotka  wrote:
>> 
>>> On 01 Aug 2016, at 10:15, William Lupton 
>>> wrote:
>>> 
>>> But the errata at https://www.w3.org/XML/xml-V10-5e-errata say the
>>> following. There are also related changes to Section 2.6 (processing
>>> instructions) and Section 3 (logical structures). W.
>>> Section 2.3 Common Syntactic Constructs
>>> Delete the following paragraph:
>>> 
>>> Names beginning with the string "xml", or with any string which would
>>> match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
>>> standardization in this or future versions of this specification.
>> 
>> Good catch!
> 
> Indeed!
> 
>> What this erratum means for YANG is that only "xml" prefix
>> needs to be forbidden.
> 
> Actually, as Dale Worley pointed out, not even this is required, since
> the prefix is not required to be used in the XML encoding.
> 
> I suggest we simply remove the line:
> 
> ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))

I agree, good riddance.

Lada

> 
> The document is now in AUTH48 so we can actually make this change.
> 
> Juergen, and/or Benoit, do you think we can make this change to the
> document?  If we do, we should also mention this in section 1.1.
> 
> 
> Eventually the type yang-identifier from RFC 6991 should be revised as
> well.
> 
> 
> /martin
> 
> 
> 
>> 
>> If it is still possible, it would IMO make a good sense to remove that
>> comment from the ABNF in 6020bis, and make this change in sec. 7.1.4:
>> 
>> OLD
>> 
>>   A prefix is an identifier (see Section 6.2).
>> 
>> NEW
>> 
>>   A prefix is an identifier (see Section 6.2), and it MUST NOT be the
>>   string "xml".
>> 
>> Lada 
>> 
>>> 
>>>> On 1 Aug 2016, at 04:22, Andy Bierman  wrote:
>>>> 
>>>> 
>>>> OK -- sorry -- must have read it wrong
>>>> 
>>>> 
>>>> Andy
>>>> 
>>>> 
>>>> 
>>>> On Sun, Jul 31, 2016 at 6:57 PM, Dale R. Worley 
>>>> wrote:
>>>> Andy Bierman  writes:
>>>>> The YANG 1.1 ABNF says:
>>>>> 
>>>>>   ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
>>>>>   identifier          = (ALPHA / "_")
>>>>>                         *(ALPHA / DIGIT / "_" / "-" / ".")
>>>>> 
>>>>> 
>>>>> There is no explanation given why.
>>>>> The same restriction was copied to RESTCONF, also without explanation.
>>>>> Supposedly, XML does not allow identifiers to start with XML.
>>>>> 
>>>>> Looks like this restriction only applies to the PITarget [17], not
>>>>> Name [5]
>>>>> https://www.w3.org/TR/REC-xml/#sec-pi
>>>>> 
>>>>> We have been applying this restriction to element names
>>>>> but it only applies to processing instructions.
>>>>> 
>>>>> IMO it should be removed.
>>>>> It confuses people when they get an error for naming a data node
>>>>> with a string that matches.
>>>> 
>>>> Eh?  Looking at "Extensible Markup Lanuage (XML) 1.0 (Fifth Edition)",
>>>> section 3.1 (http://www.w3.org/TR/xml/#sec-starttags) says that the
>>>> element name of a start in end tag is a "Name".  Looking at section
>>>> 2.3
>>>> (http://www.w3.org/TR/xml/#sec-common-syn), I see
>>>> 
>>>>    Names beginning with the string "xml", or with any string which
>>>>    would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
>>>>    standardization in this or future versions of this specification.
>>>> 
>>>> And since Yang data node names can appear as XML element names, Yang
>>>> has
>>>> to forbid node names that start with "XML".
>>>> 
>>>> Dale
>>>> 
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> 
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>> --
>> 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 Wed Aug 17 06:18: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 A289612D79C for ; Wed, 17 Aug 2016 06:18:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level: 
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OeXF3UuG0jWb for ; Wed, 17 Aug 2016 06:18: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 E6FCF12D688 for ; Wed, 17 Aug 2016 06:18:12 -0700 (PDT)
Received: from jernejthpPC (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 6A0ECC4175C2; Wed, 17 Aug 2016 15:18:07 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si 6A0ECC4175C2
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1471439887; bh=beOsxPGT/7nzHnwR54bMY4nK0RODRwNzTPw/RyAN9YA=; h=From:To:Cc:References:In-Reply-To:Subject:Date:From; b=dbLzLVT2riDMqwC4mzJ0IZbuMhhDvDof8gOqvWe60/hbEW6k828+n5CHZTJHX5zwj q/c2JIsQyrrDwwSe6fhOJjfSWbp4B68bJoKhDMFRrOtoP/XDrEO72a18XiwEhzmTf3 7EPkXx/wQjlaLs6tbItmSa3WzRcuHMd+HmDdvBwif4PzxzJaHHd29GuLiTR9rczxCP vi6m+hlOkIMseBceLwyBlUsXk3BtLwRZfWzCoZoQ5B/ks8l65XfRdEj0oiNbtlzBYL Nc7uU+/BP8otgtrcMmsL+v8E+4u/Snpwy6C38XMUboZO3Bcl06EYm7/VGL7auvkMiX lbiBQl7712cFw==
From: "Jernej Tuljak" 
To: "'Ladislav Lhotka'" , "'Martin Bjorklund'" 
References:  <57FC9BC0-DAC4-4671-AB6D-D45B6D1E7710@broadband-forum.org> <04F63698-5EA2-4A75-81EF-62BB5DCC2DC6@nic.cz> <20160817.143448.390340936867222304.mbj@tail-f.com> 
In-Reply-To: 
Date: Wed, 17 Aug 2016 15:18:04 +0200
Message-ID: <02ab01d1f889$c9a903c0$5cfb0b40$@mg-soft.si>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Content-Language: sl
Thread-Index: AQIbwQ+vgcQmggDOIligex+cv2yF2wHVKvzLAbePXyEClyxyGwJPOcFIn3X1DzA=
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] YANG 1.1: XML naming restriction
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Aug 2016 13:18:15 -0000

Is there a reason for no normative/informative reference to the XML =
specification within the document? XML 1.0 has several editions and =
there's also XML 1.1. The document is quite specific when it comes to =
XSD, XPATH, XSLT, and even XML-NAMES but not XML itself.

Jernej


> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav
> Lhotka
> Sent: Wednesday, August 17, 2016 2:50 PM
> To: Martin Bjorklund 
> Cc: netmod@ietf.org
> Subject: Re: [netmod] YANG 1.1: XML naming restriction
>=20
>=20
> > On 17 Aug 2016, at 14:34, Martin Bjorklund  wrote:
> >
> > Ladislav Lhotka  wrote:
> >>
> >>> On 01 Aug 2016, at 10:15, William Lupton  forum.org>
> >>> wrote:
> >>>
> >>> But the errata at https://www.w3.org/XML/xml-V10-5e-errata say the
> >>> following. There are also related changes to Section 2.6 =
(processing
> >>> instructions) and Section 3 (logical structures). W.
> >>> Section 2.3 Common Syntactic Constructs
> >>> Delete the following paragraph:
> >>>
> >>> Names beginning with the string "xml", or with any string which =
would
> >>> match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
> >>> standardization in this or future versions of this specification.
> >>
> >> Good catch!
> >
> > Indeed!
> >
> >> What this erratum means for YANG is that only "xml" prefix
> >> needs to be forbidden.
> >
> > Actually, as Dale Worley pointed out, not even this is required, =
since
> > the prefix is not required to be used in the XML encoding.
> >
> > I suggest we simply remove the line:
> >
> > ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
>=20
> I agree, good riddance.
>=20
> Lada
>=20
> >
> > The document is now in AUTH48 so we can actually make this change.
> >
> > Juergen, and/or Benoit, do you think we can make this change to the
> > document?  If we do, we should also mention this in section 1.1.
> >
> >
> > Eventually the type yang-identifier from RFC 6991 should be revised =
as
> > well.
> >
> >
> > /martin
> >
> >
> >
> >>
> >> If it is still possible, it would IMO make a good sense to remove =
that
> >> comment from the ABNF in 6020bis, and make this change in sec. =
7.1.4:
> >>
> >> OLD
> >>
> >>   A prefix is an identifier (see Section 6.2).
> >>
> >> NEW
> >>
> >>   A prefix is an identifier (see Section 6.2), and it MUST NOT be =
the
> >>   string "xml".
> >>
> >> Lada
> >>
> >>>
> >>>> On 1 Aug 2016, at 04:22, Andy Bierman 
> wrote:
> >>>>
> >>>>
> >>>> OK -- sorry -- must have read it wrong
> >>>>
> >>>>
> >>>> Andy
> >>>>
> >>>>
> >>>>
> >>>> On Sun, Jul 31, 2016 at 6:57 PM, Dale R. Worley =

> >>>> wrote:
> >>>> Andy Bierman  writes:
> >>>>> The YANG 1.1 ABNF says:
> >>>>>
> >>>>>   ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m')
> ('L'|'l'))
> >>>>>   identifier          =3D (ALPHA / "_")
> >>>>>                         *(ALPHA / DIGIT / "_" / "-" / ".")
> >>>>>
> >>>>>
> >>>>> There is no explanation given why.
> >>>>> The same restriction was copied to RESTCONF, also without
> explanation.
> >>>>> Supposedly, XML does not allow identifiers to start with XML.
> >>>>>
> >>>>> Looks like this restriction only applies to the PITarget [17], =
not
> >>>>> Name [5]
> >>>>> https://www.w3.org/TR/REC-xml/#sec-pi
> >>>>>
> >>>>> We have been applying this restriction to element names
> >>>>> but it only applies to processing instructions.
> >>>>>
> >>>>> IMO it should be removed.
> >>>>> It confuses people when they get an error for naming a data node
> >>>>> with a string that matches.
> >>>>
> >>>> Eh?  Looking at "Extensible Markup Lanuage (XML) 1.0 (Fifth
> Edition)",
> >>>> section 3.1 (http://www.w3.org/TR/xml/#sec-starttags) says that =
the
> >>>> element name of a start in end tag is a "Name".  Looking at =
section
> >>>> 2.3
> >>>> (http://www.w3.org/TR/xml/#sec-common-syn), I see
> >>>>
> >>>>    Names beginning with the string "xml", or with any string =
which
> >>>>    would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
> >>>>    standardization in this or future versions of this =
specification.
> >>>>
> >>>> And since Yang data node names can appear as XML element names,
> Yang
> >>>> has
> >>>> to forbid node names that start with "XML".
> >>>>
> >>>> Dale
> >>>>
> >>>> _______________________________________________
> >>>> netmod mailing list
> >>>> netmod@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> --
> >> 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
>=20
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Wed Aug 17 07:47: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 DDF1012DF09 for ; Wed, 17 Aug 2016 07:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 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=-1.247] 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 QG9NCXUtBds0 for ; Wed, 17 Aug 2016 07:47:42 -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 1ED8D12DF06 for ; Wed, 17 Aug 2016 07:47:42 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:9560:5d13:3f9e:910c] (unknown [IPv6:2001:718:1a02:1:9560:5d13:3f9e:910c]) by mail.nic.cz (Postfix) with ESMTPSA id 8AE7B60B6B; Wed, 17 Aug 2016 16:47:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471445260; bh=ujUMxmWQtIUYvKPYD72FIeMNjhQ/oNQKtP75ORhidIA=; h=From:Date:To; b=q0ZP35U+umXh37EpJC6P4nOtyDkCzUsZftgBKYowJAb23hMm4d5Mvm2UBIfWaQ3vJ Ru5m3y2kh7YDHEbdvBBkGmoFOB2Xbxu3/s0oE4s5DrLYRMWdYyFWECeV/zwovr0IG+ HU+VGZkgbd7HpxlR4NgV4Onbh0yGev6qYGnpuc9A=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <02ab01d1f889$c9a903c0$5cfb0b40$@mg-soft.si>
Date: Wed, 17 Aug 2016 16:47:45 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <47B87D6E-BA0B-4C39-B1FB-9429E04CB20F@nic.cz>
References:  <57FC9BC0-DAC4-4671-AB6D-D45B6D1E7710@broadband-forum.org> <04F63698-5EA2-4A75-81EF-62BB5DCC2DC6@nic.cz> <20160817.143448.390340936867222304.mbj@tail-f.com>  <02ab01d1f889$c9a903c0$5cfb0b40$@mg-soft.si>
To: Jernej Tuljak 
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] YANG 1.1: XML naming restriction
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 17 Aug 2016 14:47:48 -0000

> On 17 Aug 2016, at 15:18, Jernej Tuljak  =
wrote:
>=20
> Is there a reason for no normative/informative reference to the XML =
specification within the document? XML 1.0 has several editions and =
there's also XML 1.1. The document is quite specific when it comes to =
XSD, XPATH, XSLT, and even XML-NAMES but not XML itself.

I tend to agree, and it should be XML 1.0 because the document refers to =
the XML 1.0 version of [XML-NAMES]. I believe this reference can be =
added even in the AUTH48 phase.

Lada

>=20
> Jernej
>=20
>=20
>> -----Original Message-----
>> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Ladislav
>> Lhotka
>> Sent: Wednesday, August 17, 2016 2:50 PM
>> To: Martin Bjorklund 
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] YANG 1.1: XML naming restriction
>>=20
>>=20
>>> On 17 Aug 2016, at 14:34, Martin Bjorklund  wrote:
>>>=20
>>> Ladislav Lhotka  wrote:
>>>>=20
>>>>> On 01 Aug 2016, at 10:15, William Lupton > forum.org>
>>>>> wrote:
>>>>>=20
>>>>> But the errata at https://www.w3.org/XML/xml-V10-5e-errata say the
>>>>> following. There are also related changes to Section 2.6 =
(processing
>>>>> instructions) and Section 3 (logical structures). W.
>>>>> Section 2.3 Common Syntactic Constructs
>>>>> Delete the following paragraph:
>>>>>=20
>>>>> Names beginning with the string "xml", or with any string which =
would
>>>>> match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
>>>>> standardization in this or future versions of this specification.
>>>>=20
>>>> Good catch!
>>>=20
>>> Indeed!
>>>=20
>>>> What this erratum means for YANG is that only "xml" prefix
>>>> needs to be forbidden.
>>>=20
>>> Actually, as Dale Worley pointed out, not even this is required, =
since
>>> the prefix is not required to be used in the XML encoding.
>>>=20
>>> I suggest we simply remove the line:
>>>=20
>>> ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
>>=20
>> I agree, good riddance.
>>=20
>> Lada
>>=20
>>>=20
>>> The document is now in AUTH48 so we can actually make this change.
>>>=20
>>> Juergen, and/or Benoit, do you think we can make this change to the
>>> document?  If we do, we should also mention this in section 1.1.
>>>=20
>>>=20
>>> Eventually the type yang-identifier from RFC 6991 should be revised =
as
>>> well.
>>>=20
>>>=20
>>> /martin
>>>=20
>>>=20
>>>=20
>>>>=20
>>>> If it is still possible, it would IMO make a good sense to remove =
that
>>>> comment from the ABNF in 6020bis, and make this change in sec. =
7.1.4:
>>>>=20
>>>> OLD
>>>>=20
>>>>  A prefix is an identifier (see Section 6.2).
>>>>=20
>>>> NEW
>>>>=20
>>>>  A prefix is an identifier (see Section 6.2), and it MUST NOT be =
the
>>>>  string "xml".
>>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>>> On 1 Aug 2016, at 04:22, Andy Bierman 
>> wrote:
>>>>>>=20
>>>>>>=20
>>>>>> OK -- sorry -- must have read it wrong
>>>>>>=20
>>>>>>=20
>>>>>> Andy
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>> On Sun, Jul 31, 2016 at 6:57 PM, Dale R. Worley =

>>>>>> wrote:
>>>>>> Andy Bierman  writes:
>>>>>>> The YANG 1.1 ABNF says:
>>>>>>>=20
>>>>>>>  ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m')
>> ('L'|'l'))
>>>>>>>  identifier          =3D (ALPHA / "_")
>>>>>>>                        *(ALPHA / DIGIT / "_" / "-" / ".")
>>>>>>>=20
>>>>>>>=20
>>>>>>> There is no explanation given why.
>>>>>>> The same restriction was copied to RESTCONF, also without
>> explanation.
>>>>>>> Supposedly, XML does not allow identifiers to start with XML.
>>>>>>>=20
>>>>>>> Looks like this restriction only applies to the PITarget [17], =
not
>>>>>>> Name [5]
>>>>>>> https://www.w3.org/TR/REC-xml/#sec-pi
>>>>>>>=20
>>>>>>> We have been applying this restriction to element names
>>>>>>> but it only applies to processing instructions.
>>>>>>>=20
>>>>>>> IMO it should be removed.
>>>>>>> It confuses people when they get an error for naming a data node
>>>>>>> with a string that matches.
>>>>>>=20
>>>>>> Eh?  Looking at "Extensible Markup Lanuage (XML) 1.0 (Fifth
>> Edition)",
>>>>>> section 3.1 (http://www.w3.org/TR/xml/#sec-starttags) says that =
the
>>>>>> element name of a start in end tag is a "Name".  Looking at =
section
>>>>>> 2.3
>>>>>> (http://www.w3.org/TR/xml/#sec-common-syn), I see
>>>>>>=20
>>>>>>   Names beginning with the string "xml", or with any string which
>>>>>>   would match (('X'|'x') ('M'|'m') ('L'|'l')), are reserved for
>>>>>>   standardization in this or future versions of this =
specification.
>>>>>>=20
>>>>>> And since Yang data node names can appear as XML element names,
>> Yang
>>>>>> has
>>>>>> to forbid node names that start with "XML".
>>>>>>=20
>>>>>> Dale
>>>>>>=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
>>>>=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
>>=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





From nobody Thu Aug 18 03:02: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 654AD12D56D for ; Thu, 18 Aug 2016 03:02:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Level: 
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 QPG7IhOcS3Tl for ; Thu, 18 Aug 2016 03:02:10 -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 7488F12D16D for ; Thu, 18 Aug 2016 03:02:10 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 39BFB8F7 for ; Thu, 18 Aug 2016 12:02:09 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id oPtOnZ4M3tq8 for ; Thu, 18 Aug 2016 12:02:08 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 18 Aug 2016 12:02:08 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 309BE200A5 for ; Thu, 18 Aug 2016 12:02:08 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 8fZS0fDh6pMf; Thu, 18 Aug 2016 12:02:03 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0B83B200A3; Thu, 18 Aug 2016 12:02:03 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 426DF3C24619; Thu, 18 Aug 2016 12:02:02 +0200 (CEST)
Date: Thu, 18 Aug 2016 12:02:01 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20160818100201.GA4794@elstar.local>
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Subject: [netmod] YANG 1.1 bug fix last call (was YANG 1.1: XML naming restriction)
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, 18 Aug 2016 10:02:12 -0000
X-List-Received-Date: Thu, 18 Aug 2016 10:02:12 -0000

Hi,

as discussed in the thread 'YANG 1.1: XML naming restriction', it
seems that the restriction that identifiers may not start with "xml"
is not necessary according to XML 1.0 (5th edition). In addition, it
seems the YANG 1.1 specification should have an explicit normative
reference to the XML specification it is based on. The suggested
document changes are detailed below (thanks to Martin for writing this
up). Please let the WG know by August 24th if you object against
implementing this change before YANG 1.1 is published.

/js (with my RFC6020bis document shepherd hat on)

Section 1:

OLD:

   This document describes the syntax and semantics of version 1.1 of
   the YANG language.  It also describes how a data model defined in a
   YANG module is encoded in the Extensible Markup Language (XML), and

NEW:

   This document describes the syntax and semantics of version 1.1 of
   the YANG language.  It also describes how a data model defined in a
   YANG module is encoded in the Extensible Markup Language (XML)
   [XML], and


Section 1.1:

OLD:

   o  Allow type empty in a key.

   The following changes have been done to the NETCONF mapping:

NEW:

   o  Allow type empty in a key.

   o  Removed the restriction that identifiers could not start with
      the characters "xml".

   The following changes have been done to the NETCONF mapping:


Section 14:

OLD:

   ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
   identifier          = (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / ".")

NEW:

   identifier          = (ALPHA / "_")
                         *(ALPHA / DIGIT / "_" / "-" / ".")


Section 21.1:

NEW:

   [XML]      Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
              Edition)", World Wide Web Consortium Recommendation REC-
              xml-20081126, November 2008,
              .


-- 
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 Aug 18 03:08:37 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 CE75C12D8B4 for ; Thu, 18 Aug 2016 03:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 Bzj8RccXMhBf for ; Thu, 18 Aug 2016 03:08:35 -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 391B212D56D for ; Thu, 18 Aug 2016 03:08:35 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 87F291E5A22; Thu, 18 Aug 2016 03:04:40 -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 Dtkk2yL60Dkm; Thu, 18 Aug 2016 03:04:40 -0700 (PDT)
Received: from [192.168.1.127] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id A14131E5A0B; Thu, 18 Aug 2016 03:04:39 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2D626FEE-FD50-4016-AF44-EEA4DD03AF41"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: William Lupton 
In-Reply-To: <0E8E72CF-1928-4AB9-A804-338069004B5E@juniper.net>
Date: Thu, 18 Aug 2016 11:08:32 +0100
Message-Id: <74A9033D-D02F-4B57-9FB3-AC4CD7090BB1@broadband-forum.org>
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>  <0E8E72CF-1928-4AB9-A804-338069004B5E@juniper.net>
To: Kent Watsen , "netmod@ietf.org" 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Aug 2016 10:08:37 -0000

--Apple-Mail=_2D626FEE-FD50-4016-AF44-EEA4DD03AF41
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Kent, all,

OK :). I will take Lada=E2=80=99s update to my Monday text as a baseline =
and will give my proposed new text without further ado, followed by =
rationale.

BASELINE:

It is not required to keep the revision history of unpublished versions =
(e.g., Internet-Drafts). That is, within a sequence of unpublished =
versions, only the most recent revision MAY be recorded in the module or =
submodule. However, the revision date of the most recent revision MUST =
be updated to a higher value each time a new version (e.g., of the =
Internet-Draft) is posted.

NEW:

It is not required to keep the full revision history of draft versions =
(e.g., modules contained within Internet-Drafts). That is, within a =
sequence of draft versions, only the most recent revision need be =
recorded in the module. However, if the module has changed, the revision =
date of the most recent revision MUST be updated to a higher value =
whenever a new version is made available (e.g., via a new version of an =
Internet-Draft).

=E2=80=94=E2=80=94=20

The main comments and suggestions on the baseline text were:
Why say MAY rather than MUST? Suggestion to say =E2=80=9Cneed=E2=80=9D =
to avoid difficulty with =E2=80=9Conly=E2=80=9D and =E2=80=9CMAY=E2=80=9D.=

Should be more precise re the difference between a draft and a module =
contained within a draft.
Should allow or encourage the module revision date to be bumped only if =
the YANG has changed (or on the containing draft becoming a standard).
Discussion of =E2=80=9Cpublished=E2=80=9D / =E2=80=9Cposted=E2=80=9D =
etc., and their meanings in an IETF context.
Support for the principle that the text should be both general (applying =
to all organisations) and specific (applying to IETF) and note that =
IETF-specific text should be parenthesised.
Assertion that all publicly-available =E2=80=9Cadopted=E2=80=9D modules =
(whether draft or standard) must bump revision dates if the YANG =
changes.

Here are a few notes to forestall some of your possible comments:
I didn=E2=80=99t mention submodules, because of the generic (Section =
2.3) note that =E2=80=9Cmodule=E2=80=9D means =E2=80=9Cmodule or =
submodule=E2=80=9D unless specifically discussing submodules.
I didn=E2=80=99t mention RFC publication as a special case (revision =
date MUST be unconditionally updated) because this paragraph is only =
about drafts. I assume that requirements governing modules in RFCs are =
already covered elsewhere.
I hope that I avoided IETF-emotive terms outside the parentheses, e.g I =
used the terms =E2=80=9Cdraft=E2=80=9D and =E2=80=9Cmade available=E2=80=9D=
.
I nearly added =E2=80=9Cstatement=E2=80=9D as in =E2=80=9Crevision date =
of the most recent revision statement=E2=80=9D. I would certainly be =
happy with that change.
I don=E2=80=99t really like =E2=80=9Chigher value=E2=80=9D because that =
makes it sounds like a numeric value. However, no-one has commented on =
this and I guess it=E2=80=99s unambiguous. So let fido sleep on.

Comments?

Thanks,
William

> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
>=20
> Hi William,
>=20
> Do you want to take a stab on consolidating on the comments into new =
proposed draft-text?  - there were two proposals put out before, and a =
number of refinements since, but I=E2=80=99m unsure which were picked up =
or not.  Since you raised this issue originally, if would be helpful to =
get your current take on it.
>=20
> Thanks,
> Kent

--Apple-Mail=_2D626FEE-FD50-4016-AF44-EEA4DD03AF41
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Kent, all,

OK :). I will take Lada=E2=80=99s update to my Monday =
text as a baseline and will give my proposed new text without further =
ado, followed by rationale.

BASELINE:

It is =
not required to keep the revision history of unpublished versions (e.g., =
Internet-Drafts). That is, within a sequence of unpublished versions, =
only the most recent revision MAY be recorded in the module or =
submodule. However, the revision date of the most recent revision MUST =
be updated to a higher value each time a new version (e.g., of the =
Internet-Draft) is posted.

NEW:

It is not required to =
keep the full revision history of draft versions (e.g., modules =
contained within Internet-Drafts). That is, within a sequence of draft =
versions, only the most recent revision need be recorded in =
the module. However, if the module has changed, the revision date =
of the most recent revision MUST be updated to a higher value whenever a =
new version is made available (e.g., via a new version of an =
Internet-Draft).

=E2=80=94=E2=80=94 

The main comments and suggestions on =
the baseline text were:
    Why say MAY rather than MUST? Suggestion to say =E2=80=9Cneed=E2=
=80=9D to avoid difficulty with =E2=80=9Conly=E2=80=9D and =
=E2=80=9CMAY=E2=80=9D.
  1. Should be more precise re the =
difference between a draft and a module contained within a =
draft.
  2. Should allow or encourage the module revision =
date to be bumped only if the YANG has changed (or on the containing =
draft becoming a standard).
  3. Discussion of =
=E2=80=9Cpublished=E2=80=9D / =E2=80=9Cposted=E2=80=9D etc., and their =
meanings in an IETF context.
  4. Support for the =
principle that the text should be both general (applying to all =
organisations) and specific (applying to IETF) and note that =
IETF-specific text should be parenthesised.
  5. Assertion =
that all publicly-available =E2=80=9Cadopted=E2=80=9D modules (whether =
draft or standard) must bump revision dates if the YANG =
changes.

Here are a few notes to forestall some of your possible =
comments:
  1. I =
didn=E2=80=99t mention submodules, because of the generic (Section 2.3) =
note that =E2=80=9Cmodule=E2=80=9D means =E2=80=9Cmodule or submodule=E2=80=
=9D unless specifically discussing submodules.
  2. I =
didn=E2=80=99t mention RFC publication as a special case (revision date =
MUST be unconditionally updated) because this paragraph is only about =
drafts. I assume that requirements governing modules in RFCs are already =
covered elsewhere.
  3. I hope that I avoided IETF-emotive =
terms outside the parentheses, e.g I used the terms =E2=80=9Cdraft=E2=80=9D=
 and =E2=80=9Cmade available=E2=80=9D.
  4. I nearly added =
=E2=80=9Cstatement=E2=80=9D as in =E2=80=9Crevision date of the most =
recent revision statement=E2=80=9D. I would certainly be happy with that =
change.
  5. I don=E2=80=99t really like =E2=80=9Chigher =
value=E2=80=9D because that makes it sounds like a numeric value. =
However, no-one has commented on this and I guess it=E2=80=99s =
unambiguous. So let fido sleep on.

Comments?

Thanks,
William

On 16 Aug 2016, at 19:02, Kent Watsen <kwatsen@juniper.net>=
 wrote:

Hi William,

Do you want to take a stab on consolidating on the comments =
into new proposed draft-text?  - there were two proposals put out =
before, and a number of refinements since, but I=E2=80=99m unsure =
which were picked up or not.  Since you raised this issue =
originally, if would be helpful to get your current take on it.

Thanks,
Kent
=

--Apple-Mail=_2D626FEE-FD50-4016-AF44-EEA4DD03AF41--


From nobody Thu Aug 18 05:07: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 886B512DA18 for ; Thu, 18 Aug 2016 05:07:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.248
X-Spam-Level: 
X-Spam-Status: No, score=-3.248 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RP_MATCHES_RCVD=-1.247, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6Z5xYedF5kv for ; Thu, 18 Aug 2016 05:07:05 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6F512D9D8 for ; Thu, 18 Aug 2016 04:59:04 -0700 (PDT)
Received: from jernejthpPC (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id 0C681C41D7F5; Thu, 18 Aug 2016 13:59:04 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si 0C681C41D7F5
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1471521544; bh=AALAHA+2r1kvwG9Lm9BndH+iByGzvfmy3TaIcOrFUrI=; h=From:To:References:In-Reply-To:Subject:Date:From; b=uGsySWSfEW7HobDBvLrl4e/6vR2EKCiuMWCYvvW/8FyQX4JgXcEOBsksMS/71UpI6 5SzAjzW0q2k5q7b6MnzNy0U62Jv+Vv6PzMQa/N3Vrsn+R1bjoZt1tPeYEgseWZMBeY PBFJd7cJDTOf9TOUNvmaLv5qRy4s1Ch+udIfiEokhh71UoQHeaZbZQS4x6zPWu67Cx +lxE1L1hifIvqmxvJkjoHKXWUMYFK8PzscE/24qM/+a2JfE3Cy+FBV1gJffDidkn/2 VocZuU8w3SsBzIIgqgMkdrGiMFVwkRCv7ZsIpHWqUekJV3JxLw03rFQxOZE5VIcEGz OhaBpMOvbUMUw==
From: "Jernej Tuljak" 
To: "'Juergen Schoenwaelder'" , 
References: <20160818100201.GA4794@elstar.local>
In-Reply-To: <20160818100201.GA4794@elstar.local>
Date: Thu, 18 Aug 2016 13:59:01 +0200
Message-ID: <033201d1f947$e8facd80$baf06880$@mg-soft.si>
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 15.0
Content-Language: sl
Thread-Index: AQHceqFCUMekt2n5DyhCena2UBgUxqA5j6TA
Archived-At: 
Subject: Re: [netmod] YANG 1.1 bug fix last call (was YANG 1.1: XML naming	restriction)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Aug 2016 12:07:06 -0000

While you are at it, there seems to be an orphaned production in the =
grammar (rfc6020bis-14):

   boolean-operator =3D and-keyword / or-keyword

It is probably a leftover from previous versions of if-feature-expr.
=20
Jernej


> -----Original Message-----
> From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
> Schoenwaelder
> Sent: Thursday, August 18, 2016 12:02 PM
> To: netmod@ietf.org
> Subject: [netmod] YANG 1.1 bug fix last call (was YANG 1.1: XML naming
> restriction)
>=20
> Hi,
>=20
> as discussed in the thread 'YANG 1.1: XML naming restriction', it
> seems that the restriction that identifiers may not start with "xml"
> is not necessary according to XML 1.0 (5th edition). In addition, it
> seems the YANG 1.1 specification should have an explicit normative
> reference to the XML specification it is based on. The suggested
> document changes are detailed below (thanks to Martin for writing this
> up). Please let the WG know by August 24th if you object against
> implementing this change before YANG 1.1 is published.
>=20
> /js (with my RFC6020bis document shepherd hat on)
>=20
> Section 1:
>=20
> OLD:
>=20
>    This document describes the syntax and semantics of version 1.1 of
>    the YANG language.  It also describes how a data model defined in a
>    YANG module is encoded in the Extensible Markup Language (XML), and
>=20
> NEW:
>=20
>    This document describes the syntax and semantics of version 1.1 of
>    the YANG language.  It also describes how a data model defined in a
>    YANG module is encoded in the Extensible Markup Language (XML)
>    [XML], and
>=20
>=20
> Section 1.1:
>=20
> OLD:
>=20
>    o  Allow type empty in a key.
>=20
>    The following changes have been done to the NETCONF mapping:
>=20
> NEW:
>=20
>    o  Allow type empty in a key.
>=20
>    o  Removed the restriction that identifiers could not start with
>       the characters "xml".
>=20
>    The following changes have been done to the NETCONF mapping:
>=20
>=20
> Section 14:
>=20
> OLD:
>=20
>    ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') =
('L'|'l'))
>    identifier          =3D (ALPHA / "_")
>                          *(ALPHA / DIGIT / "_" / "-" / ".")
>=20
> NEW:
>=20
>    identifier          =3D (ALPHA / "_")
>                          *(ALPHA / DIGIT / "_" / "-" / ".")
>=20
>=20
> Section 21.1:
>=20
> NEW:
>=20
>    [XML]      Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., =
and
>               F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
>               Edition)", World Wide Web Consortium Recommendation REC-
>               xml-20081126, November 2008,
>               .
>=20
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Aug 18 05:22: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 6777612DAFD for ; Thu, 18 Aug 2016 05:22:34 -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 7iSHwZ7B1rmw for ; Thu, 18 Aug 2016 05:22:32 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 52DB512DB02 for ; Thu, 18 Aug 2016 05:21:09 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 9BC1B1CC024A; Thu, 18 Aug 2016 14:21:23 +0200 (CEST)
From: Ladislav Lhotka 
To: William Lupton , Kent Watsen , "netmod\@ietf.org" 
In-Reply-To: <74A9033D-D02F-4B57-9FB3-AC4CD7090BB1@broadband-forum.org>
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>  <0E8E72CF-1928-4AB9-A804-338069004B5E@juniper.net> <74A9033D-D02F-4B57-9FB3-AC4CD7090BB1@broadband-forum.org>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Thu, 18 Aug 2016 14:21:06 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Aug 2016 12:22:34 -0000

William Lupton  writes:

> Kent, all,
>
> OK :). I will take Lada=E2=80=99s update to my Monday text as a baseline =
and will give my proposed new text without further ado, followed by rationa=
le.
>
> BASELINE:
>
> It is not required to keep the revision history of unpublished versions (=
e.g., Internet-Drafts). That is, within a sequence of unpublished versions,=
 only the most recent revision MAY be recorded in the module or submodule. =
However, the revision date of the most recent revision MUST be updated to a=
 higher value each time a new version (e.g., of the Internet-Draft) is post=
ed.
>
> NEW:
>
> It is not required to keep the full revision history of draft versions
> (e.g., modules contained within Internet-Drafts). That is, within a
> sequence of draft versions, only the most recent revision need be
> recorded in the module. However, if the module has changed, the
> revision date of the most recent revision MUST be updated to a higher
> value whenever a new version is made available (e.g., via a new
> version of an Internet-Draft).

I like this text. Perhaps "a higher value" could be replaced with "a
later date"?

Lada

>
> =E2=80=94=E2=80=94=20
>
> The main comments and suggestions on the baseline text were:
> Why say MAY rather than MUST? Suggestion to say =E2=80=9Cneed=E2=80=9D to=
 avoid difficulty with =E2=80=9Conly=E2=80=9D and =E2=80=9CMAY=E2=80=9D.
> Should be more precise re the difference between a draft and a module con=
tained within a draft.
> Should allow or encourage the module revision date to be bumped only if t=
he YANG has changed (or on the containing draft becoming a standard).
> Discussion of =E2=80=9Cpublished=E2=80=9D / =E2=80=9Cposted=E2=80=9D etc.=
, and their meanings in an IETF context.
> Support for the principle that the text should be both general (applying =
to all organisations) and specific (applying to IETF) and note that IETF-sp=
ecific text should be parenthesised.
> Assertion that all publicly-available =E2=80=9Cadopted=E2=80=9D modules (=
whether draft or standard) must bump revision dates if the YANG changes.
>
> Here are a few notes to forestall some of your possible comments:
> I didn=E2=80=99t mention submodules, because of the generic (Section 2.3)=
 note that =E2=80=9Cmodule=E2=80=9D means =E2=80=9Cmodule or submodule=E2=
=80=9D unless specifically discussing submodules.
> I didn=E2=80=99t mention RFC publication as a special case (revision date=
 MUST be unconditionally updated) because this paragraph is only about draf=
ts. I assume that requirements governing modules in RFCs are already covere=
d elsewhere.
> I hope that I avoided IETF-emotive terms outside the parentheses, e.g I u=
sed the terms =E2=80=9Cdraft=E2=80=9D and =E2=80=9Cmade available=E2=80=9D.
> I nearly added =E2=80=9Cstatement=E2=80=9D as in =E2=80=9Crevision date o=
f the most recent revision statement=E2=80=9D. I would certainly be happy w=
ith that change.
> I don=E2=80=99t really like =E2=80=9Chigher value=E2=80=9D because that m=
akes it sounds like a numeric value. However, no-one has commented on this =
and I guess it=E2=80=99s unambiguous. So let fido sleep on.
>
> Comments?
>
> Thanks,
> William
>
>> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
>>=20
>> Hi William,
>>=20
>> Do you want to take a stab on consolidating on the comments into new pro=
posed draft-text?  - there were two proposals put out before, and a number =
of refinements since, but I=E2=80=99m unsure which were picked up or not.  =
Since you raised this issue originally, if would be helpful to get your cur=
rent take on it.
>>=20
>> Thanks,
>> Kent
> _______________________________________________
> 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 Aug 18 05:33:37 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 ED88E12DCFC for ; Thu, 18 Aug 2016 05:33:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 a1r26ahxxM0V for ; Thu, 18 Aug 2016 05:33:34 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BF98112DB54 for ; Thu, 18 Aug 2016 05:30:44 -0700 (PDT)
Received: from localhost (h-85-226.a165.priv.bahnhof.se [94.254.85.226]) by mail.tail-f.com (Postfix) with ESMTPSA id 5B1AE1AE0187; Thu, 18 Aug 2016 14:30:43 +0200 (CEST)
Date: Thu, 18 Aug 2016 14:30:43 +0200 (CEST)
Message-Id: <20160818.143043.1970347303758564657.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20160818100201.GA4794@elstar.local>
References: <20160818100201.GA4794@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] YANG 1.1 bug fix last call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Aug 2016 12:33:36 -0000

Hi,

Juergen Schoenwaelder  wrote:
> Hi,
> 
> as discussed in the thread 'YANG 1.1: XML naming restriction', it
> seems that the restriction that identifiers may not start with "xml"
> is not necessary according to XML 1.0 (5th edition). In addition, it
> seems the YANG 1.1 specification should have an explicit normative
> reference to the XML specification it is based on. The suggested
> document changes are detailed below (thanks to Martin for writing this
> up). Please let the WG know by August 24th if you object against
> implementing this change before YANG 1.1 is published.
> 
> /js (with my RFC6020bis document shepherd hat on)

I found one more change that I'd like to do, in section 9.4.7:

OLD:

With the following type:

  typedef yang-identifier {
    type string {
      length "1..max";
      pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
      pattern '[xX][mM][lL].*' {
        modifier invert-match;
      }
    }
  }

NEW:

With the following type:

  type string {
    length "1..max";
    pattern '[a-zA-Z_][a-zA-Z0-9\-_.]*';
    pattern '[xX][mM][lL].*' {
      modifier invert-match;
    }
  }


/martin


> 
> Section 1:
> 
> OLD:
> 
>    This document describes the syntax and semantics of version 1.1 of
>    the YANG language.  It also describes how a data model defined in a
>    YANG module is encoded in the Extensible Markup Language (XML), and
> 
> NEW:
> 
>    This document describes the syntax and semantics of version 1.1 of
>    the YANG language.  It also describes how a data model defined in a
>    YANG module is encoded in the Extensible Markup Language (XML)
>    [XML], and
> 
> 
> Section 1.1:
> 
> OLD:
> 
>    o  Allow type empty in a key.
> 
>    The following changes have been done to the NETCONF mapping:
> 
> NEW:
> 
>    o  Allow type empty in a key.
> 
>    o  Removed the restriction that identifiers could not start with
>       the characters "xml".
> 
>    The following changes have been done to the NETCONF mapping:
> 
> 
> Section 14:
> 
> OLD:
> 
>    ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
>    identifier          = (ALPHA / "_")
>                          *(ALPHA / DIGIT / "_" / "-" / ".")
> 
> NEW:
> 
>    identifier          = (ALPHA / "_")
>                          *(ALPHA / DIGIT / "_" / "-" / ".")
> 
> 
> Section 21.1:
> 
> NEW:
> 
>    [XML]      Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
>               F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
>               Edition)", World Wide Web Consortium Recommendation REC-
>               xml-20081126, November 2008,
>               .
> 
> 
> -- 
> 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 Aug 18 07:14: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 0091112D1A2 for ; Thu, 18 Aug 2016 07:14:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.148
X-Spam-Level: 
X-Spam-Status: No, score=-3.148 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-1.247, 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 E1j1sw9IX7V9 for ; Thu, 18 Aug 2016 07:14:48 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 38DC312DF2C for ; Thu, 18 Aug 2016 07:14:48 -0700 (PDT)
Received: from localhost (h-85-226.a165.priv.bahnhof.se [94.254.85.226]) by mail.tail-f.com (Postfix) with ESMTPSA id 7BF281AE0187; Thu, 18 Aug 2016 16:14:47 +0200 (CEST)
Date: Thu, 18 Aug 2016 16:14:47 +0200 (CEST)
Message-Id: <20160818.161447.1716540728951358117.mbj@tail-f.com>
To: jernej.tuljak@mg-soft.si
From: Martin Bjorklund 
In-Reply-To: <033201d1f947$e8facd80$baf06880$@mg-soft.si>
References: <20160818100201.GA4794@elstar.local> <033201d1f947$e8facd80$baf06880$@mg-soft.si>
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 bug fix last call
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Aug 2016 14:14:50 -0000

"Jernej Tuljak"  wrote:
> While you are at it, there seems to be an orphaned production in the grammar (rfc6020bis-14):
> 
>    boolean-operator = and-keyword / or-keyword
> 
> It is probably a leftover from previous versions of if-feature-expr.

Thanks!  I will remove it during AUTH48.


/martin


>  
> Jernej
> 
> 
> > -----Original Message-----
> > From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of Juergen
> > Schoenwaelder
> > Sent: Thursday, August 18, 2016 12:02 PM
> > To: netmod@ietf.org
> > Subject: [netmod] YANG 1.1 bug fix last call (was YANG 1.1: XML naming
> > restriction)
> > 
> > Hi,
> > 
> > as discussed in the thread 'YANG 1.1: XML naming restriction', it
> > seems that the restriction that identifiers may not start with "xml"
> > is not necessary according to XML 1.0 (5th edition). In addition, it
> > seems the YANG 1.1 specification should have an explicit normative
> > reference to the XML specification it is based on. The suggested
> > document changes are detailed below (thanks to Martin for writing this
> > up). Please let the WG know by August 24th if you object against
> > implementing this change before YANG 1.1 is published.
> > 
> > /js (with my RFC6020bis document shepherd hat on)
> > 
> > Section 1:
> > 
> > OLD:
> > 
> >    This document describes the syntax and semantics of version 1.1 of
> >    the YANG language.  It also describes how a data model defined in a
> >    YANG module is encoded in the Extensible Markup Language (XML), and
> > 
> > NEW:
> > 
> >    This document describes the syntax and semantics of version 1.1 of
> >    the YANG language.  It also describes how a data model defined in a
> >    YANG module is encoded in the Extensible Markup Language (XML)
> >    [XML], and
> > 
> > 
> > Section 1.1:
> > 
> > OLD:
> > 
> >    o  Allow type empty in a key.
> > 
> >    The following changes have been done to the NETCONF mapping:
> > 
> > NEW:
> > 
> >    o  Allow type empty in a key.
> > 
> >    o  Removed the restriction that identifiers could not start with
> >       the characters "xml".
> > 
> >    The following changes have been done to the NETCONF mapping:
> > 
> > 
> > Section 14:
> > 
> > OLD:
> > 
> >    ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
> >    identifier          = (ALPHA / "_")
> >                          *(ALPHA / DIGIT / "_" / "-" / ".")
> > 
> > NEW:
> > 
> >    identifier          = (ALPHA / "_")
> >                          *(ALPHA / DIGIT / "_" / "-" / ".")
> > 
> > 
> > Section 21.1:
> > 
> > NEW:
> > 
> >    [XML]      Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
> >               F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
> >               Edition)", World Wide Web Consortium Recommendation REC-
> >               xml-20081126, November 2008,
> >               .
> > 
> > 
> > --
> > Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> > Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> > Fax:   +49 421 200 3103         
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Thu Aug 18 08:12:37 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 4979712DD5C; Thu, 18 Aug 2016 08:12:35 -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.29.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <147153315528.22086.17342787128734530722.idtracker@ietfa.amsl.com>
Date: Thu, 18 Aug 2016 08:12:35 -0700
Archived-At: 
Cc: netmod@ietf.org
Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-23.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, 18 Aug 2016 15:12:35 -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-23.txt
	Pages           : 74
	Date            : 2016-08-18

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 control plane
   protocols, route filters and other functions.  The core routing data
   model provides common building blocks for such extensions -- routes,
   routing information bases (RIB), and control plane 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-23

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-routing-cfg-23


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 Aug 18 08:17: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 AA18E12DD8D for ; Thu, 18 Aug 2016 08:17:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -8.247
X-Spam-Level: 
X-Spam-Status: No, score=-8.247 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=-1.247] 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 TTEZaImS30il for ; Thu, 18 Aug 2016 08:17:48 -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 7E65D12DB67 for ; Thu, 18 Aug 2016 08:17:48 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:b125:b546:8839:ff0c] (unknown [IPv6:2001:718:1a02:1:b125:b546:8839:ff0c]) by mail.nic.cz (Postfix) with ESMTPSA id F396460869 for ; Thu, 18 Aug 2016 17:17:46 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471533467; bh=MsDUTESmwKa6BJZM3IeWOgZiDhkwhHunXi7gCoT7p0M=; h=From:Date:To; b=G2o/Iqm4C/JHeXYZKu17v8bk/Z/1Zv6sbzm6lU0CmYOVeJ+/pZL4TUYthoeiI9B0F Z+CwR4aP7qPqNaH9SJPiufaMZ+1EoncYLtuw2avUhbKR1ED6jg/pVLgBmaetxdhRjL bnLxeKZ+nQjyChd25Q3awoqGRfS7ge76BEkd4Tqw=
From: Ladislav Lhotka 
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable
Date: Thu, 18 Aug 2016 17:17:48 +0200
References: <147153315528.22086.17342787128734530722.idtracker@ietfa.amsl.com>
To: NETMOD WG 
Message-Id: 
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
X-Mailer: Apple Mail (2.3124)
X-Virus-Scanned: clamav-milter 0.98.7 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: [netmod] Fwd:  I-D Action: draft-ietf-netmod-routing-cfg-23.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, 18 Aug 2016 15:17:51 -0000

Hi,

apart from relatively minor changes to the schema that were agreed in =
Berlin, all modules were migrated to YANG 1.1 and actively use new YANG =
1.1 features: XPath function derived-from-or-self(), and the action =
"active-route".

Lada

> Begin forwarded message:
>=20
> From: internet-drafts@ietf.org
> Subject: [netmod] I-D Action: draft-ietf-netmod-routing-cfg-23.txt
> Date: 18 August 2016 at 17:12:35 GMT+2
> 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           : A YANG Data Model for Routing Management
>        Authors         : Ladislav Lhotka
>                          Acee Lindem
> 	Filename        : draft-ietf-netmod-routing-cfg-23.txt
> 	Pages           : 74
> 	Date            : 2016-08-18
>=20
> 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 control plane
>   protocols, route filters and other functions.  The core routing data
>   model provides common building blocks for such extensions -- routes,
>   routing information bases (RIB), and control plane protocols.
>=20
>=20
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-netmod-routing-cfg/
>=20
> There's also a htmlized version available at:
> https://tools.ietf.org/html/draft-ietf-netmod-routing-cfg-23
>=20
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-routing-cfg-23
>=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 Thu Aug 18 09:57: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 B453012DECF for ; Thu, 18 Aug 2016 09:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.768
X-Spam-Level: 
X-Spam-Status: No, score=-15.768 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=-1.247, 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 nxObwh32zyTx for ; Thu, 18 Aug 2016 09:56:45 -0700 (PDT)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7EE9B12DA6E for ; Thu, 18 Aug 2016 09:55:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3810; q=dns/txt; s=iport; t=1471539353; x=1472748953; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=x6ntMVfS6lF+Rizv5UMfaM+eQFLwfXqM/YhIYj2LDwY=; b=PJlPIC5Fa93zyuCRMey7nDk3gCw6b6oCNyHnELj/TlZzUUgIuInBU+pb uTHe8EG++SyvvG49xRLKPZaajZ3QeXhcWptBJk5kPV9dGK1HaW+xSDIGZ n6Jq/4use7Q4IVX7CV9D2qmjHHOdc7CdkWXv1etqt/fJNvnQPvWXTZBuA U=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAgAa6LVX/5FdJa1dg0NWfAe3YIF9J?= =?us-ascii?q?IUvSgIcgU84FAIBAQEBAQEBXieEXgEBBQEBIRE6CxACAQgOAwMBAgMCJgICAiU?= =?us-ascii?q?LFQYBAQUDAgQBDQWIMQ6sDZAWAQEBAQEBAQEBAQEBAQEBAQEBAQEBHIEBiXaHQ?= =?us-ascii?q?YJaBZlEAYYfiH6Ba06EDokCjDuDdwEeNoN6boYufwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,540,1464652800"; d="scan'208";a="141340275"
Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 18 Aug 2016 16:55:51 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u7IGtplv028963 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 18 Aug 2016 16:55:51 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.1210.3; Thu, 18 Aug 2016 12:55:50 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Thu, 18 Aug 2016 12:55:50 -0400
From: "Acee Lindem (acee)" 
To: Lou Berger , Kent Watsen 
Thread-Topic: [netmod] Fwd:  I-D Action: draft-ietf-netmod-routing-cfg-23.txt
Thread-Index: AQHR+WPHIzK/c6DrHEyyf/9bQCCo8KBO7/GA
Date: Thu, 18 Aug 2016 16:55:49 +0000
Message-ID: 
References: <147153315528.22086.17342787128734530722.idtracker@ietfa.amsl.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.116.152.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: netmod WG 
Subject: [netmod] FW: Fwd: I-D Action: draft-ietf-netmod-routing-cfg-23.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, 18 Aug 2016 16:56:56 -0000

TG91LCBLZW50LCANCg0KTGFkYSBhbmQgSSBmZWVsIHRoaXMgdmVyc2lvbiBpcyByZWFkeSBmb3Ig
V0cgbGFzdCBjYWxsLg0KDQpUaGFua3MsDQpBY2VlIA0KDQpPbiA4LzE4LzE2LCAxMToxNyBBTSwg
Im5ldG1vZCBvbiBiZWhhbGYgb2YgTGFkaXNsYXYgTGhvdGthIg0KPG5ldG1vZC1ib3VuY2VzQGll
dGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToNCg0KPkhpLA0KPg0KPmFw
YXJ0IGZyb20gcmVsYXRpdmVseSBtaW5vciBjaGFuZ2VzIHRvIHRoZSBzY2hlbWEgdGhhdCB3ZXJl
IGFncmVlZCBpbg0KPkJlcmxpbiwgYWxsIG1vZHVsZXMgd2VyZSBtaWdyYXRlZCB0byBZQU5HIDEu
MSBhbmQgYWN0aXZlbHkgdXNlIG5ldyBZQU5HDQo+MS4xIGZlYXR1cmVzOiBYUGF0aCBmdW5jdGlv
biBkZXJpdmVkLWZyb20tb3Itc2VsZigpLCBhbmQgdGhlIGFjdGlvbg0KPiJhY3RpdmUtcm91dGUi
Lg0KPg0KPkxhZGENCj4NCj4+IEJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KPj4gDQo+PiBGcm9t
OiBpbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmcNCj4+IFN1YmplY3Q6IFtuZXRtb2RdIEktRCBBY3Rp
b246IGRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTIzLnR4dA0KPj4gRGF0ZTogMTggQXVn
dXN0IDIwMTYgYXQgMTc6MTI6MzUgR01UKzINCj4+IFRvOiA8aS1kLWFubm91bmNlQGlldGYub3Jn
Pg0KPj4gQ2M6IG5ldG1vZEBpZXRmLm9yZw0KPj4gDQo+PiANCj4+IEEgTmV3IEludGVybmV0LURy
YWZ0IGlzIGF2YWlsYWJsZSBmcm9tIHRoZSBvbi1saW5lIEludGVybmV0LURyYWZ0cw0KPj5kaXJl
Y3Rvcmllcy4NCj4+IFRoaXMgZHJhZnQgaXMgYSB3b3JrIGl0ZW0gb2YgdGhlIE5FVENPTkYgRGF0
YSBNb2RlbGluZyBMYW5ndWFnZSBvZiB0aGUNCj4+SUVURi4NCj4+IA0KPj4gICAgICAgIFRpdGxl
ICAgICAgICAgICA6IEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0aW5nIE1hbmFnZW1lbnQNCj4+
ICAgICAgICBBdXRob3JzICAgICAgICAgOiBMYWRpc2xhdiBMaG90a2ENCj4+ICAgICAgICAgICAg
ICAgICAgICAgICAgICBBY2VlIExpbmRlbQ0KPj4gCUZpbGVuYW1lICAgICAgICA6IGRyYWZ0LWll
dGYtbmV0bW9kLXJvdXRpbmctY2ZnLTIzLnR4dA0KPj4gCVBhZ2VzICAgICAgICAgICA6IDc0DQo+
PiAJRGF0ZSAgICAgICAgICAgIDogMjAxNi0wOC0xOA0KPj4gDQo+PiBBYnN0cmFjdDoNCj4+ICAg
VGhpcyBkb2N1bWVudCBjb250YWlucyBhIHNwZWNpZmljYXRpb24gb2YgdGhyZWUgWUFORyBtb2R1
bGVzIGFuZCBvbmUNCj4+ICAgc3VibW9kdWxlLiAgVG9nZXRoZXIgdGhleSBmb3JtIHRoZSBjb3Jl
IHJvdXRpbmcgZGF0YSBtb2RlbCB3aGljaA0KPj4gICBzZXJ2ZXMgYXMgYSBmcmFtZXdvcmsgZm9y
IGNvbmZpZ3VyaW5nIGFuZCBtYW5hZ2luZyBhIHJvdXRpbmcNCj4+ICAgc3Vic3lzdGVtLiAgSXQg
aXMgZXhwZWN0ZWQgdGhhdCB0aGVzZSBtb2R1bGVzIHdpbGwgYmUgYXVnbWVudGVkIGJ5DQo+PiAg
IGFkZGl0aW9uYWwgWUFORyBtb2R1bGVzIGRlZmluaW5nIGRhdGEgbW9kZWxzIGZvciBjb250cm9s
IHBsYW5lDQo+PiAgIHByb3RvY29scywgcm91dGUgZmlsdGVycyBhbmQgb3RoZXIgZnVuY3Rpb25z
LiAgVGhlIGNvcmUgcm91dGluZyBkYXRhDQo+PiAgIG1vZGVsIHByb3ZpZGVzIGNvbW1vbiBidWls
ZGluZyBibG9ja3MgZm9yIHN1Y2ggZXh0ZW5zaW9ucyAtLSByb3V0ZXMsDQo+PiAgIHJvdXRpbmcg
aW5mb3JtYXRpb24gYmFzZXMgKFJJQiksIGFuZCBjb250cm9sIHBsYW5lIHByb3RvY29scy4NCj4+
IA0KPj4gDQo+PiBUaGUgSUVURiBkYXRhdHJhY2tlciBzdGF0dXMgcGFnZSBmb3IgdGhpcyBkcmFm
dCBpczoNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0
bW9kLXJvdXRpbmctY2ZnLw0KPj4gDQo+PiBUaGVyZSdzIGFsc28gYSBodG1saXplZCB2ZXJzaW9u
IGF2YWlsYWJsZSBhdDoNCj4+IGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1pZXRm
LW5ldG1vZC1yb3V0aW5nLWNmZy0yMw0KPj4gDQo+PiBBIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMg
dmVyc2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9yZmNkaWZm
P3VybDI9ZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMjMNCj4+IA0KPj4gDQo+PiBQbGVh
c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt
ZSBvZg0KPj5zdWJtaXNzaW9uDQo+PiB1bnRpbCB0aGUgaHRtbGl6ZWQgdmVyc2lvbiBhbmQgZGlm
ZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KPj4gDQo+PiBJbnRlcm5ldC1EcmFm
dHMgYXJlIGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+PiBmdHA6Ly9mdHAu
aWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fXw0KPj4gbmV0bW9kIG1haWxpbmcgbGlzdA0KPj4gbmV0
bW9kQGlldGYub3JnDQo+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25l
dG1vZA0KPg0KPi0tDQo+TGFkaXNsYXYgTGhvdGthLCBDWi5OSUMgTGFicw0KPlBHUCBLZXkgSUQ6
IEU3NEU4QzBDDQo+DQo+DQo+DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18NCj5uZXRtb2QgbWFpbGluZyBsaXN0DQo+bmV0bW9kQGlldGYub3JnDQo+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0K


From nobody Thu Aug 18 10:08:57 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 30C0B12D801 for ; Thu, 18 Aug 2016 10:08:56 -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 gVM1dylYld-1 for ; Thu, 18 Aug 2016 10:08:54 -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 7F98512D5CA for ; Thu, 18 Aug 2016 10:08:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id B14A91E5A35; Thu, 18 Aug 2016 10:04:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from mail.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QQ9Ek-lVdY73; Thu, 18 Aug 2016 10:04:58 -0700 (PDT)
Received: from [192.168.1.129] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id B1A371E5A0B; Thu, 18 Aug 2016 10:04:57 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: William Lupton 
In-Reply-To: 
Date: Thu, 18 Aug 2016 18:08:51 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>  <0E8E72CF-1928-4AB9-A804-338069004B5E@juniper.net> <74A9033D-D02F-4B57-9FB3-AC4CD7090BB1@broadband-forum.org> 
To: Ladislav Lhotka 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Aug 2016 17:08:56 -0000

Thanks. Of course I am fine with this suggestion. This gives:

NEW:

It is not required to keep the full revision history of draft versions =
(e.g., modules contained within Internet-Drafts). That is, within a =
sequence of draft versions, only the most recent revision need be =
recorded in the module. However, if the module has changed, the revision =
date of the most recent revision MUST be updated to a later date =
whenever a new version is made available (e.g., via a new version of an =
Internet-Draft).

> On 18 Aug 2016, at 13:21, Ladislav Lhotka  wrote:
>=20
> William Lupton  writes:
>=20
>> Kent, all,
>>=20
>> OK :). I will take Lada=E2=80=99s update to my Monday text as a =
baseline and will give my proposed new text without further ado, =
followed by rationale.
>>=20
>> BASELINE:
>>=20
>> It is not required to keep the revision history of unpublished =
versions (e.g., Internet-Drafts). That is, within a sequence of =
unpublished versions, only the most recent revision MAY be recorded in =
the module or submodule. However, the revision date of the most recent =
revision MUST be updated to a higher value each time a new version =
(e.g., of the Internet-Draft) is posted.
>>=20
>> NEW:
>>=20
>> It is not required to keep the full revision history of draft =
versions
>> (e.g., modules contained within Internet-Drafts). That is, within a
>> sequence of draft versions, only the most recent revision need be
>> recorded in the module. However, if the module has changed, the
>> revision date of the most recent revision MUST be updated to a higher
>> value whenever a new version is made available (e.g., via a new
>> version of an Internet-Draft).
>=20
> I like this text. Perhaps "a higher value" could be replaced with "a
> later date"?
>=20
> Lada
>=20
>>=20
>> =E2=80=94=E2=80=94=20
>>=20
>> The main comments and suggestions on the baseline text were:
>> Why say MAY rather than MUST? Suggestion to say =E2=80=9Cneed=E2=80=9D =
to avoid difficulty with =E2=80=9Conly=E2=80=9D and =E2=80=9CMAY=E2=80=9D.=

>> Should be more precise re the difference between a draft and a module =
contained within a draft.
>> Should allow or encourage the module revision date to be bumped only =
if the YANG has changed (or on the containing draft becoming a =
standard).
>> Discussion of =E2=80=9Cpublished=E2=80=9D / =E2=80=9Cposted=E2=80=9D =
etc., and their meanings in an IETF context.
>> Support for the principle that the text should be both general =
(applying to all organisations) and specific (applying to IETF) and note =
that IETF-specific text should be parenthesised.
>> Assertion that all publicly-available =E2=80=9Cadopted=E2=80=9D =
modules (whether draft or standard) must bump revision dates if the YANG =
changes.
>>=20
>> Here are a few notes to forestall some of your possible comments:
>> I didn=E2=80=99t mention submodules, because of the generic (Section =
2.3) note that =E2=80=9Cmodule=E2=80=9D means =E2=80=9Cmodule or =
submodule=E2=80=9D unless specifically discussing submodules.
>> I didn=E2=80=99t mention RFC publication as a special case (revision =
date MUST be unconditionally updated) because this paragraph is only =
about drafts. I assume that requirements governing modules in RFCs are =
already covered elsewhere.
>> I hope that I avoided IETF-emotive terms outside the parentheses, e.g =
I used the terms =E2=80=9Cdraft=E2=80=9D and =E2=80=9Cmade available=E2=80=
=9D.
>> I nearly added =E2=80=9Cstatement=E2=80=9D as in =E2=80=9Crevision =
date of the most recent revision statement=E2=80=9D. I would certainly =
be happy with that change.
>> I don=E2=80=99t really like =E2=80=9Chigher value=E2=80=9D because =
that makes it sounds like a numeric value. However, no-one has commented =
on this and I guess it=E2=80=99s unambiguous. So let fido sleep on.
>>=20
>> Comments?
>>=20
>> Thanks,
>> William
>>=20
>>> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
>>>=20
>>> Hi William,
>>>=20
>>> Do you want to take a stab on consolidating on the comments into new =
proposed draft-text?  - there were two proposals put out before, and a =
number of refinements since, but I=E2=80=99m unsure which were picked up =
or not.  Since you raised this issue originally, if would be helpful to =
get your current take on it.
>>>=20
>>> Thanks,
>>> Kent
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> --=20
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>=20


From nobody Thu Aug 18 10:21: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 C5CB712DB2B for ; Thu, 18 Aug 2016 10:21:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XNzZc67H_DEY for ; Thu, 18 Aug 2016 10:21:11 -0700 (PDT)
Received: from mail-ua0-x22f.google.com (mail-ua0-x22f.google.com [IPv6:2607:f8b0:400c:c08::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 763D112DAB3 for ; Thu, 18 Aug 2016 10:21:11 -0700 (PDT)
Received: by mail-ua0-x22f.google.com with SMTP id k90so39237249uak.1 for ; Thu, 18 Aug 2016 10:21:11 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=pOBnDc69kuUzm0FGErdh7OgBo1/dfybarxtX8/VLvDY=; b=1ZNztB4YSBh1mrl185S3BUctbcEL5GldZXoLjO2TrlXhQoRK4VR7QIcTCG3+EXa9/m LhdpCIk9mnqSgDCnA8GEuKIzwtr5dadGxEqNcm/nq0rvUivIxZkTsOI6TIAML+b9xIRd xFXAJb0uBDvTYdBWx66enOmvGrjpwq5rxEsglpsqq+cWa2IJjahfuNGqYF39yxJKhH6P sRK4iuxq3NGdTkBkRP0HpxSm/R7ckEhpBBlEbaE/qvdbqoFDhRSj55ofosvddt1hsCeK xrlKFjHSAhD037Sq2EjmB320mdpYFo+LHG9FmB+j0JLMN0fuz7dERUUtWVg0RVD5HvFO qfPQ==
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:from:date :message-id:subject:to:cc; bh=pOBnDc69kuUzm0FGErdh7OgBo1/dfybarxtX8/VLvDY=; b=ZCQKLWQJ2IYhygWBO1P8nJ2Q2JquWReVsf+8Qek27lWnIDKR7FvvEhQkhfVi5y2CXp mI4j4miMnmGlsiunPnx5f48aC+1OBTMvp1TFTHirajqoGaV4f1B06U6H1gTyrS56Yvec 9+H9O3qr7zyD1tUM6E8Cs7r2jfR2sR0m3OcUjC4EdmuZOq/xi3b9K/3PbqIGzVFQo+6f YLUBtFU8FAfgPCSeNFLVFkvr6GAsWNMgVqy/8Z3u799c7MXv2iEmu0QQP9oYSBMlKwzn YVeQLbKfxct1yOf7kOpEZC/EnUw73JvbS0Jb3abUTUJggN4IYeX0se/OgL2iEkNfSSg0 csEg==
X-Gm-Message-State: AEkoouu5m9i03v0b1A4XUdRLcCRl+nxpWqSD8gdmSuqePhyrUhePDHoiiIke5cw6NYYD3ADLgdJZlBM3XkiAhw==
X-Received: by 10.31.175.1 with SMTP id y1mr1738843vke.123.1471540870523; Thu, 18 Aug 2016 10:21:10 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Thu, 18 Aug 2016 10:21:09 -0700 (PDT)
In-Reply-To: 
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>  <0E8E72CF-1928-4AB9-A804-338069004B5E@juniper.net> <74A9033D-D02F-4B57-9FB3-AC4CD7090BB1@broadband-forum.org>  
From: Andy Bierman 
Date: Thu, 18 Aug 2016 10:21:09 -0700
Message-ID: 
To: William Lupton 
Content-Type: multipart/alternative; boundary=001a114413b4dc4e98053a5bcebb
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Aug 2016 17:21:16 -0000

--001a114413b4dc4e98053a5bcebb
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,

So this is the test that is supposed to replace 5.8, para 7:

   It is acceptable to reuse the same revision statement within
   unpublished versions (i.e., Internet-Drafts), but the revision date
   MUST be updated to a higher value each time the Internet-Draft is re-
   posted.


IMO the new text is worse.

I like the suggestion to define "published" and "unpublished"
to have the semantics defined in RFC 2026.



Andy

On Thu, Aug 18, 2016 at 10:08 AM, William Lupton <
wlupton@broadband-forum.org> wrote:

> Thanks. Of course I am fine with this suggestion. This gives:
>
> NEW:
>
> It is not required to keep the full revision history of draft versions
> (e.g., modules contained within Internet-Drafts). That is, within a
> sequence of draft versions, only the most recent revision need be recorde=
d
> in the module. However, if the module has changed, the revision date of t=
he
> most recent revision MUST be updated to a later date whenever a new versi=
on
> is made available (e.g., via a new version of an Internet-Draft).
>
> > On 18 Aug 2016, at 13:21, Ladislav Lhotka  wrote:
> >
> > William Lupton  writes:
> >
> >> Kent, all,
> >>
> >> OK :). I will take Lada=E2=80=99s update to my Monday text as a baseli=
ne and
> will give my proposed new text without further ado, followed by rationale=
.
> >>
> >> BASELINE:
> >>
> >> It is not required to keep the revision history of unpublished version=
s
> (e.g., Internet-Drafts). That is, within a sequence of unpublished
> versions, only the most recent revision MAY be recorded in the module or
> submodule. However, the revision date of the most recent revision MUST be
> updated to a higher value each time a new version (e.g., of the
> Internet-Draft) is posted.
> >>
> >> NEW:
> >>
> >> It is not required to keep the full revision history of draft versions
> >> (e.g., modules contained within Internet-Drafts). That is, within a
> >> sequence of draft versions, only the most recent revision need be
> >> recorded in the module. However, if the module has changed, the
> >> revision date of the most recent revision MUST be updated to a higher
> >> value whenever a new version is made available (e.g., via a new
> >> version of an Internet-Draft).
> >
> > I like this text. Perhaps "a higher value" could be replaced with "a
> > later date"?
> >
> > Lada
> >
> >>
> >> =E2=80=94=E2=80=94
> >>
> >> The main comments and suggestions on the baseline text were:
> >> Why say MAY rather than MUST? Suggestion to say =E2=80=9Cneed=E2=80=9D=
 to avoid
> difficulty with =E2=80=9Conly=E2=80=9D and =E2=80=9CMAY=E2=80=9D.
> >> Should be more precise re the difference between a draft and a module
> contained within a draft.
> >> Should allow or encourage the module revision date to be bumped only i=
f
> the YANG has changed (or on the containing draft becoming a standard).
> >> Discussion of =E2=80=9Cpublished=E2=80=9D / =E2=80=9Cposted=E2=80=9D e=
tc., and their meanings in an
> IETF context.
> >> Support for the principle that the text should be both general
> (applying to all organisations) and specific (applying to IETF) and note
> that IETF-specific text should be parenthesised.
> >> Assertion that all publicly-available =E2=80=9Cadopted=E2=80=9D module=
s (whether draft
> or standard) must bump revision dates if the YANG changes.
> >>
> >> Here are a few notes to forestall some of your possible comments:
> >> I didn=E2=80=99t mention submodules, because of the generic (Section 2=
.3) note
> that =E2=80=9Cmodule=E2=80=9D means =E2=80=9Cmodule or submodule=E2=80=9D=
 unless specifically discussing
> submodules.
> >> I didn=E2=80=99t mention RFC publication as a special case (revision d=
ate MUST
> be unconditionally updated) because this paragraph is only about drafts. =
I
> assume that requirements governing modules in RFCs are already covered
> elsewhere.
> >> I hope that I avoided IETF-emotive terms outside the parentheses, e.g =
I
> used the terms =E2=80=9Cdraft=E2=80=9D and =E2=80=9Cmade available=E2=80=
=9D.
> >> I nearly added =E2=80=9Cstatement=E2=80=9D as in =E2=80=9Crevision dat=
e of the most recent
> revision statement=E2=80=9D. I would certainly be happy with that change.
> >> I don=E2=80=99t really like =E2=80=9Chigher value=E2=80=9D because tha=
t makes it sounds like a
> numeric value. However, no-one has commented on this and I guess it=E2=80=
=99s
> unambiguous. So let fido sleep on.
> >>
> >> Comments?
> >>
> >> Thanks,
> >> William
> >>
> >>> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
> >>>
> >>> Hi William,
> >>>
> >>> Do you want to take a stab on consolidating on the comments into new
> proposed draft-text?  - there were two proposals put out before, and a
> number of refinements since, but I=E2=80=99m unsure which were picked up =
or not.
> Since you raised this issue originally, if would be helpful to get your
> current take on it.
> >>>
> >>> Thanks,
> >>> Kent
> >> _______________________________________________
> >> 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
>

--001a114413b4dc4e98053a5bcebb
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

So this is the test that is suppose=
d to replace 5.8, para 7:

   It is acceptable to re=
use the same revision statement within
   unpublished versions (i.e., Internet-Drafts), but the revision date
   MUST be updated to a higher value each time the Internet-Draft is re-
   posted.


IMO the new text is worse.

I like the suggestion to define "published" and "un=
published"
to have the semantics defined in RFC 2026.
<=
div>


Andy

<=
div class=3D"gmail_extra">
On Thu, Aug 18, 2016 a=
t 10:08 AM, William Lupton <wlupton@broadband-forum.org><=
/span> wrote:
Thanks. Of course I am fine with this sug=
gestion. This gives:



NEW:



It is not required to keep the full revision history of draft versions (e.g=
., modules contained within Internet-Drafts). That is, within a sequence of=
 draft versions, only the most recent revision need be recorded in the modu=
le. However, if the module has changed, the revision date of the most recen=
t revision MUST be updated to a later date whenever a new version is made a=
vailable (e.g., via a new version of an Internet-Draft).



> On 18 Aug 2016, at 13:21, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> William Lupton <wlup=
ton@broadband-forum.org> writes:

>

>> Kent, all,

>>

>> OK :). I will take Lada=E2=80=99s update to my Monday text as a ba=
seline and will give my proposed new text without further ado, followed by =
rationale.

>>

>> BASELINE:

>>

>> It is not required to keep the revision history of unpublished ver=
sions (e.g., Internet-Drafts). That is, within a sequence of unpublished ve=
rsions, only the most recent revision MAY be recorded in the module or subm=
odule. However, the revision date of the most recent revision MUST be updat=
ed to a higher value each time a new version (e.g., of the Internet-Draft) =
is posted.

>>

>> NEW:

>>

>> It is not required to keep the full revision history of draft vers=
ions

>> (e.g., modules contained within Internet-Drafts). That is, within =
a

>> sequence of draft versions, only the most recent revision need be<=
br>
>> recorded in the module. However, if the module has changed, the
>> revision date of the most recent revision MUST be updated to a hig=
her

>> value whenever a new version is made available (e.g., via a new
>> version of an Internet-Draft).

>

> I like this text. Perhaps "a higher value" could be replaced=
 with "a

> later date"?

>

> Lada

>

>>

>> =E2=80=94=E2=80=94

>>

>> The main comments and suggestions on the baseline text were:

>> Why say MAY rather than MUST? Suggestion to say =E2=80=9Cneed=E2=
=80=9D to avoid difficulty with =E2=80=9Conly=E2=80=9D and =E2=80=9CMAY=E2=
=80=9D.

>> Should be more precise re the difference between a draft and a mod=
ule contained within a draft.

>> Should allow or encourage the module revision date to be bumped on=
ly if the YANG has changed (or on the containing draft becoming a standard)=
.

>> Discussion of =E2=80=9Cpublished=E2=80=9D / =E2=80=9Cposted=E2=80=
=9D etc., and their meanings in an IETF context.

>> Support for the principle that the text should be both general (ap=
plying to all organisations) and specific (applying to IETF) and note that =
IETF-specific text should be parenthesised.

>> Assertion that all publicly-available =E2=80=9Cadopted=E2=80=9D mo=
dules (whether draft or standard) must bump revision dates if the YANG chan=
ges.

>>

>> Here are a few notes to forestall some of your possible comments:<=
br>
>> I didn=E2=80=99t mention submodules, because of the generic (Secti=
on 2.3) note that =E2=80=9Cmodule=E2=80=9D means =E2=80=9Cmodule or submodu=
le=E2=80=9D unless specifically discussing submodules.

>> I didn=E2=80=99t mention RFC publication as a special case (revisi=
on date MUST be unconditionally updated) because this paragraph is only abo=
ut drafts. I assume that requirements governing modules in RFCs are already=
 covered elsewhere.

>> I hope that I avoided IETF-emotive terms outside the parentheses, =
e.g I used the terms =E2=80=9Cdraft=E2=80=9D and =E2=80=9Cmade available=E2=
=80=9D.

>> I nearly added =E2=80=9Cstatement=E2=80=9D as in =E2=80=9Crevision=
 date of the most recent revision statement=E2=80=9D. I would certainly be =
happy with that change.

>> I don=E2=80=99t really like =E2=80=9Chigher value=E2=80=9D because=
 that makes it sounds like a numeric value. However, no-one has commented o=
n this and I guess it=E2=80=99s unambiguous. So let fido sleep on.

>>

>> Comments?

>>

>> Thanks,

>> William

>>

>>> On 16 Aug 2016, at 19:02, Kent Watsen <kwatsen@juniper.net> wrote:

>>>

>>> Hi William,

>>>

>>> Do you want to take a stab on consolidating on the comments in=
to new proposed draft-text?=C2=A0 - there were two proposals put out before=
, and a number of refinements since, but I=E2=80=99m unsure which were pick=
ed up or not.=C2=A0 Since you raised this issue originally, if would be hel=
pful to get your current take on it.

>>>

>>> Thanks,

>>> Kent

>> _______________________________________________

>> netmod mailing list

>> netmod@ietf.org

>> https://www.ietf.org/mailman/listinfo/netm=
od

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a114413b4dc4e98053a5bcebb--


From nobody Thu Aug 18 10:26: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 0928712D1BE for ; Thu, 18 Aug 2016 10:26:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 k7KJ-YDrhqqd for ; Thu, 18 Aug 2016 10:26:16 -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 EDC4F12DA71 for ; Thu, 18 Aug 2016 10:26:15 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 256281E5A22; Thu, 18 Aug 2016 10:22:20 -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 NJhXBsqBoe2K; Thu, 18 Aug 2016 10:22:20 -0700 (PDT)
Received: from [192.168.1.129] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id EAED91E5A0A; Thu, 18 Aug 2016 10:22:18 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_C2B2B039-1B0A-49E6-8E0C-FB7991EE90FA"
From: William Lupton 
In-Reply-To: 
Date: Thu, 18 Aug 2016 18:26:12 +0100
Message-Id: 
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>  <0E8E72CF-1928-4AB9-A804-338069004B5E@juniper.net> <74A9033D-D02F-4B57-9FB3-AC4CD7090BB1@broadband-forum.org>   
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Aug 2016 17:26:22 -0000

--Apple-Mail=_C2B2B039-1B0A-49E6-8E0C-FB7991EE90FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Oh dear :(. What do you think about this, which is what I really care =
about?

=E2=80=94=20
Regardless of the discussion about =E2=80=9Cpublished=E2=80=9D, other =
organisations may be planning to use YANG modules that are currently =
within IDs. Obviously it=E2=80=99s vastly preferable if such IDs become =
RFCs before these other organisations publish any specifications or data =
models that use such draft IETF YANG, but it might occasionally be =
necessary to reference a draft model (hopefully one that has already =
been sent for AD review) in a published standard. This is why I would =
like the clarification to cover IDs (at least WG-adopted ones)!
=E2=80=94=20

William

> On 18 Aug 2016, at 18:21, Andy Bierman  wrote:
>=20
> Hi,
>=20
> So this is the test that is supposed to replace 5.8, para 7:
>=20
>    It is acceptable to reuse the same revision statement within
>    unpublished versions (i.e., Internet-Drafts), but the revision date
>    MUST be updated to a higher value each time the Internet-Draft is =
re-
>    posted.
>=20
> IMO the new text is worse.
>=20
> I like the suggestion to define "published" and "unpublished"
> to have the semantics defined in RFC 2026.
>=20
>=20
>=20
> Andy
>=20
> On Thu, Aug 18, 2016 at 10:08 AM, William Lupton =
> =
wrote:
> Thanks. Of course I am fine with this suggestion. This gives:
>=20
> NEW:
>=20
> It is not required to keep the full revision history of draft versions =
(e.g., modules contained within Internet-Drafts). That is, within a =
sequence of draft versions, only the most recent revision need be =
recorded in the module. However, if the module has changed, the revision =
date of the most recent revision MUST be updated to a later date =
whenever a new version is made available (e.g., via a new version of an =
Internet-Draft).
>=20
> > On 18 Aug 2016, at 13:21, Ladislav Lhotka > wrote:
> >
> > William Lupton > writes:
> >
> >> Kent, all,
> >>
> >> OK :). I will take Lada=E2=80=99s update to my Monday text as a =
baseline and will give my proposed new text without further ado, =
followed by rationale.
> >>
> >> BASELINE:
> >>
> >> It is not required to keep the revision history of unpublished =
versions (e.g., Internet-Drafts). That is, within a sequence of =
unpublished versions, only the most recent revision MAY be recorded in =
the module or submodule. However, the revision date of the most recent =
revision MUST be updated to a higher value each time a new version =
(e.g., of the Internet-Draft) is posted.
> >>
> >> NEW:
> >>
> >> It is not required to keep the full revision history of draft =
versions
> >> (e.g., modules contained within Internet-Drafts). That is, within a
> >> sequence of draft versions, only the most recent revision need be
> >> recorded in the module. However, if the module has changed, the
> >> revision date of the most recent revision MUST be updated to a =
higher
> >> value whenever a new version is made available (e.g., via a new
> >> version of an Internet-Draft).
> >
> > I like this text. Perhaps "a higher value" could be replaced with "a
> > later date"?
> >
> > Lada
> >
> >>
> >> =E2=80=94=E2=80=94
> >>
> >> The main comments and suggestions on the baseline text were:
> >> Why say MAY rather than MUST? Suggestion to say =E2=80=9Cneed=E2=80=9D=
 to avoid difficulty with =E2=80=9Conly=E2=80=9D and =E2=80=9CMAY=E2=80=9D=
.
> >> Should be more precise re the difference between a draft and a =
module contained within a draft.
> >> Should allow or encourage the module revision date to be bumped =
only if the YANG has changed (or on the containing draft becoming a =
standard).
> >> Discussion of =E2=80=9Cpublished=E2=80=9D / =E2=80=9Cposted=E2=80=9D =
etc., and their meanings in an IETF context.
> >> Support for the principle that the text should be both general =
(applying to all organisations) and specific (applying to IETF) and note =
that IETF-specific text should be parenthesised.
> >> Assertion that all publicly-available =E2=80=9Cadopted=E2=80=9D =
modules (whether draft or standard) must bump revision dates if the YANG =
changes.
> >>
> >> Here are a few notes to forestall some of your possible comments:
> >> I didn=E2=80=99t mention submodules, because of the generic =
(Section 2.3) note that =E2=80=9Cmodule=E2=80=9D means =E2=80=9Cmodule =
or submodule=E2=80=9D unless specifically discussing submodules.
> >> I didn=E2=80=99t mention RFC publication as a special case =
(revision date MUST be unconditionally updated) because this paragraph =
is only about drafts. I assume that requirements governing modules in =
RFCs are already covered elsewhere.
> >> I hope that I avoided IETF-emotive terms outside the parentheses, =
e.g I used the terms =E2=80=9Cdraft=E2=80=9D and =E2=80=9Cmade =
available=E2=80=9D.
> >> I nearly added =E2=80=9Cstatement=E2=80=9D as in =E2=80=9Crevision =
date of the most recent revision statement=E2=80=9D. I would certainly =
be happy with that change.
> >> I don=E2=80=99t really like =E2=80=9Chigher value=E2=80=9D because =
that makes it sounds like a numeric value. However, no-one has commented =
on this and I guess it=E2=80=99s unambiguous. So let fido sleep on.
> >>
> >> Comments?
> >>
> >> Thanks,
> >> William
> >>
> >>> On 16 Aug 2016, at 19:02, Kent Watsen > wrote:
> >>>
> >>> Hi William,
> >>>
> >>> Do you want to take a stab on consolidating on the comments into =
new proposed draft-text?  - there were two proposals put out before, and =
a number of refinements since, but I=E2=80=99m unsure which were picked =
up or not.  Since you raised this issue originally, if would be helpful =
to get your current take on it.
> >>>
> >>> Thanks,
> >>> Kent
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org 
> >> https://www.ietf.org/mailman/listinfo/netmod =

> >
> > --
> > Ladislav Lhotka, CZ.NIC Labs
> > PGP Key ID: E74E8C0C
> >
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =

>=20


--Apple-Mail=_C2B2B039-1B0A-49E6-8E0C-FB7991EE90FA
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Oh dear :(. What do you think about this, which is what I =
really care about?

=E2=80=94 
Regardless of the =
discussion about =E2=80=9Cpublished=E2=80=9D, other organisations may be =
planning to use YANG modules that are currently within IDs. Obviously =
it=E2=80=99s vastly preferable if such IDs become RFCs before these =
other organisations publish any specifications or data models that use =
such draft IETF YANG, but it might occasionally be necessary to =
reference a draft model (hopefully one that has already been sent =
for AD review) in a published standard. This is why I would like the =
clarification to cover IDs (at least WG-adopted ones)!
=E2=80=94 

William

On 18 Aug 2016, at 18:21, Andy =
Bierman <andy@yumaworks.com> wrote:

Hi,

So =
this is the test that is supposed to replace 5.8, para 7:

   It is acceptable to =
reuse the same revision statement within
   unpublished versions (i.e., Internet-Drafts), but the revision date
   MUST be updated to a higher value each time the Internet-Draft is re-
   posted.


IMO the =
new text is worse.

I like the suggestion to define "published" and =
"unpublished"
to have the semantics defined in RFC =
2026.



Andy

On Thu, Aug 18, 2016 at =
10:08 AM, William Lupton <wlupton@broadband-forum.org> wrote:
Thanks. Of course I am fine with this =
suggestion. This gives:



NEW:



It is not required to keep the full revision history of draft versions =
(e.g., modules contained within Internet-Drafts). That is, within a =
sequence of draft versions, only the most recent revision need be =
recorded in the module. However, if the module has changed, the revision =
date of the most recent revision MUST be updated to a later date =
whenever a new version is made available (e.g., via a new version of an =
Internet-Draft).



> On 18 Aug 2016, at 13:21, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> William Lupton <wlupton@broadband-forum.org> writes:

>

>> Kent, all,

>>

>> OK :). I will take Lada=E2=80=99s update to my Monday text as a =
baseline and will give my proposed new text without further ado, =
followed by rationale.

>>

>> BASELINE:

>>

>> It is not required to keep the revision history of unpublished =
versions (e.g., Internet-Drafts). That is, within a sequence of =
unpublished versions, only the most recent revision MAY be recorded in =
the module or submodule. However, the revision date of the most recent =
revision MUST be updated to a higher value each time a new version =
(e.g., of the Internet-Draft) is posted.

>>

>> NEW:

>>

>> It is not required to keep the full revision history of draft =
versions

>> (e.g., modules contained within Internet-Drafts). That is, =
within a

>> sequence of draft versions, only the most recent revision need =
be

>> recorded in the module. However, if the module has changed, =
the

>> revision date of the most recent revision MUST be updated to a =
higher

>> value whenever a new version is made available (e.g., via a =
new

>> version of an Internet-Draft).

>

> I like this text. Perhaps "a higher value" could be replaced with =
"a

> later date"?

>

> Lada

>

>>

>> =E2=80=94=E2=80=94

>>

>> The main comments and suggestions on the baseline text were:

>> Why say MAY rather than MUST? Suggestion to say =E2=80=9Cneed=E2=80=
=9D to avoid difficulty with =E2=80=9Conly=E2=80=9D and =E2=80=9CMAY=E2=80=
=9D.

>> Should be more precise re the difference between a draft and a =
module contained within a draft.

>> Should allow or encourage the module revision date to be bumped =
only if the YANG has changed (or on the containing draft becoming a =
standard).

>> Discussion of =E2=80=9Cpublished=E2=80=9D / =E2=80=9Cposted=E2=80=
=9D etc., and their meanings in an IETF context.

>> Support for the principle that the text should be both general =
(applying to all organisations) and specific (applying to IETF) and note =
that IETF-specific text should be parenthesised.

>> Assertion that all publicly-available =E2=80=9Cadopted=E2=80=9D =
modules (whether draft or standard) must bump revision dates if the YANG =
changes.

>>

>> Here are a few notes to forestall some of your possible =
comments:

>> I didn=E2=80=99t mention submodules, because of the generic =
(Section 2.3) note that =E2=80=9Cmodule=E2=80=9D means =E2=80=9Cmodule =
or submodule=E2=80=9D unless specifically discussing submodules.

>> I didn=E2=80=99t mention RFC publication as a special case =
(revision date MUST be unconditionally updated) because this paragraph =
is only about drafts. I assume that requirements governing modules in =
RFCs are already covered elsewhere.

>> I hope that I avoided IETF-emotive terms outside the =
parentheses, e.g I used the terms =E2=80=9Cdraft=E2=80=9D and =E2=80=9Cmad=
e available=E2=80=9D.

>> I nearly added =E2=80=9Cstatement=E2=80=9D as in =E2=80=9Crevisio=
n date of the most recent revision statement=E2=80=9D. I would certainly =
be happy with that change.

>> I don=E2=80=99t really like =E2=80=9Chigher value=E2=80=9D =
because that makes it sounds like a numeric value. However, no-one has =
commented on this and I guess it=E2=80=99s unambiguous. So let fido =
sleep on.

>>

>> Comments?

>>

>> Thanks,

>> William

>>

>>> On 16 Aug 2016, at 19:02, Kent Watsen <kwatsen@juniper.net>=
 wrote:

>>>

>>> Hi William,

>>>

>>> Do you want to take a stab on consolidating on the comments =
into new proposed draft-text?  - there were two proposals put out =
before, and a number of refinements since, but I=E2=80=99m unsure which =
were picked up or not.  Since you raised this issue originally, if =
would be helpful to get your current take on it.

>>>

>>> Thanks,

>>> Kent

>> _______________________________________________

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






=

--Apple-Mail=_C2B2B039-1B0A-49E6-8E0C-FB7991EE90FA--


From nobody Thu Aug 18 10:58: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 CAF8312DA56 for ; Thu, 18 Aug 2016 10:58: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, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BYBMoHA8V8EA for ; Thu, 18 Aug 2016 10:58:02 -0700 (PDT)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 4669812D733 for ; Thu, 18 Aug 2016 10:56:51 -0700 (PDT)
Received: by mail-ua0-x22e.google.com with SMTP id 97so40693308uav.3 for ; Thu, 18 Aug 2016 10:56: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:from:date:message-id:subject:to :cc; bh=U/+HoXaw3JstRAZcIi6Jw4aWVkp1EPAMgyYfhsSToR8=; b=nRYX96/0FBU+qQllHX4KR3toXWS1d1MK3TtmXh8kBR/5V80hU7eOKpKXOO6x3pznHj RTph/NRpKJCTplPnY7CRBB2+5OBkw48cAgwq2RfqVJk/5hRVhHJMQEGCBqagWBN7x5dI NCDLb8LJE/XlDLRebhNMWa8Lvi7rGdsaQVqscfvfC155vsepAeTFdq+baxJQsMSmiAL+ gaRp2IIByX+AsSNcoi1H1QxOTDKeukrC6vz7SvLiK/neGR+xAWnVnx86hDpTumndH9pI MHZfZ3KKrlcUiR7SOklUNmhsUmjxwcyKnjwvnVVyryniwv1FTwMci7FzWxCON/NmPtxu gY4Q==
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:from:date :message-id:subject:to:cc; bh=U/+HoXaw3JstRAZcIi6Jw4aWVkp1EPAMgyYfhsSToR8=; b=mUrd23oqz2BjAcx3alWcAsCcFRuvZXA+g6tsBJYD7m+JyUpatTuOLjtBqkp1woNKzK 1MFBoxh5ZyDvzly/OEwgsL+/kgivtfNm4QfW70EeHPV+H0UpYM5Q2rzXGHWCXrEln/wo wDA02Rgnx6ugmKLVd54cYg7aIOz1P253mkYMhiW/5mlyF0koSTRnkfsweAjCP5m6vufe VJexi1ZTf2Gvpc77CwJzgEpXGkjk6YptMa0o6CoEmGuHr6IAnQ4FFumpG8Ow2IuoCFkx 6S/fvT4yeXH+D609pb+NONLye0DsXh+k7GCz14g4QLzSW9NviOZra9dpyzKoFmI3lzZR MC6w==
X-Gm-Message-State: AEkoouul8Lf9shkWpv0fMn9r8Sa1YdXwJuFfZGPmHa3r/h6nQl6aXkyN3xX7wK+C1z7xgaRFq+J6QG9iIBplAg==
X-Received: by 10.31.192.202 with SMTP id q193mr1470051vkf.44.1471543010300; Thu, 18 Aug 2016 10:56:50 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Thu, 18 Aug 2016 10:56:49 -0700 (PDT)
In-Reply-To: 
References:  <394632ad-2c2f-22bd-eb4f-c01ba98dcd26@alumni.stanford.edu> <315BC692-B3CE-40F5-A9A3-59776B4C8106@broadband-forum.org> <5d6d9fdb-f909-1488-fb7b-4f587ec977d2@alumni.stanford.edu> <81A5CA61-B028-4A5D-93AD-B75D246FBC4D@broadband-forum.org> <96AAB9C5-A9EC-4A10-A2AB-6C2433869993@nic.cz> <51d0a2d8-03c1-bf1e-f3d0-01a996e4f808@alumni.stanford.edu> <0F2F257D-5FBF-4985-B13B-1CD624864710@juniper.net>  <0E8E72CF-1928-4AB9-A804-338069004B5E@juniper.net> <74A9033D-D02F-4B57-9FB3-AC4CD7090BB1@broadband-forum.org>    
From: Andy Bierman 
Date: Thu, 18 Aug 2016 10:56:49 -0700
Message-ID: 
To: William Lupton 
Content-Type: multipart/alternative; boundary=001a114398de673730053a5c4ee2
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 18 Aug 2016 17:58:44 -0000

--001a114398de673730053a5c4ee2
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Hi,


IMO it is not useful to have lots of
copies of a module that just differ by revision date.


   It is acceptable to reuse the same revision statement within
   unpublished versions (e.g., Internet-Drafts), but the revision date
   MUST be updated to a higher value each time the YANG module is changed.
   The revision date MAY be updated if nothing in the module has changed.



Andy


On Thu, Aug 18, 2016 at 10:26 AM, William Lupton <
wlupton@broadband-forum.org> wrote:

> Oh dear :(. What do you think about this, which is what I really care
> about?
>
> =E2=80=94
> Regardless of the discussion about =E2=80=9Cpublished=E2=80=9D, other org=
anisations may be
> planning to use YANG modules that are currently within IDs. Obviously it=
=E2=80=99s
> vastly preferable if such IDs become RFCs before these other organisation=
s
> publish any specifications or data models that use such draft IETF YANG,
> but it might occasionally be necessary to reference a draft model
> (hopefully one that has already been sent for AD review) in a published
> standard. This is why I would like the clarification to cover IDs (at lea=
st
> WG-adopted ones)!
> =E2=80=94
>
> William
>
> On 18 Aug 2016, at 18:21, Andy Bierman  wrote:
>
> Hi,
>
> So this is the test that is supposed to replace 5.8, para 7:
>
>    It is acceptable to reuse the same revision statement within
>    unpublished versions (i.e., Internet-Drafts), but the revision date
>    MUST be updated to a higher value each time the Internet-Draft is re-
>    posted.
>
>
> IMO the new text is worse.
>
> I like the suggestion to define "published" and "unpublished"
> to have the semantics defined in RFC 2026.
>
>
>
> Andy
>
> On Thu, Aug 18, 2016 at 10:08 AM, William Lupton <
> wlupton@broadband-forum.org> wrote:
>
>> Thanks. Of course I am fine with this suggestion. This gives:
>>
>> NEW:
>>
>> It is not required to keep the full revision history of draft versions
>> (e.g., modules contained within Internet-Drafts). That is, within a
>> sequence of draft versions, only the most recent revision need be record=
ed
>> in the module. However, if the module has changed, the revision date of =
the
>> most recent revision MUST be updated to a later date whenever a new vers=
ion
>> is made available (e.g., via a new version of an Internet-Draft).
>>
>> > On 18 Aug 2016, at 13:21, Ladislav Lhotka  wrote:
>> >
>> > William Lupton  writes:
>> >
>> >> Kent, all,
>> >>
>> >> OK :). I will take Lada=E2=80=99s update to my Monday text as a basel=
ine and
>> will give my proposed new text without further ado, followed by rational=
e.
>> >>
>> >> BASELINE:
>> >>
>> >> It is not required to keep the revision history of unpublished
>> versions (e.g., Internet-Drafts). That is, within a sequence of unpublis=
hed
>> versions, only the most recent revision MAY be recorded in the module or
>> submodule. However, the revision date of the most recent revision MUST b=
e
>> updated to a higher value each time a new version (e.g., of the
>> Internet-Draft) is posted.
>> >>
>> >> NEW:
>> >>
>> >> It is not required to keep the full revision history of draft version=
s
>> >> (e.g., modules contained within Internet-Drafts). That is, within a
>> >> sequence of draft versions, only the most recent revision need be
>> >> recorded in the module. However, if the module has changed, the
>> >> revision date of the most recent revision MUST be updated to a higher
>> >> value whenever a new version is made available (e.g., via a new
>> >> version of an Internet-Draft).
>> >
>> > I like this text. Perhaps "a higher value" could be replaced with "a
>> > later date"?
>> >
>> > Lada
>> >
>> >>
>> >> =E2=80=94=E2=80=94
>> >>
>> >> The main comments and suggestions on the baseline text were:
>> >> Why say MAY rather than MUST? Suggestion to say =E2=80=9Cneed=E2=80=
=9D to avoid
>> difficulty with =E2=80=9Conly=E2=80=9D and =E2=80=9CMAY=E2=80=9D.
>> >> Should be more precise re the difference between a draft and a module
>> contained within a draft.
>> >> Should allow or encourage the module revision date to be bumped only
>> if the YANG has changed (or on the containing draft becoming a standard)=
.
>> >> Discussion of =E2=80=9Cpublished=E2=80=9D / =E2=80=9Cposted=E2=80=9D =
etc., and their meanings in an
>> IETF context.
>> >> Support for the principle that the text should be both general
>> (applying to all organisations) and specific (applying to IETF) and note
>> that IETF-specific text should be parenthesised.
>> >> Assertion that all publicly-available =E2=80=9Cadopted=E2=80=9D modul=
es (whether draft
>> or standard) must bump revision dates if the YANG changes.
>> >>
>> >> Here are a few notes to forestall some of your possible comments:
>> >> I didn=E2=80=99t mention submodules, because of the generic (Section =
2.3) note
>> that =E2=80=9Cmodule=E2=80=9D means =E2=80=9Cmodule or submodule=E2=80=
=9D unless specifically discussing
>> submodules.
>> >> I didn=E2=80=99t mention RFC publication as a special case (revision =
date MUST
>> be unconditionally updated) because this paragraph is only about drafts.=
 I
>> assume that requirements governing modules in RFCs are already covered
>> elsewhere.
>> >> I hope that I avoided IETF-emotive terms outside the parentheses, e.g
>> I used the terms =E2=80=9Cdraft=E2=80=9D and =E2=80=9Cmade available=E2=
=80=9D.
>> >> I nearly added =E2=80=9Cstatement=E2=80=9D as in =E2=80=9Crevision da=
te of the most recent
>> revision statement=E2=80=9D. I would certainly be happy with that change=
.
>> >> I don=E2=80=99t really like =E2=80=9Chigher value=E2=80=9D because th=
at makes it sounds like a
>> numeric value. However, no-one has commented on this and I guess it=E2=
=80=99s
>> unambiguous. So let fido sleep on.
>> >>
>> >> Comments?
>> >>
>> >> Thanks,
>> >> William
>> >>
>> >>> On 16 Aug 2016, at 19:02, Kent Watsen  wrote:
>> >>>
>> >>> Hi William,
>> >>>
>> >>> Do you want to take a stab on consolidating on the comments into new
>> proposed draft-text?  - there were two proposals put out before, and a
>> number of refinements since, but I=E2=80=99m unsure which were picked up=
 or not.
>> Since you raised this issue originally, if would be helpful to get your
>> current take on it.
>> >>>
>> >>> Thanks,
>> >>> Kent
>> >> _______________________________________________
>> >> 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
>>
>
>
>

--001a114398de673730053a5c4ee2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,


IMO it is not useful=
 to have lots of
copies of a module that just differ by revision =
date.

   It is acceptable=
 to reuse the same revision statement within
   unpublished versions (e.g., Internet-Drafts), but the revision date
   MUST be updated to a higher value each time the YANG module is changed.
   The revision date MAY be updated if nothing in the module has changed.


Andy
<=
div>

On Thu, Aug 18, 2016 at 10:26 AM, William Lupton <wlupton@broa=
dband-forum.org> wrote:
Oh dear :(. What do you think about this, which is what =
I really care about?

=E2=80=94=C2=A0
Regardles=
s of the discussion about =E2=80=9Cpublished=E2=80=9D, other organisations =
may be planning to use YANG modules that are currently within IDs. Obviousl=
y it=E2=80=99s vastly preferable if such IDs become RFCs=C2=A0before these =
other organisations publish any specifications or data models that use such=
 draft IETF YANG, but it might occasionally be necessary to reference a dra=
ft model (hopefully one that has=C2=A0already been sent for AD review) in a=
 published standard. This is why I would like the clarification to cover ID=
s (at least WG-adopted ones)!
=E2=80=94=C2=A0

William

On 18 Aug 2=
016, at 18:21, Andy Bierman <andy@yumaworks.com> wrote:

Hi,

So this is the test that is supposed to replace 5=
.8, para 7:

   It is acceptable to reuse the same revision statement=
 within
   unpublished versions (i.e., Internet-Drafts), but the revision date
   MUST be updated to a higher value each time the Internet-Draft is re-
   posted.


IMO the new text is worse.

I like the suggestion to define "published" and "un=
published"
to have the semantics defined in RFC 2026.
<=
div>


Andy

<=
div class=3D"gmail_extra">
On Thu, Aug 18, 2016 a=
t 10:08 AM, William Lupton <wlupton@broadband-forum.org><=
/span> wrote:
Thanks. Of course I am fine with this sug=
gestion. This gives:



NEW:



It is not required to keep the full revision history of draft versions (e.g=
., modules contained within Internet-Drafts). That is, within a sequence of=
 draft versions, only the most recent revision need be recorded in the modu=
le. However, if the module has changed, the revision date of the most recen=
t revision MUST be updated to a later date whenever a new version is made a=
vailable (e.g., via a new version of an Internet-Draft).



> On 18 Aug 2016, at 13:21, Ladislav Lhotka <lhotka@nic.cz> wrote:

>

> William Lupton <wlupton@broadband-forum.org> writes:

>

>> Kent, all,

>>

>> OK :). I will take Lada=E2=80=99s update to my Monday text as a ba=
seline and will give my proposed new text without further ado, followed by =
rationale.

>>

>> BASELINE:

>>

>> It is not required to keep the revision history of unpublished ver=
sions (e.g., Internet-Drafts). That is, within a sequence of unpublished ve=
rsions, only the most recent revision MAY be recorded in the module or subm=
odule. However, the revision date of the most recent revision MUST be updat=
ed to a higher value each time a new version (e.g., of the Internet-Draft) =
is posted.

>>

>> NEW:

>>

>> It is not required to keep the full revision history of draft vers=
ions

>> (e.g., modules contained within Internet-Drafts). That is, within =
a

>> sequence of draft versions, only the most recent revision need be<=
br>
>> recorded in the module. However, if the module has changed, the
>> revision date of the most recent revision MUST be updated to a hig=
her

>> value whenever a new version is made available (e.g., via a new
>> version of an Internet-Draft).

>

> I like this text. Perhaps "a higher value" could be replaced=
 with "a

> later date"?

>

> Lada

>

>>

>> =E2=80=94=E2=80=94

>>

>> The main comments and suggestions on the baseline text were:

>> Why say MAY rather than MUST? Suggestion to say =E2=80=9Cneed=E2=
=80=9D to avoid difficulty with =E2=80=9Conly=E2=80=9D and =E2=80=9CMAY=E2=
=80=9D.

>> Should be more precise re the difference between a draft and a mod=
ule contained within a draft.

>> Should allow or encourage the module revision date to be bumped on=
ly if the YANG has changed (or on the containing draft becoming a standard)=
.

>> Discussion of =E2=80=9Cpublished=E2=80=9D / =E2=80=9Cposted=E2=80=
=9D etc., and their meanings in an IETF context.

>> Support for the principle that the text should be both general (ap=
plying to all organisations) and specific (applying to IETF) and note that =
IETF-specific text should be parenthesised.

>> Assertion that all publicly-available =E2=80=9Cadopted=E2=80=9D mo=
dules (whether draft or standard) must bump revision dates if the YANG chan=
ges.

>>

>> Here are a few notes to forestall some of your possible comments:<=
br>
>> I didn=E2=80=99t mention submodules, because of the generic (Secti=
on 2.3) note that =E2=80=9Cmodule=E2=80=9D means =E2=80=9Cmodule or submodu=
le=E2=80=9D unless specifically discussing submodules.

>> I didn=E2=80=99t mention RFC publication as a special case (revisi=
on date MUST be unconditionally updated) because this paragraph is only abo=
ut drafts. I assume that requirements governing modules in RFCs are already=
 covered elsewhere.

>> I hope that I avoided IETF-emotive terms outside the parentheses, =
e.g I used the terms =E2=80=9Cdraft=E2=80=9D and =E2=80=9Cmade available=E2=
=80=9D.

>> I nearly added =E2=80=9Cstatement=E2=80=9D as in =E2=80=9Crevision=
 date of the most recent revision statement=E2=80=9D. I would certainly be =
happy with that change.

>> I don=E2=80=99t really like =E2=80=9Chigher value=E2=80=9D because=
 that makes it sounds like a numeric value. However, no-one has commented o=
n this and I guess it=E2=80=99s unambiguous. So let fido sleep on.

>>

>> Comments?

>>

>> Thanks,

>> William

>>

>>> On 16 Aug 2016, at 19:02, Kent Watsen <kwatsen@juniper.net> wrote:

>>>

>>> Hi William,

>>>

>>> Do you want to take a stab on consolidating on the comments in=
to new proposed draft-text?=C2=A0 - there were two proposals put out before=
, and a number of refinements since, but I=E2=80=99m unsure which were pick=
ed up or not.=C2=A0 Since you raised this issue originally, if would be hel=
pful to get your current take on it.

>>>

>>> Thanks,

>>> Kent

>> _______________________________________________

>> netmod mailing list

>> netmod@ietf.o=
rg

>> https://www.ietf.org/mailman/listinfo/netm=
od

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>



_______________________________________________

netmod mailing list

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








--001a114398de673730053a5c4ee2--


From nobody Thu Aug 18 19:15: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 37FE612D5C5 for ; Thu, 18 Aug 2016 19:15:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xfej4cVkRdgW for ; Thu, 18 Aug 2016 19:15:31 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D36E112D13D for ; Thu, 18 Aug 2016 19:15:29 -0700 (PDT)
Received: from resomta-ch2-11v.sys.comcast.net ([69.252.207.107]) by resqmta-ch2-12v.sys.comcast.net with SMTP id aZLFbbJikxBKTaZLFb3w6Z; Fri, 19 Aug 2016 02:15:29 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-11v.sys.comcast.net with SMTP id aZLDbrkL2m7dBaZLEbSQKQ; Fri, 19 Aug 2016 02:15:29 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7J2FRBu002634 for ; Thu, 18 Aug 2016 22:15:27 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7J2FRqR002631; Thu, 18 Aug 2016 22:15:27 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: netmod@ietf.org
In-Reply-To:  (wlupton@broadband-forum.org)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Thu, 18 Aug 2016 22:15:26 -0400
Message-ID: <871t1ly05d.fsf@hobgoblin.ariadne.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-CMAE-Envelope: MS4wfCCs/kyw1HiLBTGkXnuJ1wAMtytrl9VKByAnlB00bQJDC11AhrYjyFPtfP5cEnAje4tL54yyxL0GFQE0OnOJmfLD/A2ZD1GUcF0MCEc0U3Hxn7M6gMde E9dZqhClG51CKn504coMGbjuZtTu6FBuSpoDtTKmuNq2RHy1Op/7peAOteAWQREiWIvCOUYRTDUbrA==
Archived-At: 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Aug 2016 02:15:32 -0000

William Lupton  writes:
> Regardless of the discussion about =E2=80=9Cpublished=E2=80=9D, other org=
anisations
> may be planning to use YANG modules that are currently within
> IDs. Obviously it=E2=80=99s vastly preferable if such IDs become RFCs bef=
ore
> these other organisations publish any specifications or data models
> that use such draft IETF YANG, but it might occasionally be necessary
> to reference a draft model (hopefully one that has already been sent
> for AD review) in a published standard. This is why I would like the
> clarification to cover IDs (at least WG-adopted ones)!

Unfortunately, this sort of problem has to be considered.  I remember
when the "SIP multiple line appearances" draft was being worked on.
Ultimately, there were products on the market that supported the -03
version, the -04 version, and the final (RFC) version.

My suggestion is that any time a version of a module is "published", it
must either be identical to the previous "published" version, or have a
newer revision date.  As far as I can see, the *practical* meaning of
"published" is a document that has a permanent URL, because you can't
convince a customer that a document is a "specification" if it doesn't
have a stable URL.  For Internet Drafts, that seems to mean each
numbered version entered into the Data Tracker.

But there is a further problem:  A sequence of versions of a module with
different revision dates are required to be related by the rules of
section 11 of RFC 6020 (or draft-ietf-netmod-rfc6020bis), i.e., each
newer version is a proper extension of the older version(s).  Clearly,
we *don't* want to have that constraint between versions of modules in a
sequence of I-Ds, we want to be able to delete elements.

Dale


From nobody Thu Aug 18 19:43: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 D826E12D6AC for ; Thu, 18 Aug 2016 19:43:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sZ40JqB7KROv for ; Thu, 18 Aug 2016 19:43:55 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 3F3A112D61D for ; Thu, 18 Aug 2016 19:43:55 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id k90so59254747uak.1 for ; Thu, 18 Aug 2016 19:43:55 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=vWV4bN/jBcAnpRB4OwYwyxBeMyH3YGn2vplfSbsXn7c=; b=HtQ2SFjawXPe4LCVRLAi/8BWxrZatYC3D2I62kaDkmoYFwh/LvDy9b+FwohlupfwuG xghl+olrOtVp5ZVSau4sbhvJECKKfhqLfRuz4Hbut540Cvc/YjgQQq+YIDQgpHY4Lcge Au2nAEf+ige6xIB4ae1JV4GEwLtt0LWQ/Tj2XfwIH5q5vdGm/A0CmZWXDHmnyCiTU8Fa UHRqLivZxjqSqqWUJ9baBmorZotYdpibGZK8DKsfyJhIS/uRvZwhVe57PKIZoSmO+lcy 02DRpPc7T/0WX8cQZ4MjdVApF69T7KRU/W1YN6yBD/OJBCaIS/UuxAps1in+UYdj1D+V jR2w==
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:from:date :message-id:subject:to:cc; bh=vWV4bN/jBcAnpRB4OwYwyxBeMyH3YGn2vplfSbsXn7c=; b=h751kdils23r76S4NnA44oZeHsJatF0KVqSM+LHH1pjuuTDudrVpv638n5+CLJ+7Cj nGmMQSbKZ/bbRP9RoNyrG2O6afUIuFXoJa+uwGNoBx7XdztyoTa3WPgehhAnZ6cLeD00 c26RZSQyoj7wHq1pBhgmATvYQuLW6va0sCi+qWEOG06ga/AoZvZGyjdlUHWpN8mHNrZb JTgS4VJUP2nDLJEsT0y9EXgkptvMuFVYFYjk0xavFcbzRRZ3kGUaOTm4lnGYRQrvH/K2 wHCHmiTHNsT8ETuv4vdfSGiUDoMCOViQOTgC1uSi9BkVUu9btEeJLzc3nziilCjweGpv b7YQ==
X-Gm-Message-State: AEkoouuIU09DTEJ+NxfwGuDaDNwr9lhBXr7mzNCbGpKsGQr33+0VI+t+2NRN/px9PbA4Z1ye+q0Uyw6XU/AF/Q==
X-Received: by 10.176.3.232 with SMTP id 95mr2916170uau.9.1471574634300; Thu, 18 Aug 2016 19:43:54 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.198 with HTTP; Thu, 18 Aug 2016 19:43:53 -0700 (PDT)
In-Reply-To: <871t1ly05d.fsf@hobgoblin.ariadne.com>
References:  <871t1ly05d.fsf@hobgoblin.ariadne.com>
From: Andy Bierman 
Date: Thu, 18 Aug 2016 19:43:53 -0700
Message-ID: 
To: "Dale R. Worley" 
Content-Type: multipart/alternative; boundary=94eb2c056550569ec8053a63ab38
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Aug 2016 02:43:58 -0000

--94eb2c056550569ec8053a63ab38
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 18, 2016 at 7:15 PM, Dale R. Worley  wrote:

> William Lupton  writes:
> > Regardless of the discussion about =E2=80=9Cpublished=E2=80=9D, other o=
rganisations
> > may be planning to use YANG modules that are currently within
> > IDs. Obviously it=E2=80=99s vastly preferable if such IDs become RFCs b=
efore
> > these other organisations publish any specifications or data models
> > that use such draft IETF YANG, but it might occasionally be necessary
> > to reference a draft model (hopefully one that has already been sent
> > for AD review) in a published standard. This is why I would like the
> > clarification to cover IDs (at least WG-adopted ones)!
>
> Unfortunately, this sort of problem has to be considered.  I remember
> when the "SIP multiple line appearances" draft was being worked on.
> Ultimately, there were products on the market that supported the -03
> version, the -04 version, and the final (RFC) version.
>
> My suggestion is that any time a version of a module is "published", it
> must either be identical to the previous "published" version, or have a
> newer revision date.  As far as I can see, the *practical* meaning of
> "published" is a document that has a permanent URL, because you can't
> convince a customer that a document is a "specification" if it doesn't
> have a stable URL.  For Internet Drafts, that seems to mean each
> numbered version entered into the Data Tracker.
>


The current text says the revision date MUST be updated
if the YANG module changed at all.  Seems clear to me.

I think I will add a reference to RFC 2026, sec. 2.2
to use the term  "published" specification

An Internet-Draft is NOT a means of "publishing" a specification;



Andy



>
> But there is a further problem:  A sequence of versions of a module with
> different revision dates are required to be related by the rules of
> section 11 of RFC 6020 (or draft-ietf-netmod-rfc6020bis), i.e., each
> newer version is a proper extension of the older version(s).  Clearly,
> we *don't* want to have that constraint between versions of modules in a
> sequence of I-Ds, we want to be able to delete elements.
>
> Dale
>
> ___________


Andy


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

--94eb2c056550569ec8053a63ab38
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Thu, Aug 18, 2016 at 7:15 PM, Dale R. Worley <<=
a href=3D"mailto:worley@ariadne.com" target=3D"_blank">worley@ariadne.com> wrote:
William Lupton <wlupton@broadband-forum.org> writes:=


> Regardless of the discussion about =E2=80=9Cpublished=E2=80=9D, other =
organisations

> may be planning to use YANG modules that are currently within

> IDs. Obviously it=E2=80=99s vastly preferable if such IDs become RFCs =
before

> these other organisations publish any specifications or data models
> that use such draft IETF YANG, but it might occasionally be necessary<=
br>
> to reference a draft model (hopefully one that has already been sent
> for AD review) in a published standard. This is why I would like the
> clarification to cover IDs (at least WG-adopted ones)!



Unfortunately, this sort of problem has to be considered.=C2=A0 I remember<=
br>
when the "SIP multiple line appearances" draft was being worked o=
n.

Ultimately, there were products on the market that supported the -03

version, the -04 version, and the final (RFC) version.



My suggestion is that any time a version of a module is "published&quo=
t;, it

must either be identical to the previous "published" version, or =
have a

newer revision date.=C2=A0 As far as I can see, the *practical* meaning of<=
br>
"published" is a document that has a permanent URL, because you c=
an't

convince a customer that a document is a "specification" if it do=
esn't

have a stable URL.=C2=A0 For Internet Drafts, that seems to mean each

numbered version entered into the Data Tracker.


The current text says the revision date MUST be upd=
ated
if the YANG module changed at all.=C2=A0 Seems clear to me.<=
/div>

I think I will add a reference to RFC 2026, sec. 2=
.2
to use the term =C2=A0"published" specification

An Internet-Draft is NOT a means of "publishing&qu=
ot; a specification;


Andy

<=
/div>
=C2=A0



But there is a further problem:=C2=A0 A sequence of versions of a module wi=
th

different revision dates are required to be related by the rules of

section 11 of RFC 6020 (or draft-ietf-netmod-rfc6020bis), i.e., each

newer version is a proper extension of the older version(s).=C2=A0 Clearly,=


we *don't* want to have that constraint between versions of modules in =
a

sequence of I-Ds, we want to be able to delete elements.



Dale



___________

Andy
=C2=A0
____________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c056550569ec8053a63ab38--


From nobody Fri Aug 19 07:14: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 C731412DA9C for ; Fri, 19 Aug 2016 07:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pfAGEsDJgXV9 for ; Fri, 19 Aug 2016 07:14:20 -0700 (PDT)
Received: from resqmta-ch2-10v.sys.comcast.net (resqmta-ch2-10v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:42]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C36F012DAE9 for ; Fri, 19 Aug 2016 07:14:00 -0700 (PDT)
Received: from resomta-ch2-16v.sys.comcast.net ([69.252.207.112]) by resqmta-ch2-10v.sys.comcast.net with SMTP id akYRbfeOIRingakYab9HeG; Fri, 19 Aug 2016 14:14:00 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-16v.sys.comcast.net with SMTP id akYYb09yXpwEGakYZbre9s; Fri, 19 Aug 2016 14:14:00 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7JEDwKe013399; Fri, 19 Aug 2016 10:13:58 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7JEDv7Q013396; Fri, 19 Aug 2016 10:13:57 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Andy Bierman 
In-Reply-To:  (andy@yumaworks.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Fri, 19 Aug 2016 10:13:57 -0400
Message-ID: <87pop4x2vu.fsf@hobgoblin.ariadne.com>
MIME-Version: 1.0
Content-Type: text/plain
X-CMAE-Envelope: MS4wfLb+ZtdC2mmKu3RNsxrpJWgmxDYgZpPj8P6nCZh7fXpgBFxnyg7Fks/zPQzESc6sj0IU5KPgcuYJJnoaJlG9/Zv3DPLQeHfE/wYOuu0BL1nw17tU15Vt wa5WCW+yuToTJb9ZskLbaVvdpR0WDo3MUSijaAiEjmgCOzSoYe09Y4GPVmZz3xeXRLa/e7vVtPP1iOABZlBf5Jhjeb7fTBfEXy0=
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Aug 2016 14:14:22 -0000

Andy Bierman  writes:
> An Internet-Draft is NOT a means of "publishing" a specification;

As I said, that's the theory, but practice is considerably different.

Dale


From nobody Fri Aug 19 07:42: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 85DD212D7BF for ; Fri, 19 Aug 2016 07:42:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id La6WP2Zu_yb7 for ; Fri, 19 Aug 2016 07:42:28 -0700 (PDT)
Received: from mail-ua0-x230.google.com (mail-ua0-x230.google.com [IPv6:2607:f8b0:400c:c08::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 AC5AA12D992 for ; Fri, 19 Aug 2016 07:42:14 -0700 (PDT)
Received: by mail-ua0-x230.google.com with SMTP id 97so83209154uav.3 for ; Fri, 19 Aug 2016 07:42:14 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=GbWD/EaINx9pSWHiONkAKO9I7ycx5kCT5iKjpRbcUQY=; b=CviD9L12VMoDQ0KdZPSA7vqF/xdAgDS2rFzx3/zjyUfi1qxbMseouGdAnLw9qhau23 ES0xmkpiSlBsiPl5hUinEO6rDH6q3WcBmQAs9Sc9YVyD8SzPwVWdJc8V8wTw+wMYn2by aWVuUH85pDVbLd0FxITA6ncti/v0hnBNt4N6gOklnAcXJlnlf58BwZsBP/eZqJKXlcoe 9QjSHDIDgLbWb7dvaa4sgjonc4OAVuH1LYEWzjj2Pp/58QaeUtIkXvhxhP9Vi9b62XKf wq0x6e9IRtKFwb9OCJkCu+2siE6Ljtt3mHVs1YP+hR83I6tMke9/ht8gXxykGlFuAAaM EUxw==
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:from:date :message-id:subject:to:cc; bh=GbWD/EaINx9pSWHiONkAKO9I7ycx5kCT5iKjpRbcUQY=; b=Bo3pyslc6ZIRUEfpxj1wBrhWxYVHy1Ln2MEBjWup6x9Z3f7aF+WWh7xMCXL70BcjYv ZWKe4FgqprIW+d4bWysf4m3KWCIC+HXGspAchjGVDDqEGrqa6Eb8+ZFWR8CRwxKXm7lY ykqYKd5C3Me/J14k1QPTE1FdBXu3hTitP5n7TENrxrJUriNW1UffXOUPK53LyqZJhXv+ OI+f11RTVQhXxAPtapiecnIDRNJ8MR5V3I9+ldbgl+pCRUpBGf3wk09lJcHKN7K2juZ2 eLTjFs2j+NRuxgGx5Ok8JkL8Tj+yLoMa1MpNZhEp9YUDAztOiRFhwqQos0owR+IGdcAV jy+A==
X-Gm-Message-State: AEkoousuUF3zNPtyXYjLDBbJbm0vbWgvXPpIRqRBP6wxtKrN4mnrwH5ZOSCCe70VQA5MxjOsdlf4efrYUF/dTA==
X-Received: by 10.176.3.232 with SMTP id 95mr4303590uau.9.1471617733889; Fri, 19 Aug 2016 07:42:13 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.131.4 with HTTP; Fri, 19 Aug 2016 07:42:12 -0700 (PDT)
In-Reply-To: <87pop4x2vu.fsf@hobgoblin.ariadne.com>
References:  <87pop4x2vu.fsf@hobgoblin.ariadne.com>
From: Andy Bierman 
Date: Fri, 19 Aug 2016 07:42:12 -0700
Message-ID: 
To: "Dale R. Worley" 
Content-Type: multipart/alternative; boundary=94eb2c056550462520053a6db491
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 19 Aug 2016 14:42:31 -0000

--94eb2c056550462520053a6db491
Content-Type: text/plain; charset=UTF-8

On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley  wrote:

> Andy Bierman  writes:
> > An Internet-Draft is NOT a means of "publishing" a specification;
>
> As I said, that's the theory, but practice is considerably different.
>
>
Anybody that implements a work-in-progress knows they are taking a risk
on an unstable document.  The guideline already says MUST update
the revision date.

Not sure what more you want to guidelines document to do.



> Dale
>


Andy

--94eb2c056550462520053a6db491
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley <<=
a href=3D"mailto:worley@ariadne.com" target=3D"_blank">worley@ariadne.com> wrote:
Andy Bierman <andy@yumaworks.com> writes:

> An Internet-Draft is NOT a means of "publishing" a specifica=
tion;



As I said, that's the theory, but practice is considerably different.


Anybody that implements a work-in-progress knows the=
y are taking a risk
on an unstable document.=C2=A0 The guideline =
already says MUST update
the revision date.

<=
div>Not sure what more you want to guidelines document to do.
=C2=A0

Dale




<=
/div>
Andy


--94eb2c056550462520053a6db491--


From nobody Fri Aug 19 19:04: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 A1FC012D135; Fri, 19 Aug 2016 19:04:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rFHaf6vANDLq; Fri, 19 Aug 2016 19:04:13 -0700 (PDT)
Received: from mail-pf0-x235.google.com (mail-pf0-x235.google.com [IPv6:2607:f8b0:400e:c00::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 C07EB12B076; Fri, 19 Aug 2016 19:04:13 -0700 (PDT)
Received: by mail-pf0-x235.google.com with SMTP id x72so14333850pfd.2; Fri, 19 Aug 2016 19:04:13 -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 :content-transfer-encoding:message-id:references:to; bh=DHgdOanVhXeSUmt5Or72obFMANROWB3bEAN6zRpyhWM=; b=bUJY8NQozp9etJ8QYWgHS37J/huopGTX0lC+uRONPEkU6QCRyiQPuMhH8OY+yeSvZO uicbeJNrlshBwOwyZf6uvflX3aMaufr77EF8VzxPlJETH6C3vD4sdjCtEmWQatE9kX1w 7okfg+Objoq8bk+neM6dac+TP0FR5qQ3YRDu2N6OHFyAnqCn1dVPPIvOZbHdw02pUe+z OSHOiSR0U1yTCsiI8rfStikMjFJ4i2v8gtfdym9+mvJ25GX28XeQFO6nXmqOh6k2iJMc 6rYEPvmfZdFL+3Vyh8BIgGWaPDTIWd5B1D3e15p84tcoNaTz9nR25c7UhKPEdtA8e3Py N/NA==
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 :content-transfer-encoding:message-id:references:to; bh=DHgdOanVhXeSUmt5Or72obFMANROWB3bEAN6zRpyhWM=; b=LVOjTyY8lgK9s4usBGuKLoItVCLCENzLRAm73O8JDNbdQjbmv5t4T76J+/V8uwI9kt 2qRXKhdjRdQsaOk8cF2bkmglsN4rDGIe2oHbtIJHDeq76lq+3glE8idCja5ApXOwJHao Hp/ns6B4UTyHOlvcZcaCTRyzpjmdesSQTZs1lSBKkupuu3fNkTD/B7C5H69uASF2ekqD sg7BsVw6hw2utGiG+dP0Nyhm84tox0ZO3dKTebn2gs3FzrcEc0mcez6E9rKMf7teke8y u5S2fC1fLZ/ntoTz6gw42s8jRO3gYXpkYYjsQnupsvvgh/aYy1VFYFQXEKVPBEfY/JX+ Ad5g==
X-Gm-Message-State: AEkoousdDrxnhxRFk5o7f/h33FbyLYsNZRIDGmnqPB/fkfUVhERJdmRQ5/w/nKrFkts+BA==
X-Received: by 10.98.34.151 with SMTP id p23mr19943169pfj.102.1471658653295; Fri, 19 Aug 2016 19:04:13 -0700 (PDT)
Received: from sjc-mahesh-nitro6.cisco.com ([128.107.241.170]) by smtp.gmail.com with ESMTPSA id wp4sm14420649pab.15.2016.08.19.19.04.11 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 19 Aug 2016 19:04:11 -0700 (PDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <20160817.111343.387561472405973484.mbj@tail-f.com>
Date: Fri, 19 Aug 2016 19:04:10 -0700
Content-Transfer-Encoding: 7bit
Message-Id: <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com>
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: Netconf , netmod WG 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Aug 2016 02:04:16 -0000

Moving the thread from netconf to netmod.

Will the authors pull 6020bis back into the WG to reach the rough consensus?

> On Aug 17, 2016, at 2:13 AM, Martin Bjorklund  wrote:
> 
> Hi,
> 
> I have read this long ML thread twice now, and I agree with Andy that:
> 
> 1)  We should not / cannot make design changes in an errata or late in
>    AUTH48; in order to do this we need to pull the document back to
>    the WG and reach (rough) consensus on the behavior (note btw that
>    this thread is currently in NETCONF, it really should be NETMOD).
> 
> 2)  Since servers MAY delete NP-containers in some cases, clients can
>    easily handle NP-containers by using "merge" on them.
> 
> 
> I also agree with Jason that ideally the server should never fail on
> any kind of operation on an NP-container, regardless of current state
> and requested operation.  (But again, this is not a simple
> clarification of the current text.)
> 
> 
> And to answer the original question, I think the server that first got
> a request to create the empty NP-containers and then a request w/
> operation "none" is not correct when it fails with a "data-missing"
> error.  There is no text in 6241 or 6020 that supports this behavior.
> 
> 
> /martin
> 
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

Mahesh Jethanandani
mjethanandani@gmail.com




From nobody Sat Aug 20 01:29: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 7726912D63E for ; Sat, 20 Aug 2016 01:29:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.447
X-Spam-Level: 
X-Spam-Status: No, score=-5.447 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-1.247] 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 W-vwfCHR09dK for ; Sat, 20 Aug 2016 01:29: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 9BECD12B01B for ; Sat, 20 Aug 2016 01:29:27 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 12E6F757; Sat, 20 Aug 2016 10:29:25 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 5w53Du71ZJ57; Sat, 20 Aug 2016 10:29:14 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Sat, 20 Aug 2016 10:29:23 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id C5363200A5; Sat, 20 Aug 2016 10:29:23 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id clSLU0J3uHLe; Sat, 20 Aug 2016 10:29:22 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 81FB1200A3; Sat, 20 Aug 2016 10:29:22 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 69D4F3C28479; Sat, 20 Aug 2016 10:29:22 +0200 (CEST)
Date: Sat, 20 Aug 2016 10:29:22 +0200
From: Juergen Schoenwaelder 
To: Mahesh Jethanandani 
Message-ID: <20160820082922.GB9108@elstar.local>
Mail-Followup-To: Mahesh Jethanandani , netmod WG 
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod WG 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
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: Sat, 20 Aug 2016 08:29:30 -0000

Here is what I wrote on Thu, 16 Jun 2016 14:49:00 +0200:

: It is possible that people will find more bugs while this I-D sits in
: the RFC editor queue. My idea is to treat them pretty much in the way
: we treat errata of published RFCs (they need to be clearly written up,
: discussed on the list, there needs to be agreement on the bug and the
: proposed fix). If we get pre-publication errata with consensus, I hope
: we can address them during the editing/auth48 stage so we do not have
: to post an RFC with already known defects. Does this make sense to
: you?

As document shepherd, I believe there is no strong agreement on the
problem and there is no concrete proposal with strong consensus for a
modification of the document (which is in AUTH48). In fact, there has
been no defect description and proposed bug fix at all on the NETMOD
mailing list.

/js

On Fri, Aug 19, 2016 at 07:04:10PM -0700, Mahesh Jethanandani wrote:
> Moving the thread from netconf to netmod.
> 
> Will the authors pull 6020bis back into the WG to reach the rough consensus?
> 
> > On Aug 17, 2016, at 2:13 AM, Martin Bjorklund  wrote:
> > 
> > Hi,
> > 
> > I have read this long ML thread twice now, and I agree with Andy that:
> > 
> > 1)  We should not / cannot make design changes in an errata or late in
> >    AUTH48; in order to do this we need to pull the document back to
> >    the WG and reach (rough) consensus on the behavior (note btw that
> >    this thread is currently in NETCONF, it really should be NETMOD).
> > 
> > 2)  Since servers MAY delete NP-containers in some cases, clients can
> >    easily handle NP-containers by using "merge" on them.
> > 
> > 
> > I also agree with Jason that ideally the server should never fail on
> > any kind of operation on an NP-container, regardless of current state
> > and requested operation.  (But again, this is not a simple
> > clarification of the current text.)
> > 
> > 
> > And to answer the original question, I think the server that first got
> > a request to create the empty NP-containers and then a request w/
> > operation "none" is not correct when it fails with a "data-missing"
> > error.  There is no text in 6241 or 6020 that supports this behavior.
> > 
> > 
> > /martin
> > 
> > _______________________________________________
> > Netconf mailing list
> > Netconf@ietf.org
> > https://www.ietf.org/mailman/listinfo/netconf
> 
> Mahesh Jethanandani
> mjethanandani@gmail.com
> 
> 
> 
> _______________________________________________
> 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 Sat Aug 20 09:44: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 F071012D0BB for ; Sat, 20 Aug 2016 09:44:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0
X-Spam-Level: 
X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, 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 haFcgKfxL3We for ; Sat, 20 Aug 2016 09:44:13 -0700 (PDT)
Received: from mail-ua0-x229.google.com (mail-ua0-x229.google.com [IPv6:2607:f8b0:400c:c08::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 72B8412B020 for ; Sat, 20 Aug 2016 09:44:13 -0700 (PDT)
Received: by mail-ua0-x229.google.com with SMTP id k90so127559406uak.1 for ; Sat, 20 Aug 2016 09:44:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=LbYZeo8C4TG6JXjECeCvbSgv4Jq3UEwSsGlBU81UrgA=; b=M9Fq0zDJH2sdTBrFkotTy3rIqv3r5lIzTD79PEbRQlS1ZLPFqSQJQct7vSBDnJTiUF yAJ3tvaRdhpC7K2Cgn3Byv3uhcmQpTFvB+P7ujda+DLdhREt1b51W6ML7cCHSQ069j7e 4t0rwH/CM3BcdyizupLyWn7GD62oD5W62pFbCOSmWlCJCWVSq2USu9OplJqQ4fu75XNK u0VO4WqPwjZ82FiGg/tacxStUbt40SC8Mn9268q/dS5UVW1joRiypOg96/Hr7XFow9Kj KxydvlVSt/XuZxuh9Tk7OqLD6hr/DDSFJugj/dS4QEDBfWMUI1FHf2oeFQ74v6NLPY2B yO/g==
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:from:date :message-id:subject:to; bh=LbYZeo8C4TG6JXjECeCvbSgv4Jq3UEwSsGlBU81UrgA=; b=QMHbEh9qmG3D8Hbur/6lho5GgB+YbiFeVQzkrbEr7oAm+adphrEnPb1rDFoxSAWAPC QkwlR9/gbydTw4Ro9KnK08HqrUMWZ3j27p9M9y9tKkhI704T9RsqGikZCNjuDME7tmTD fH7rfpfPxk8Z8yw9tE6TeQcJ2FBidmsQn/rd6S7dZa/aUcco7kgAD8qF7xSI5rvidRkP lzaAFBgZ711dci1fhIv+Dwp6h1Zfk5gIgt7lPLwgf0B0tHEU4Zk9hBiT9aLmsxnJdvbf VLAf296O2qc4II1mNTwGUdQTQRSrdZ8kFrpDzvwgArMqmJl4Cu12nZUFkJdeHwcuPFe3 /QFw==
X-Gm-Message-State: AEkoouuuBLp+91x6lcFZW6CqqqTOKkfmucLXn9nsZwsRgR2YymhYtQQl2cXToD2Zt1yVdQFb+QZwmMaBny1AVA==
X-Received: by 10.176.80.47 with SMTP id b44mr7061208uaa.135.1471711452460; Sat, 20 Aug 2016 09:44:12 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.134 with HTTP; Sat, 20 Aug 2016 09:44:11 -0700 (PDT)
In-Reply-To: <20160820082922.GB9108@elstar.local>
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local>
From: Andy Bierman 
Date: Sat, 20 Aug 2016 09:44:11 -0700
Message-ID: 
To: Juergen Schoenwaelder ,  Mahesh Jethanandani , netmod WG 
Content-Type: multipart/alternative; boundary=94eb2c18f30a560f1a053a8386a3
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Aug 2016 16:44:25 -0000

--94eb2c18f30a560f1a053a8386a3
Content-Type: text/plain; charset=UTF-8

Hi,

This text in sec 7.5.8, para 2 is wrong:

   If a container does not have a "presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.



This text in 6.4.1 is correct, which implies deleting an N container occurs
when its non-NP container
ancestor is deleted.


   If a node that exists in the accessible tree has a non-presence
   container as a child, then the non-presence container also exists in
   the tree.


This text in 7.5.7 covers the intended external behavior on an NP-container
better than the text in 7.5.8:

   If a non-presence container does not have any child nodes, the
   container may or may not be present in the XML encoding.


(BTW, why isn't this text using RFC 2119 terms like sec. 7.5.8?)


I propose that the cited text in sec. 7.5.8 be removed as a clarification.
It is a redundant (incorrect) restatement of the cited text in 7.5.7.


Andy



On Sat, Aug 20, 2016 at 1:29 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> Here is what I wrote on Thu, 16 Jun 2016 14:49:00 +0200:
>
> : It is possible that people will find more bugs while this I-D sits in
> : the RFC editor queue. My idea is to treat them pretty much in the way
> : we treat errata of published RFCs (they need to be clearly written up,
> : discussed on the list, there needs to be agreement on the bug and the
> : proposed fix). If we get pre-publication errata with consensus, I hope
> : we can address them during the editing/auth48 stage so we do not have
> : to post an RFC with already known defects. Does this make sense to
> : you?
>
> As document shepherd, I believe there is no strong agreement on the
> problem and there is no concrete proposal with strong consensus for a
> modification of the document (which is in AUTH48). In fact, there has
> been no defect description and proposed bug fix at all on the NETMOD
> mailing list.
>
> /js
>
> On Fri, Aug 19, 2016 at 07:04:10PM -0700, Mahesh Jethanandani wrote:
> > Moving the thread from netconf to netmod.
> >
> > Will the authors pull 6020bis back into the WG to reach the rough
> consensus?
> >
> > > On Aug 17, 2016, at 2:13 AM, Martin Bjorklund  wrote:
> > >
> > > Hi,
> > >
> > > I have read this long ML thread twice now, and I agree with Andy that:
> > >
> > > 1)  We should not / cannot make design changes in an errata or late in
> > >    AUTH48; in order to do this we need to pull the document back to
> > >    the WG and reach (rough) consensus on the behavior (note btw that
> > >    this thread is currently in NETCONF, it really should be NETMOD).
> > >
> > > 2)  Since servers MAY delete NP-containers in some cases, clients can
> > >    easily handle NP-containers by using "merge" on them.
> > >
> > >
> > > I also agree with Jason that ideally the server should never fail on
> > > any kind of operation on an NP-container, regardless of current state
> > > and requested operation.  (But again, this is not a simple
> > > clarification of the current text.)
> > >
> > >
> > > And to answer the original question, I think the server that first got
> > > a request to create the empty NP-containers and then a request w/
> > > operation "none" is not correct when it fails with a "data-missing"
> > > error.  There is no text in 6241 or 6020 that supports this behavior.
> > >
> > >
> > > /martin
> > >
> > > _______________________________________________
> > > Netconf mailing list
> > > Netconf@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netconf
> >
> > Mahesh Jethanandani
> > mjethanandani@gmail.com
> >
> >
> >
> > _______________________________________________
> > 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
>

--94eb2c18f30a560f1a053a8386a3
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

This text in sec 7.5.8, para 2 is w=
rong:

   If a container does not have a =
"presence" statement and the last
   child node is deleted, the NETCONF server MAY delete the container.



This text in 6.4.1 is correc=
t, which implies deleting an N container occurs when its non-NP container
ancestor is deleted.


   If a node that exists in the accessible tree has a non-presence
   container as a child, then the non-presence container also exists in
   the tree.



This text in 7.5.7 covers the intended external behavior on an NP=
-container
better than the text in 7.5.8:

   If a non-p=
resence container does not have any child nodes, the
   container may or may not be present in the XML encoding.

=
(BTW, why isn't this text using RFC 2119 terms like sec. 7.5.8?)
<=
div>

I propose that the cited text in sec. 7.5=
.8 be removed as a clarification.
It is a redundant (incorrect) r=
estatement of the cited text in 7.5.7.


<=
div>Andy



On Sat, Aug 20, 2016 at 1:29 AM, Juergen S=
choenwaelder <j.schoenwaelder@jacobs-university.de&=
gt; wrote:
Here is what I wrote on=
 Thu, 16 Jun 2016 14:49:00 +0200:



: It is possible that people will find more bugs while this I-D sits in

: the RFC editor queue. My idea is to treat them pretty much in the way

: we treat errata of published RFCs (they need to be clearly written up,
: discussed on the list, there needs to be agreement on the bug and the

: proposed fix). If we get pre-publication errata with consensus, I hope
: we can address them during the editing/auth48 stage so we do not have

: to post an RFC with already known defects. Does this make sense to

: you?



As document shepherd, I believe there is no strong agreement on the

problem and there is no concrete proposal with strong consensus for a

modification of the document (which is in AUTH48). In fact, there has

been no defect description and proposed bug fix at all on the NETMOD

mailing list.



/js



On Fri, Aug 19, 2016 at 07:04:10PM -0700, Mahesh Jethanandani wrote:

> Moving the thread from netconf to netmod.

>

> Will the authors pull 6020bis back into the WG to reach the rough cons=
ensus?

>

> > On Aug 17, 2016, at 2:13 AM, Martin Bjorklund <mbj@tail-f.com> wrote:

> >

> > Hi,

> >

> > I have read this long ML thread twice now, and I agree with Andy =
that:

> >

> > 1)=C2=A0 We should not / cannot make design changes in an errata =
or late in

> >=C2=A0 =C2=A0 AUTH48; in order to do this we need to pull the docu=
ment back to

> >=C2=A0 =C2=A0 the WG and reach (rough) consensus on the behavior (=
note btw that

> >=C2=A0 =C2=A0 this thread is currently in NETCONF, it really shoul=
d be NETMOD).

> >

> > 2)=C2=A0 Since servers MAY delete NP-containers in some cases, cl=
ients can

> >=C2=A0 =C2=A0 easily handle NP-containers by using "merge&quo=
t; on them.

> >

> >

> > I also agree with Jason that ideally the server should never fail=
 on

> > any kind of operation on an NP-container, regardless of current s=
tate

> > and requested operation.=C2=A0 (But again, this is not a simple
> > clarification of the current text.)

> >

> >

> > And to answer the original question, I think the server that firs=
t got

> > a request to create the empty NP-containers and then a request w/=


> > operation "none" is not correct when it fails with a &q=
uot;data-missing"

> > error.=C2=A0 There is no text in 6241 or 6020 that supports this =
behavior.

> >

> >

> > /martin

> >

> > _______________________________________________

> > Netconf mailing list

> > Netconf@ietf.org

> > https://www.ietf.org/mailman/listinfo/ne=
tconf

>

> Mahesh Jethanandani

> mjethanandani@gmail.com=


>

>

>

> _______________________________________________

> netmod mailing list

> netmod@ietf.org

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



--

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




--94eb2c18f30a560f1a053a8386a3--


From nobody Sat Aug 20 10:18: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 E041D12D1D1 for ; Sat, 20 Aug 2016 10:18:46 -0700 (PDT)
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=[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 8BHTbZxNpk_w for ; Sat, 20 Aug 2016 10:18:45 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 36F3612D188 for ; Sat, 20 Aug 2016 10:18:45 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 9896F9261A8; Sat, 20 Aug 2016 19:18:42 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9KHaAPOzmsja; Sat, 20 Aug 2016 19:18:42 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6E3F79261AA; Sat, 20 Aug 2016 19:18:42 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id MefLwhQ_Vcok; Sat, 20 Aug 2016 19:18:42 +0200 (CEST)
Received: from [192.168.2.191] (cm-84.215.234.162.getinternet.no [84.215.234.162]) by mail.transpacket.com (Postfix) with ESMTPSA id 37FD89261A8; Sat, 20 Aug 2016 19:18:42 +0200 (CEST)
Message-ID: <57B890F2.9070605@transpacket.com>
Date: Sat, 20 Aug 2016 19:18:42 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Juergen Schoenwaelder ,  netmod@ietf.org
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local>
In-Reply-To: <20160820082922.GB9108@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 20 Aug 2016 17:18:47 -0000

On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:
>
> As document shepherd, I believe there is no strong agreement on the
> problem and there is no concrete proposal with strong consensus for a
> modification of the document (which is in AUTH48). In fact, there has
> been no defect description and proposed bug fix at all on the NETMOD
> mailing list.
Hello,

I have strong objection to the text proposed as solution to issue #41:

6.4.1 Xpath Context:

     If a node that exists in the accessible tree has a non-presence
     container as a child, then the non-presence container also exists in
     the tree.

The description of the issue itself is:

     Y41: clarification of "must" in NP-container <>


I believe the 5 mails in the 
http://www.ietf.org/mail-archive/web/netmod/current/msg10015.html did 
not address all the negative consequences of such change in the rules 
for evaluation of validation statements regarding non-presence 
containers and the solution that was taken is not acceptable for the 
following reasons:

[1] the proposed text is not a clarification as indicated in Y41 but a 
backward incompatible change of the YANG validation statement evaluation 
rules.

[2] the clarification introduces further confusion for models like NACM 
where non-presence containers are used for access control and their 
explicit creation and deletion is the only sane way to enforce the 
configured rules. Always present non-presence containers that MAY be 
auto deleted by servers ... how will this work exactly?

[3] the proposed text leads to increased processing of large number of 
validation checks which is very unlikely to bring real value to YANG. 20 
non-presence containers with must statements per interface in 
96-interface switch is already heavy Xpath evaluation task. A task that 
in YANG 1.0 was not necessary if the containers were not explicitly created.

[4] the proposed text leads to less flexibility and excludes certain 
practical validation models e.g. 
https://www.ietf.org/mail-archive/web/netconf/current/msg11609.html

[5] the proposed text inflicts problems 1-4 and its clarification effect 
is not working for me.

I have a concrete proposal for a solution on the issue - remove the 
"non-presence containers MAY be deleted automatically" text from YANG 
1.1 instead of opening Pandora's box:

Instead of building further the pipe dream of non-presence containers 
that MAY be deleted automatically I propose that flexibility removed 
from YANG 1.1. All non-presence containers have to be created explicitly 
and the validation statements must be evaluated only for explicitly 
created containers (so long there is no change from YANG 1.0) and these 
containers MUST be deleted explicitly (replacing the "MAY be deleted 
automatically" YANG 1.0 optimization attempt which is the origin of the 
pipe dream) as one would logically expect. It is semantical meaning that 
is not present not the container which still has its usage giving 
structure to the data and especially in cases like NACM and validation 
statements where without certain explicit create/delete rules things get 
really confusing.

The concrete proposal in form of a patch to RFC6020 sent in this e-mail 
to the netconf mailing list: 
https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html 
There will be even more obsoleted clarification text that will be 
irrelevant if the concept change is applied to YANG 1.1

Vladimir


From nobody Mon Aug 22 02:25:57 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 398A412B049 for ; Mon, 22 Aug 2016 02:25:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 r9C4LsIKrntu for ; Mon, 22 Aug 2016 02:25:54 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD54F12B032 for ; Mon, 22 Aug 2016 02:25:54 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 8D5DF70D; Mon, 22 Aug 2016 11:25:53 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id NZcEz4SSfaB4; Mon, 22 Aug 2016 11:25:51 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Aug 2016 11:25:52 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id CFDD8200A8; Mon, 22 Aug 2016 11:25:52 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id OQikcwp2tpyW; Mon, 22 Aug 2016 11:25:51 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AC8DA200AA; Mon, 22 Aug 2016 11:25:51 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id CFEA33C2A555; Mon, 22 Aug 2016 11:25:50 +0200 (CEST)
Date: Mon, 22 Aug 2016 11:25:50 +0200
From: Juergen Schoenwaelder 
To: Vladimir Vassilev 
Message-ID: <20160822092550.GC12015@elstar.local>
Mail-Followup-To: Vladimir Vassilev , netmod@ietf.org
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57B890F2.9070605@transpacket.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
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, 22 Aug 2016 09:25:56 -0000

On Sat, Aug 20, 2016 at 07:18:42PM +0200, Vladimir Vassilev wrote:
> On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:
> > 
> > As document shepherd, I believe there is no strong agreement on the
> > problem and there is no concrete proposal with strong consensus for a
> > modification of the document (which is in AUTH48). In fact, there has
> > been no defect description and proposed bug fix at all on the NETMOD
> > mailing list.
> Hello,
> 
> I have strong objection to the text proposed as solution to issue #41:
>

Dear Vladimir Vassilev,

please note that we YANG 1.1 is in AUTH48 state, that is YANG 1.1 has
passed WG last call, IETF last call, and IESG approval. In other
words, we are way beyond the state in the IETF process where we
discuss the resolution of individual issues. As far as I recall from
the logs, issue #41 was closed about two years ago.

/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 Aug 22 02:38: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 7AE7C12B049 for ; Mon, 22 Aug 2016 02:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.09
X-Spam-Level: 
X-Spam-Status: No, score=-0.09 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=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 qdKHnAvpnzbZ for ; Mon, 22 Aug 2016 02:38:39 -0700 (PDT)
Received: from mail-qk0-x229.google.com (mail-qk0-x229.google.com [IPv6:2607:f8b0:400d:c09::229]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8452712B044 for ; Mon, 22 Aug 2016 02:38:39 -0700 (PDT)
Received: by mail-qk0-x229.google.com with SMTP id z190so80358188qkc.0 for ; Mon, 22 Aug 2016 02:38:39 -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=EMRBAX1eLznOVgUrAcl1bITgbkoMhXjhKjPLjb4898I=; b=vyy5eSF3xlOFWD1g6xTUBXnz8nPDdWZaRr1tx2SNybE+QCcFjuBMYpYelFN0DONQSP EXwlrYflmBWxcnpN0OCleHsIPeoSDpHBCmXLu4hH6IsgTuChuu8u+3uuHHi7UBaoDtFa DvFQyn24joiX/iUYAV0E/8b6SYH7d6kxGM7pyQBNEWpZt9mw5tGonvRS/5TfOBFbPt1j 3DluzuajmpWoTlbGfG95AOn6G/I66TTYdRsHON6zjpzSI09F9by7SaK6S728TjF4aadI vykJdaisXJvfY3D+0/5ZZJU75t0uJbXMM4LKkq9ooiP1dvL8MHqlXSAmpXM1WU5FpXBO oLGg==
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=EMRBAX1eLznOVgUrAcl1bITgbkoMhXjhKjPLjb4898I=; b=F4ljl6mNs5htk6uT+Qtm33QBLTR7wtB7B4OIPlbcG65gMXBmRb3JyVwI1Mz0p/GvYc 8FAOY5piEN9zgTmznQdrx+lUEXrUwan58QAKzPgD2wSvlc+mF/FDkHOUzDkj3FlHbfYQ hGpwXQWUfQgpO3h99FwADAfL9llY7T6mcLObLkuxV/yxoK37m7rFxYPWWYqX1PWFeFg0 qLm3VKWnM00IhaHcIF7eoyrLd0ZdzJJko5xijoU1bQjm5wLRIRQTxaq9G6GjirnfjExH 0+OFUzJtrLceqeft7EgSIaCxuCWrU6qBkHMhN5IXfM/1yXiwlMq92Zmp4jeM8QJ+jpl+ 2vyg==
X-Gm-Message-State: AE9vXwN5r94vPdwAsUlucd5TtCENEArrddPj8zxFnp9EP73GrLCcCb03A8x29jZh7x5BFg==
X-Received: by 10.55.56.141 with SMTP id f135mr8212479qka.73.1471858718583; Mon, 22 Aug 2016 02:38:38 -0700 (PDT)
Received: from [10.0.1.12] (c-75-68-179-118.hsd1.ma.comcast.net. [75.68.179.118]) by smtp.gmail.com with ESMTPSA id r100sm10704630qkh.10.2016.08.22.02.38.36 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Mon, 22 Aug 2016 02:38:38 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_2789972B-285B-41DD-96BB-4A5FA48157C7"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dean Bogdanovic 
In-Reply-To: <7F859F89F9B4DD4DB902232F9E2DAC083873C373@ESGSCMB103.ericsson.se>
Date: Mon, 22 Aug 2016 05:38:35 -0400
Message-Id: 
References: <7F859F89F9B4DD4DB902232F9E2DAC083873C373@ESGSCMB103.ericsson.se>
To: Adrian Pan 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "kkoushik@cisco.com" , netmod WG 
Subject: Re: [netmod] Question about acl-type in draft-ietf-netmod-acl-model-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: Mon, 22 Aug 2016 09:38:41 -0000

--Apple-Mail=_2789972B-285B-41DD-96BB-4A5FA48157C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

(+netmod mailing list)
Adrian,

Please see inline
> On Aug 22, 2016, at 2:27 AM, Adrian Pan  =
wrote:
>=20
> Dear authors,
> =20
> I have some questions about ietf acl model as below, your reply is =
appreciated.
> =20
> 1)   In the model definition acl-type is one key of the acl, also in =
the description it says that the acl-type could be ethernet, IPv4, IPv6, =
mixed, in case the acl-type is mixed, what=E2=80=99s the identifier =
should be?
> Should it be augmented by different vendor? Since I don=E2=80=99t see =
the definition about it.

As mixed ACLs are not supported by all vendors, those are not part of =
the standard model. Iit is up to the vendor to augment the ace-type and =
select an identifier to their liking.=20

> 2)   In the =E2=80=9Cmix=E2=80=9D case, the =E2=80=9Cmatches=E2=80=9D =
the ace list can be the combination of Ethernet,ipv4,ipv6 for different =
ace, right?

Or another combination, again depends on what that particular vendor =
supports.
> 3)   With the model definition, even the acl-type is configured as =
Ethernet, the operator still can configure the matches of ace under the =
acl as ipv4 or ipv6, right?

No, if ACL type is ethernet, then all ACEs are expected to be ethernet.=20=

> is this the model design intention?

If acl-type is of one family, then only ace with match condition from =
that family are expected to be in the acl. If you want to combine them, =
please use mixed type.

Dean

> module: ietf-access-control-list
>    +--rw access-lists
>       +--rw acl* [acl-type acl-name]
>          +--rw acl-name               string
>          +--rw acl-type               acl-type
>          +--ro acl-oper-data
>          +--rw access-list-entries
>             +--rw ace* [rule-name]
>                +--rw rule-name        string
>                +--rw matches
>                |  +--rw (ace-type)?
> =20
>          leaf acl-type {
>=20
>            type acl-type;
>=20
>            description
>=20
>          "Type of access control list. Indicates the primary intended
>=20
>          type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, =
etc)
>=20
>          used in the list instance.";
>=20
>          }
>=20
> =20

> Thanks
> Adrian


--Apple-Mail=_2789972B-285B-41DD-96BB-4A5FA48157C7
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


(+netmod mailing list)
Adrian,

Please see inline
On =
Aug 22, 2016, at 2:27 AM, Adrian Pan <adrian.pan@ericsson.com> wrote:

Dear authors,
 
I have some questions =
about ietf acl model as below, your reply =
is appreciated.
 
1)   In the model definition acl-type is one key of the acl, also in the description it says that =
the acl-type could be ethernet, IPv4, IPv6, mixed, in case the acl-type is mixed, what=E2=80=99s the identifier should =
be?
Should it be =
augmented by different vendor? Since I don=E2=80=99t see the =
definition about it.

As mixed ACLs are not supported by all vendors, =
those are not part of the standard model. Iit is up to the vendor to =
augment the ace-type and select an identifier to their =
liking. 

2)   In the =E2=80=9Cmix=E2=80=9D case, the =E2=80=9Cmatches=E2=80=9D the ace list can be the =
combination of Ethernet,ipv4,ipv6 for different ace, =
right?

Or =
another combination, again depends on what that particular vendor =
supports.
3)   With the model definition, even the acl-type is configured as Ethernet, the operator =
still can configure the matches of ace under the acl as ipv4 or ipv6, =
right?

No, =
if ACL type is ethernet, then all ACEs are expected to be =
ethernet. 
 is this the model =
design intention?

If acl-type is of one family, then only ace with match =
condition from that family are expected to be in the acl. If you want to =
combine them, please use mixed type.

Dean

module: ietf-access-control-list
   +--rw =
access-lists
      =
+--rw acl* [acl-type =
acl-name]
         =
+--rw acl-name          &nb=
sp;    string
         =
+--rw acl-type     =
          acl-type
         =
+--ro acl-oper-data
         =
+--rw access-list-entries
          &nb=
sp; +--rw ace* [rule-name]
          &nb=
sp;    +--rw =
rule-name        =
string
          &nb=
sp;    +--rw =
matches
          &nb=
sp;    |  +--rw (ace-type)?
 
         leaf acl-type {
           type acl-type;
           description
         "Type of access =
control list. Indicates the primary intended
         type of match =
criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)
         used in the list =
instance.";
         }
 

Thanks
Adrian

=

--Apple-Mail=_2789972B-285B-41DD-96BB-4A5FA48157C7--


From nobody Mon Aug 22 03:25: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 A934112D137 for ; Mon, 22 Aug 2016 03:25:51 -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 ZjCjNmi8WjU7 for ; Mon, 22 Aug 2016 03:25:49 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3AF3C12D100 for ; Mon, 22 Aug 2016 03:25:49 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id AEE18926312; Mon, 22 Aug 2016 12:25:46 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id fqfn_f6TFJZI; Mon, 22 Aug 2016 12:25:46 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 84B21926325; Mon, 22 Aug 2016 12:25:46 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id vq5NvuMMeqM6; Mon, 22 Aug 2016 12:25:46 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 60161926312; Mon, 22 Aug 2016 12:25:46 +0200 (CEST)
Message-ID: <57BAD328.80606@transpacket.com>
Date: Mon, 22 Aug 2016 12:25:44 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Juergen Schoenwaelder ,  netmod@ietf.org
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com> <20160822092550.GC12015@elstar.local>
In-Reply-To: <20160822092550.GC12015@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 10:25:52 -0000

Dear Juergen Schoenwaelder,

On 08/22/2016 11:25 AM, Juergen Schoenwaelder wrote:
> On Sat, Aug 20, 2016 at 07:18:42PM +0200, Vladimir Vassilev wrote:
>
>> Hello,
>>
>> I have strong objection to the text proposed as solution to issue #41:
>>
> Dear Vladimir Vassilev,
>
> please note that we YANG 1.1 is in AUTH48 state, that is YANG 1.1 has
> passed WG last call, IETF last call, and IESG approval. In other
> words, we are way beyond the state in the IETF process where we
> discuss the resolution of individual issues. As far as I recall from
> the logs, issue #41 was closed about two years ago.
>
> /js
>

I wrote my proposal for errata as if the RFC was published hoping it 
would  gain agreement on the bug and the proposed fix and hopefully get 
addressed during the editing/auth48 stage so we do not have to post an 
RFC with already known defects. I interpreted your mail as invitation 
for people with opinion on the issue to post their concrete proposals 
which is what I did.

On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:
> Here is what I wrote on Thu, 16 Jun 2016 14:49:00 +0200:
>
> : It is possible that people will find more bugs while this I-D sits in
> : the RFC editor queue. My idea is to treat them pretty much in the way
> : we treat errata of published RFCs (they need to be clearly written up,
> : discussed on the list, there needs to be agreement on the bug and the
> : proposed fix). If we get pre-publication errata with consensus, I hope
> : we can address them during the editing/auth48 stage so we do not have
> : to post an RFC with already known defects. Does this make sense to
> : you?
>
> As document shepherd, I believe there is no strong agreement on the
> problem and there is no concrete proposal with strong consensus for a
> modification of the document (which is in AUTH48). In fact, there has
> been no defect description and proposed bug fix at all on the NETMOD
> mailing list.
>
> /js
Why is the "defect description and proposed bug fix" I propose not a 
candidate for consideration for a AUTH48 change?

Can someone with alternative opinion comment on the issues [1-4] I list. 
I really hope I am wrong and those are not as significant problems as it 
currently seems to me.

On 08/20/2016 07:18 PM, Vladimir Vassilev wrote:
> Hello,
>
> I have strong objection to the text proposed as solution to issue #41:
>
> 6.4.1 Xpath Context:
>
>     If a node that exists in the accessible tree has a non-presence
>     container as a child, then the non-presence container also exists in
>     the tree.
>
> The description of the issue itself is:
>
>     Y41: clarification of "must" in NP-container <>
>
>
> I believe the 5 mails in the 
> http://www.ietf.org/mail-archive/web/netmod/current/msg10015.html did 
> not address all the negative consequences of such change in the rules 
> for evaluation of validation statements regarding non-presence 
> containers and the solution that was taken is not acceptable for the 
> following reasons:
>
> [1] the proposed text is not a clarification as indicated in Y41 but a 
> backward incompatible change of the YANG validation statement 
> evaluation rules.
>
> [2] the clarification introduces further confusion for models like 
> NACM where non-presence containers are used for access control and 
> their explicit creation and deletion is the only sane way to enforce 
> the configured rules. Always present non-presence containers that MAY 
> be auto deleted by servers ... how will this work exactly?
>
> [3] the proposed text leads to increased processing of large number of 
> validation checks which is very unlikely to bring real value to YANG. 
> 20 non-presence containers with must statements per interface in 
> 96-interface switch is already heavy Xpath evaluation task. A task 
> that in YANG 1.0 was not necessary if the containers were not 
> explicitly created.
>
> [4] the proposed text leads to less flexibility and excludes certain 
> practical validation models e.g. 
> https://www.ietf.org/mail-archive/web/netconf/current/msg11609.html
>
> [5] the proposed text inflicts problems 1-4 and its clarification 
> effect is not working for me.
>
> I have a concrete proposal for a solution on the issue - remove the 
> "non-presence containers MAY be deleted automatically" text from YANG 
> 1.1 instead of opening Pandora's box:
>
> Instead of building further the pipe dream of non-presence containers 
> that MAY be deleted automatically I propose that flexibility removed 
> from YANG 1.1. All non-presence containers have to be created 
> explicitly and the validation statements must be evaluated only for 
> explicitly created containers (so long there is no change from YANG 
> 1.0) and these containers MUST be deleted explicitly (replacing the 
> "MAY be deleted automatically" YANG 1.0 optimization attempt which is 
> the origin of the pipe dream) as one would logically expect. It is 
> semantical meaning that is not present not the container which still 
> has its usage giving structure to the data and especially in cases 
> like NACM and validation statements where without certain explicit 
> create/delete rules things get really confusing.
>
> The concrete proposal in form of a patch to RFC6020 sent in this 
> e-mail to the netconf mailing list: 
> https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html 
> There will be even more obsoleted clarification text that will be 
> irrelevant if the concept change is applied to YANG 1.1
>
> Vladimir 

Vladimir


From nobody Mon Aug 22 04:56:37 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 B0BB112B053 for ; Mon, 22 Aug 2016 04:56:35 -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 BMRycwRNeGJb for ; Mon, 22 Aug 2016 04:56:33 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CC836127A90 for ; Mon, 22 Aug 2016 04:56:31 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id 630AA1CC0222; Mon, 22 Aug 2016 13:56:29 +0200 (CEST)
From: Ladislav Lhotka 
To: Vladimir Vassilev , Juergen Schoenwaelder , netmod@ietf.org
In-Reply-To: <57B890F2.9070605@transpacket.com>
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Mon, 22 Aug 2016 13:56:28 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 11:56:36 -0000

Vladimir Vassilev  writes:

> On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:
>>
>> As document shepherd, I believe there is no strong agreement on the
>> problem and there is no concrete proposal with strong consensus for a
>> modification of the document (which is in AUTH48). In fact, there has
>> been no defect description and proposed bug fix at all on the NETMOD
>> mailing list.
> Hello,
>
> I have strong objection to the text proposed as solution to issue #41:
>
> 6.4.1 Xpath Context:
>
>      If a node that exists in the accessible tree has a non-presence
>      container as a child, then the non-presence container also exists in
>      the tree.
>
> The description of the issue itself is:
>
>      Y41: clarification of "must" in NP-container <>
>
>
> I believe the 5 mails in the 
> http://www.ietf.org/mail-archive/web/netmod/current/msg10015.html did 
> not address all the negative consequences of such change in the rules 
> for evaluation of validation statements regarding non-presence 
> containers and the solution that was taken is not acceptable for the 
> following reasons:
>
> [1] the proposed text is not a clarification as indicated in Y41 but a 
> backward incompatible change of the YANG validation statement evaluation 
> rules.

The charter doesn't limit YANG 1.1 to clarifications. The adopted
solution addresses ambiguous cases like this:

container top {
  must "foo > 42";
  leaf foo {
    type uint8;
  }
  leaf bar {
    type boolean;
    default true;
  }
}

If "top" doesn't exist, then according to sec. 7.6.1 of RFC 6020, the
default value of "bar" is in use, so somehow the NP-container "top"
should also be in use. The question then arises whether the "must"
constraint applies or not.

>
> [2] the clarification introduces further confusion for models like NACM 
> where non-presence containers are used for access control and their 
> explicit creation and deletion is the only sane way to enforce the 
> configured rules. Always present non-presence containers that MAY be 
> auto deleted by servers ... how will this work exactly?

IMO the problem is in this auto-deletion option. I suspect my example
above may also be unclear from the NACM point of view - do the rules set
for "top" apply if "top" hasn't been explicitly configured?

>
> [3] the proposed text leads to increased processing of large number of 
> validation checks which is very unlikely to bring real value to YANG. 20 
> non-presence containers with must statements per interface in 
> 96-interface switch is already heavy Xpath evaluation task. A task that 
> in YANG 1.0 was not necessary if the containers were not explicitly
> created.

Some implementations did it anyway and some didn't, which was considered
a problem.

>
> [4] the proposed text leads to less flexibility and excludes certain 
> practical validation models e.g. 
> https://www.ietf.org/mail-archive/web/netconf/current/msg11609.html

Well... If the goal it to prevent np2_leaf from appearing when np1_leaf
is configured, then the most natural solution is to put a must statement on
np1_leaf:

leaf np1_leaf {
  type string;
  must "not(../../np2/np2_leaf)";
}

Or if you insisted on having it on the "np1" container, you can do this:

  must "not(np1_leaf) or not(../np2/np2_leaf)";

Lada

>
> [5] the proposed text inflicts problems 1-4 and its clarification effect 
> is not working for me.
>
> I have a concrete proposal for a solution on the issue - remove the 
> "non-presence containers MAY be deleted automatically" text from YANG 
> 1.1 instead of opening Pandora's box:
>
> Instead of building further the pipe dream of non-presence containers 
> that MAY be deleted automatically I propose that flexibility removed 
> from YANG 1.1. All non-presence containers have to be created explicitly 
> and the validation statements must be evaluated only for explicitly 
> created containers (so long there is no change from YANG 1.0) and these 
> containers MUST be deleted explicitly (replacing the "MAY be deleted 
> automatically" YANG 1.0 optimization attempt which is the origin of the 
> pipe dream) as one would logically expect. It is semantical meaning that 
> is not present not the container which still has its usage giving 
> structure to the data and especially in cases like NACM and validation 
> statements where without certain explicit create/delete rules things get 
> really confusing.
>
> The concrete proposal in form of a patch to RFC6020 sent in this e-mail 
> to the netconf mailing list: 
> https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html 
> There will be even more obsoleted clarification text that will be 
> irrelevant if the concept change is applied to YANG 1.1
>
> Vladimir
>
> _______________________________________________
> 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 Aug 22 05:56: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 A6B2812D197 for ; Mon, 22 Aug 2016 05:56:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 qqTD6-KJv1T1 for ; Mon, 22 Aug 2016 05:56:23 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0F23512D0CB for ; Mon, 22 Aug 2016 05:56:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id F08579263BA; Mon, 22 Aug 2016 14:56:20 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id HoFaTYieoA9d; Mon, 22 Aug 2016 14:56:20 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id C55319263B6; Mon, 22 Aug 2016 14:56:20 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SHzXLxE1ktIR; Mon, 22 Aug 2016 14:56:20 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id A025D9263B2; Mon, 22 Aug 2016 14:56:20 +0200 (CEST)
Message-ID: <57BAF672.60308@transpacket.com>
Date: Mon, 22 Aug 2016 14:56:18 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Ladislav Lhotka , netmod@ietf.org
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 12:56:25 -0000

On 08/22/2016 01:56 PM, Ladislav Lhotka wrote:
> Vladimir Vassilev  writes:
>
>> On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:
>>> As document shepherd, I believe there is no strong agreement on the
>>> problem and there is no concrete proposal with strong consensus for a
>>> modification of the document (which is in AUTH48). In fact, there has
>>> been no defect description and proposed bug fix at all on the NETMOD
>>> mailing list.
>> Hello,
>>
>> I have strong objection to the text proposed as solution to issue #41:
>>
>> 6.4.1 Xpath Context:
>>
>>       If a node that exists in the accessible tree has a non-presence
>>       container as a child, then the non-presence container also exists in
>>       the tree.
>>
>> The description of the issue itself is:
>>
>>       Y41: clarification of "must" in NP-container <>
>>
>>
>> I believe the 5 mails in the
>> http://www.ietf.org/mail-archive/web/netmod/current/msg10015.html did
>> not address all the negative consequences of such change in the rules
>> for evaluation of validation statements regarding non-presence
>> containers and the solution that was taken is not acceptable for the
>> following reasons:
>>
>> [1] the proposed text is not a clarification as indicated in Y41 but a
>> backward incompatible change of the YANG validation statement evaluation
>> rules.
> The charter doesn't limit YANG 1.1 to clarifications. The adopted
> solution addresses ambiguous cases like this:
>
> container top {
>    must "foo > 42";
>    leaf foo {
>      type uint8;
>    }
>    leaf bar {
>      type boolean;
>      default true;
>    }
> }
>
> If "top" doesn't exist, then according to sec. 7.6.1 of RFC 6020, the
> default value of "bar" is in use, so somehow the NP-container "top"
> should also be in use. The question then arises whether the "must"
> constraint applies or not.
This example is based on the bug I propose to be fixed. If you looked at 
the patch I propose in 
https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html sec. 
7.1.6 of RFC 6020 is modified:

---
OLD:
7.6.1.  The leaf's default value

    The default value of a leaf is the value that the server uses if the
    leaf does not exist in the data tree.  The usage of the default value
    depends on the leaf's closest ancestor node in the schema tree that
    is not a non-presence container:

NEW:
7.6.1.  The leaf's default value

    The default value of a leaf is the value that the server uses if the
    leaf does not exist in the data tree.  The usage of the default value
    depends on the leaf's closest ancestor node in the schema tree:
---
The patch removes the "MAY be deleted" text and all artifacts resulting 
from poor attempts to cover the logical discontinuity it inflicts on 
YANG. It is the only justification of all special case clarifications 
regarding non-presence containers which are never going to be enough to 
cover all private cases.
>
>> [2] the clarification introduces further confusion for models like NACM
>> where non-presence containers are used for access control and their
>> explicit creation and deletion is the only sane way to enforce the
>> configured rules. Always present non-presence containers that MAY be
>> auto deleted by servers ... how will this work exactly?
> IMO the problem is in this auto-deletion option. I suspect my example
> above may also be unclear from the NACM point of view - do the rules set
> for "top" apply if "top" hasn't been explicitly configured?
+1 I do not know either. NACM is affected in a bad way. The "MAY be 
deleted" text was not that bad since one would assume sane servers would 
not auto delete data nodes which already have configured NACM rules.
>
>> [3] the proposed text leads to increased processing of large number of
>> validation checks which is very unlikely to bring real value to YANG. 20
>> non-presence containers with must statements per interface in
>> 96-interface switch is already heavy Xpath evaluation task. A task that
>> in YANG 1.0 was not necessary if the containers were not explicitly
>> created.
> Some implementations did it anyway and some didn't, which was considered
> a problem.
The implementations that did it anyway were not conforming to YANG 1.0 
since non-presence containers were not part of the configuration tree by 
default unless they were explicitly created. By introducing the Y41 
"clarification" now they are conforming which is the only benefit at the 
cost of limited validation expression flexibility, higher validation 
workload, broken NACM and probably some other issues we are about to 
discover.
>
>> [4] the proposed text leads to less flexibility and excludes certain
>> practical validation models e.g.
>> https://www.ietf.org/mail-archive/web/netconf/current/msg11609.html
> Well... If the goal it to prevent np2_leaf from appearing when np1_leaf
> is configured, then the most natural solution is to put a must statement on
> np1_leaf:
>
> leaf np1_leaf {
>    type string;
>    must "not(../../np2/np2_leaf)";
> }
>
> Or if you insisted on having it on the "np1" container, you can do this:
>
>    must "not(np1_leaf) or not(../np2/np2_leaf)";
Yes there are workarounds but the solution I propose is to remove the 
cause leading to the limitation and the need to use workarounds. If it 
is too late at least there will be a trace in the netmod mailing list 
indicating the issue was recognized before the publication of the RFC 
and something to consider in YANG 1.2

Vladimir
>
> Lada
>
>> [5] the proposed text inflicts problems 1-4 and its clarification effect
>> is not working for me.
>>
>> I have a concrete proposal for a solution on the issue - remove the
>> "non-presence containers MAY be deleted automatically" text from YANG
>> 1.1 instead of opening Pandora's box:
>>
>> Instead of building further the pipe dream of non-presence containers
>> that MAY be deleted automatically I propose that flexibility removed
>> from YANG 1.1. All non-presence containers have to be created explicitly
>> and the validation statements must be evaluated only for explicitly
>> created containers (so long there is no change from YANG 1.0) and these
>> containers MUST be deleted explicitly (replacing the "MAY be deleted
>> automatically" YANG 1.0 optimization attempt which is the origin of the
>> pipe dream) as one would logically expect. It is semantical meaning that
>> is not present not the container which still has its usage giving
>> structure to the data and especially in cases like NACM and validation
>> statements where without certain explicit create/delete rules things get
>> really confusing.
>>
>> The concrete proposal in form of a patch to RFC6020 sent in this e-mail
>> to the netconf mailing list:
>> https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html
>> There will be even more obsoleted clarification text that will be
>> irrelevant if the concept change is applied to YANG 1.1
>>
>> Vladimir
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Aug 22 06:36:57 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 0F68212D193 for ; Mon, 22 Aug 2016 06:36:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 iUi1dGeaEgF3 for ; Mon, 22 Aug 2016 06:36:53 -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 5CF0E126FDC for ; Mon, 22 Aug 2016 06:36:52 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:c91d:9203:b6d5:6ec4] (unknown [IPv6:2001:718:1a02:1:c91d:9203:b6d5:6ec4]) by mail.nic.cz (Postfix) with ESMTPSA id E71D160DD4; Mon, 22 Aug 2016 15:36:50 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471873011; bh=9TECtCFUBgE+9Orf2BVi1Y3r61W3778VWiRa39BQSlE=; h=From:Date:To; b=km3BeQz0eXztzqIUcn6W/s1w0PzWeOkXlJ/37vwG31g+XLIrnwpyZEJoIBr0QW6lS VtfFKt+m+vCLTXrbVIASfUb/wetCtJmRgrMfAAcHsxM4rqm12C6yCDhEmUnkVqTdH1 XO/xiXlkQaMq0P5rt3vRmyorcY8gB+T0UjIZhorc=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <57BAF672.60308@transpacket.com>
Date: Mon, 22 Aug 2016 15:36:51 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz>
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>  <57BAF672.60308@transpacket.com>
To: Vladimir Vassilev 
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] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 13:36:56 -0000

> On 22 Aug 2016, at 14:56, Vladimir Vassilev  =
wrote:
>=20
> On 08/22/2016 01:56 PM, Ladislav Lhotka wrote:
>> Vladimir Vassilev  writes:
>>=20
>>> On 08/20/2016 10:29 AM, Juergen Schoenwaelder wrote:
>>>> As document shepherd, I believe there is no strong agreement on the
>>>> problem and there is no concrete proposal with strong consensus for =
a
>>>> modification of the document (which is in AUTH48). In fact, there =
has
>>>> been no defect description and proposed bug fix at all on the =
NETMOD
>>>> mailing list.
>>> Hello,
>>>=20
>>> I have strong objection to the text proposed as solution to issue =
#41:
>>>=20
>>> 6.4.1 Xpath Context:
>>>=20
>>>      If a node that exists in the accessible tree has a non-presence
>>>      container as a child, then the non-presence container also =
exists in
>>>      the tree.
>>>=20
>>> The description of the issue itself is:
>>>=20
>>>      Y41: clarification of "must" in NP-container <>
>>>=20
>>>=20
>>> I believe the 5 mails in the
>>> http://www.ietf.org/mail-archive/web/netmod/current/msg10015.html =
did
>>> not address all the negative consequences of such change in the =
rules
>>> for evaluation of validation statements regarding non-presence
>>> containers and the solution that was taken is not acceptable for the
>>> following reasons:
>>>=20
>>> [1] the proposed text is not a clarification as indicated in Y41 but =
a
>>> backward incompatible change of the YANG validation statement =
evaluation
>>> rules.
>> The charter doesn't limit YANG 1.1 to clarifications. The adopted
>> solution addresses ambiguous cases like this:
>>=20
>> container top {
>>   must "foo > 42";
>>   leaf foo {
>>     type uint8;
>>   }
>>   leaf bar {
>>     type boolean;
>>     default true;
>>   }
>> }
>>=20
>> If "top" doesn't exist, then according to sec. 7.6.1 of RFC 6020, the
>> default value of "bar" is in use, so somehow the NP-container "top"
>> should also be in use. The question then arises whether the "must"
>> constraint applies or not.
> This example is based on the bug I propose to be fixed. If you looked =
at the patch I propose in =
https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html sec. =
7.1.6 of RFC 6020 is modified:
>=20
> ---
> OLD:
> 7.6.1.  The leaf's default value
>=20
>   The default value of a leaf is the value that the server uses if the
>   leaf does not exist in the data tree.  The usage of the default =
value
>   depends on the leaf's closest ancestor node in the schema tree that
>   is not a non-presence container:
>=20
> NEW:
> 7.6.1.  The leaf's default value
>=20
>   The default value of a leaf is the value that the server uses if the
>   leaf does not exist in the data tree.  The usage of the default =
value
>   depends on the leaf's closest ancestor node in the schema tree:

This would effectively remove the distinction between presence and =
non-presence containers, and I am not in favour of doing so. In any =
case, this is not something to introduce in the AUTH48 stage.

> ---
> The patch removes the "MAY be deleted" text and all artifacts =
resulting from poor attempts to cover the logical discontinuity it =
inflicts on YANG. It is the only justification of all special case =
clarifications regarding non-presence containers which are never going =
to be enough to cover all private cases.
>>=20
>>> [2] the clarification introduces further confusion for models like =
NACM
>>> where non-presence containers are used for access control and their
>>> explicit creation and deletion is the only sane way to enforce the
>>> configured rules. Always present non-presence containers that MAY be
>>> auto deleted by servers ... how will this work exactly?
>> IMO the problem is in this auto-deletion option. I suspect my example
>> above may also be unclear from the NACM point of view - do the rules =
set
>> for "top" apply if "top" hasn't been explicitly configured?
> +1 I do not know either. NACM is affected in a bad way. The "MAY be =
deleted" text was not that bad since one would assume sane servers would =
not auto delete data nodes which already have configured NACM rules.
>>=20
>>> [3] the proposed text leads to increased processing of large number =
of
>>> validation checks which is very unlikely to bring real value to =
YANG. 20
>>> non-presence containers with must statements per interface in
>>> 96-interface switch is already heavy Xpath evaluation task. A task =
that
>>> in YANG 1.0 was not necessary if the containers were not explicitly
>>> created.
>> Some implementations did it anyway and some didn't, which was =
considered
>> a problem.
> The implementations that did it anyway were not conforming to YANG 1.0 =
since non-presence containers were not part of the configuration tree by =
default unless they were explicitly created.

This wasn't clear in cases like my example.

> By introducing the Y41 "clarification" now they are conforming which =
is the only benefit at the cost of limited validation expression =
flexibility, higher validation workload, broken NACM and probably some =
other issues we are about to discover.

I don't agree with this conclusion. NACM probably needs to be updated =
anyway.

>>=20
>>> [4] the proposed text leads to less flexibility and excludes certain
>>> practical validation models e.g.
>>> https://www.ietf.org/mail-archive/web/netconf/current/msg11609.html
>> Well... If the goal it to prevent np2_leaf from appearing when =
np1_leaf
>> is configured, then the most natural solution is to put a must =
statement on
>> np1_leaf:
>>=20
>> leaf np1_leaf {
>>   type string;
>>   must "not(../../np2/np2_leaf)";
>> }
>>=20
>> Or if you insisted on having it on the "np1" container, you can do =
this:
>>=20
>>   must "not(np1_leaf) or not(../np2/np2_leaf)";
> Yes there are workarounds but the solution I propose is to remove the =
cause leading to the limitation and the need to use workarounds. If it =
is too late at least there will be a trace in the netmod mailing list =
indicating the issue was recognized before the publication of the RFC =
and something to consider in YANG 1.2

I don't see it as a workaround and I don't think there is ANY limitation =
whatsoever due to this. The rules are now clear, which is a good thing.

Lada
=20
>=20
> Vladimir
>>=20
>> Lada
>>=20
>>> [5] the proposed text inflicts problems 1-4 and its clarification =
effect
>>> is not working for me.
>>>=20
>>> I have a concrete proposal for a solution on the issue - remove the
>>> "non-presence containers MAY be deleted automatically" text from =
YANG
>>> 1.1 instead of opening Pandora's box:
>>>=20
>>> Instead of building further the pipe dream of non-presence =
containers
>>> that MAY be deleted automatically I propose that flexibility removed
>>> from YANG 1.1. All non-presence containers have to be created =
explicitly
>>> and the validation statements must be evaluated only for explicitly
>>> created containers (so long there is no change from YANG 1.0) and =
these
>>> containers MUST be deleted explicitly (replacing the "MAY be deleted
>>> automatically" YANG 1.0 optimization attempt which is the origin of =
the
>>> pipe dream) as one would logically expect. It is semantical meaning =
that
>>> is not present not the container which still has its usage giving
>>> structure to the data and especially in cases like NACM and =
validation
>>> statements where without certain explicit create/delete rules things =
get
>>> really confusing.
>>>=20
>>> The concrete proposal in form of a patch to RFC6020 sent in this =
e-mail
>>> to the netconf mailing list:
>>> https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html
>>> There will be even more obsoleted clarification text that will be
>>> irrelevant if the concept change is applied to YANG 1.1
>>>=20
>>> Vladimir
>>>=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 Aug 22 07:04: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 30BD512D534 for ; Mon, 22 Aug 2016 07:04:34 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.321
X-Spam-Level: 
X-Spam-Status: No, score=-1.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MANY_SPAN_IN_TEXT=2.899, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I0_oK6lUnZrf for ; Mon, 22 Aug 2016 07:04:32 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 899BB12D512 for ; Mon, 22 Aug 2016 07:04:31 -0700 (PDT)
X-AuditID: c1b4fb2d-903ff700000019a3-86-57bb066b4731
Received: from ESGSCHC005.ericsson.se (Unknown_Domain [146.11.116.80]) by  (Symantec Mail Security) with SMTP id A4.CB.06563.C660BB75; Mon, 22 Aug 2016 16:04:29 +0200 (CEST)
Received: from ESGSCMB103.ericsson.se ([169.254.3.181]) by ESGSCHC005.ericsson.se ([146.11.116.80]) with mapi id 14.03.0301.000; Mon, 22 Aug 2016 22:04:27 +0800
From: Adrian Pan 
To: Dean Bogdanovic 
Thread-Topic: Question about acl-type in draft-ietf-netmod-acl-model-08
Thread-Index: AdH8PD4i48XDLWwOTSWOv9sixPEsCv//s0+A//85uMA=
Date: Mon, 22 Aug 2016 14:04:26 +0000
Message-ID: <7F859F89F9B4DD4DB902232F9E2DAC083873C9AD@ESGSCMB103.ericsson.se>
References: <7F859F89F9B4DD4DB902232F9E2DAC083873C373@ESGSCMB103.ericsson.se> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [146.11.116.8]
Content-Type: multipart/alternative; boundary="_000_7F859F89F9B4DD4DB902232F9E2DAC083873C9ADESGSCMB103erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrNIsWRmVeSWpSXmKPExsUyibskQDeXbXe4wfIP+hZrF/1ntdj58hWL Rcv0mYwWTTv7WC3mX2xkdWD1mPJ7I6vHzll32T2WLPnJFMAcxWWTkpqTWZZapG+XwJXR9e86 a8GhtWwVT5/eZWpgPDCDrYuRk0NCwESib/9uli5GLg4hgfWMEgsav7JDOEsYJY7PnMIEUsUm oCVx9MgqVhBbREBD4tXp+2BFzCBFi27OYgZJCAu4Sbz8/Ywdoshd4s6n6YxdjBxAtpXEhfW2 IGEWAVWJi19OgG3mFfCVWPTlOjPEsgZGiV2Pv4Et4BSwldhzZgrYHEYBMYnvp9aAHcEsIC5x 68l8JoizBSSW7DnPDGGLSrx8/I8VwlaQOLBoCVR9vsT871eglglKnJz5hGUCo8gsJKNmISmb haRsFtDZzAKaEut36UOUKEpM6X7IDmFrSLTOmcuOLL6AkX0Vo2hxanFxbrqRsV5qUWZycXF+ nl5easkmRmAUHtzyW3cH4+rXjocYBTgYlXh4Fd7sDBdiTSwrrsw9xCjBwawkwjuXdXe4EG9K YmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2ampBalFMFkmDk6pBsbkN0eeJn9jmazi umKu6/UdqzZ/5RRUajbdcMSGceqCpa9nyPtv6D4VsDOowJK5zfbG68L/p+sCW14lNe173mcr KhO5++2OK7VaPLobsjxmvJWaxfL8Ob/eNIXENz9SFbe/2176/l3gNON3wisP8MUrph4Ie5M3 l9N039bjpbPybpwVy1bbIjJXiaU4I9FQi7moOBEAMmCZZb4CAAA=
Archived-At: 
Cc: "kkoushik@cisco.com" , netmod WG 
Subject: Re: [netmod] Question about acl-type in draft-ietf-netmod-acl-model-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: Mon, 22 Aug 2016 14:04:34 -0000

--_000_7F859F89F9B4DD4DB902232F9E2DAC083873C9ADESGSCMB103erics_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

SGkgRGVhbiwNCg0KMykgICBXaXRoIHRoZSBtb2RlbCBkZWZpbml0aW9uLCBldmVuIHRoZSBhY2wt
dHlwZSBpcyBjb25maWd1cmVkIGFzIEV0aGVybmV0LCB0aGUgb3BlcmF0b3Igc3RpbGwgY2FuIGNv
bmZpZ3VyZSB0aGUgbWF0Y2hlcyBvZiBhY2UgdW5kZXIgdGhlIGFjbCBhcyBpcHY0IG9yIGlwdjYs
IHJpZ2h0Pw0KDQpObywgaWYgQUNMIHR5cGUgaXMgZXRoZXJuZXQsIHRoZW4gYWxsIEFDRXMgYXJl
IGV4cGVjdGVkIHRvIGJlIGV0aGVybmV0Lg0KW0Fkcmlhbl0gSSB1bmRlcnN0YW5kIHlvdXIgcG9p
bnQsIGJ1dCB0aGlzIGlzIG5vdCByZWZsZWN0ZWQgaW4gdGhlIG1vZGVsLCBpZiBhY2NvcmRpbmcg
dG8gdGhlIG1vZGVsLCB0aGUgb3BlcmF0b3Igc3RpbGwgY2FuIGNvbmZpZ3VyZSB0aGUgYWNsLXR5
cGUgYXMgRXRoZXJuZXQsIHdoaWxlIGNvbmZpZ3VyZSB0aGUgYWNlIG9mIHRoZSBhY2wgYXMgaXB2
NCwgYW5kIHRoaXMgc2hvdWxkIGJlIHZhbGlkIGNvbmZpZ3VyYXRpb24uDQoNCmlzIHRoaXMgdGhl
IG1vZGVsIGRlc2lnbiBpbnRlbnRpb24/DQoNCklmIGFjbC10eXBlIGlzIG9mIG9uZSBmYW1pbHks
IHRoZW4gb25seSBhY2Ugd2l0aCBtYXRjaCBjb25kaXRpb24gZnJvbSB0aGF0IGZhbWlseSBhcmUg
ZXhwZWN0ZWQgdG8gYmUgaW4gdGhlIGFjbC4gSWYgeW91IHdhbnQgdG8gY29tYmluZSB0aGVtLCBw
bGVhc2UgdXNlIG1peGVkIHR5cGUuDQpbQWRyaWFuXSBpZiBpdOKAmXMgb25seSBleHBlY3RlZCB0
byBiZSB0aGUgc2FtZSBhcyB0aGUgYWNsLXR5cGUsIGJ1dCB3aXRob3V0IHRoZSByZXN0cmljdGlv
biBpbiB0aGUgbW9kZWwsIHlvdSBjYW7igJl0IGF2b2lkIHRoZSBvcGVyYXRvciBjb25maWd1cmF0
aW9uIHRvIG1peCB0aGUgYWNsLXR5cGUgYW5kIHRoZSBhY2UgbWF0Y2hlcy4gU28gbXkgdGhpbmtp
bmcgaXMgdGhhdCwgY2FuIHdlIGFkZCB0aGUgcmVzdHJpY3Rpb24gaW4gdGhlIG1vZGVsIGZvciB0
aGlzIGFzIGJlbG93IHRvIGJldHRlciByZWZsZWN0IHRoZSBtb2RlbCBkZXNpZ24gaW50ZW50aW9u
Pw0KDQoNCg0KY29udGFpbmVyIG1hdGNoZXMgew0KICBkZXNjcmlwdGlvbg0KICAgICJEZWZpbml0
aW9ucyBmb3IgbWF0Y2ggY3JpdGVyaWEgZm9yIHRoaXMgQWNjZXNzIExpc3QNCkVudHJ5LiI7DQoN
CiAgY29udGFpbmVyIGFjZS1pcHY0IHsNCiAgICB3aGVuICIuLi8uLi9hY2wtdHlwZT0naXB2NC1h
Y2wnIjsNCiAgICBkZXNjcmlwdGlvbiAiSVB2NCBBY2Nlc3MgTGlzdCBFbnRyeS4iOw0KICAgIHVz
ZXMgcGFja2V0LWZpZWxkczphY2wtaXAtaGVhZGVyLWZpZWxkczsNCiAgICB1c2VzIHBhY2tldC1m
aWVsZHM6YWNsLWlwdjQtaGVhZGVyLWZpZWxkczsNCiAgfQ0KICBjb250YWluZXIgYWNlLWlwdjYg
ew0KICAgIHdoZW4gIi4uLy4uL2FjbC10eXBlPSdpcHY2LWFjbCciOw0KICAgIGRlc2NyaXB0aW9u
ICJJUHY2IEFjY2VzcyBMaXN0IEVudHJ5LiI7DQogICAgdXNlcyBwYWNrZXQtZmllbGRzOmFjbC1p
cC1oZWFkZXItZmllbGRzOw0KICAgIHVzZXMgcGFja2V0LWZpZWxkczphY2wtaXB2Ni1oZWFkZXIt
ZmllbGRzOw0KICB9DQogIGNvbnRhaW5lciBhY2UtZXRoIHsNCiAgICB3aGVuICIuLi8uLi9hY2wt
dHlwZT0nZXRoLWFjbCciOw0KICAgIGRlc2NyaXB0aW9uDQogICAgICAiRXRoZXJuZXQgQWNjZXNz
IExpc3QgZW50cnkuIjsNCiAgICB1c2VzIHBhY2tldC1maWVsZHM6YWNsLWV0aC1oZWFkZXItZmll
bGRzOw0KICB9DQp9DQoNCg0KVGhhbmtzDQpBZHJpYW4NCg0KRnJvbTogRGVhbiBCb2dkYW5vdmlj
IFttYWlsdG86aXZhbmRlYW5AZ21haWwuY29tXQ0KU2VudDogTW9uZGF5LCBBdWd1c3QgMjIsIDIw
MTYgNTozOSBQTQ0KVG86IEFkcmlhbiBQYW4gPGFkcmlhbi5wYW5AZXJpY3Nzb24uY29tPg0KQ2M6
IGtrb3VzaGlrQGNpc2NvLmNvbTsgbHlpaHVhbmcxNkBnbWFpbC5jb207IGRibGFpckBjaXNjby5j
b207IG5ldG1vZCBXRyA8bmV0bW9kQGlldGYub3JnPg0KU3ViamVjdDogUmU6IFF1ZXN0aW9uIGFi
b3V0IGFjbC10eXBlIGluIGRyYWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC0wOA0KDQooK25ldG1v
ZCBtYWlsaW5nIGxpc3QpDQpBZHJpYW4sDQoNClBsZWFzZSBzZWUgaW5saW5lDQpPbiBBdWcgMjIs
IDIwMTYsIGF0IDI6MjcgQU0sIEFkcmlhbiBQYW4gPGFkcmlhbi5wYW5AZXJpY3Nzb24uY29tPG1h
aWx0bzphZHJpYW4ucGFuQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQpEZWFyIGF1dGhvcnMsDQoN
CkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dCBpZXRmIGFjbCBtb2RlbCBhcyBiZWxvdywgeW91
ciByZXBseSBpcyBhcHByZWNpYXRlZC4NCg0KMSkgICBJbiB0aGUgbW9kZWwgZGVmaW5pdGlvbiBh
Y2wtdHlwZSBpcyBvbmUga2V5IG9mIHRoZSBhY2wsIGFsc28gaW4gdGhlIGRlc2NyaXB0aW9uIGl0
IHNheXMgdGhhdCB0aGUgYWNsLXR5cGUgY291bGQgYmUgZXRoZXJuZXQsIElQdjQsIElQdjYsIG1p
eGVkLCBpbiBjYXNlIHRoZSBhY2wtdHlwZSBpcyBtaXhlZCwgd2hhdOKAmXMgdGhlIGlkZW50aWZp
ZXIgc2hvdWxkIGJlPw0KU2hvdWxkIGl0IGJlIGF1Z21lbnRlZCBieSBkaWZmZXJlbnQgdmVuZG9y
PyBTaW5jZSBJIGRvbuKAmXQgc2VlIHRoZSBkZWZpbml0aW9uIGFib3V0IGl0Lg0KDQpBcyBtaXhl
ZCBBQ0xzIGFyZSBub3Qgc3VwcG9ydGVkIGJ5IGFsbCB2ZW5kb3JzLCB0aG9zZSBhcmUgbm90IHBh
cnQgb2YgdGhlIHN0YW5kYXJkIG1vZGVsLiBJaXQgaXMgdXAgdG8gdGhlIHZlbmRvciB0byBhdWdt
ZW50IHRoZSBhY2UtdHlwZSBhbmQgc2VsZWN0IGFuIGlkZW50aWZpZXIgdG8gdGhlaXIgbGlraW5n
Lg0KDQoNCjIpICAgSW4gdGhlIOKAnG1peOKAnSBjYXNlLCB0aGUg4oCcbWF0Y2hlc+KAnSB0aGUg
YWNlIGxpc3QgY2FuIGJlIHRoZSBjb21iaW5hdGlvbiBvZiBFdGhlcm5ldCxpcHY0LGlwdjYgZm9y
IGRpZmZlcmVudCBhY2UsIHJpZ2h0Pw0KDQpPciBhbm90aGVyIGNvbWJpbmF0aW9uLCBhZ2FpbiBk
ZXBlbmRzIG9uIHdoYXQgdGhhdCBwYXJ0aWN1bGFyIHZlbmRvciBzdXBwb3J0cy4NCg0KMykgICBX
aXRoIHRoZSBtb2RlbCBkZWZpbml0aW9uLCBldmVuIHRoZSBhY2wtdHlwZSBpcyBjb25maWd1cmVk
IGFzIEV0aGVybmV0LCB0aGUgb3BlcmF0b3Igc3RpbGwgY2FuIGNvbmZpZ3VyZSB0aGUgbWF0Y2hl
cyBvZiBhY2UgdW5kZXIgdGhlIGFjbCBhcyBpcHY0IG9yIGlwdjYsIHJpZ2h0Pw0KDQpObywgaWYg
QUNMIHR5cGUgaXMgZXRoZXJuZXQsIHRoZW4gYWxsIEFDRXMgYXJlIGV4cGVjdGVkIHRvIGJlIGV0
aGVybmV0Lg0KDQppcyB0aGlzIHRoZSBtb2RlbCBkZXNpZ24gaW50ZW50aW9uPw0KDQpJZiBhY2wt
dHlwZSBpcyBvZiBvbmUgZmFtaWx5LCB0aGVuIG9ubHkgYWNlIHdpdGggbWF0Y2ggY29uZGl0aW9u
IGZyb20gdGhhdCBmYW1pbHkgYXJlIGV4cGVjdGVkIHRvIGJlIGluIHRoZSBhY2wuIElmIHlvdSB3
YW50IHRvIGNvbWJpbmUgdGhlbSwgcGxlYXNlIHVzZSBtaXhlZCB0eXBlLg0KDQpEZWFuDQoNCg0K
DQptb2R1bGU6IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdA0KDQogICArLS1ydyBhY2Nlc3MtbGlz
dHMNCg0KICAgICAgKy0tcncgYWNsKiBbYWNsLXR5cGUgYWNsLW5hbWVdDQoNCiAgICAgICAgICst
LXJ3IGFjbC1uYW1lICAgICAgICAgICAgICAgc3RyaW5nDQoNCiAgICAgICAgICstLXJ3IGFjbC10
eXBlICAgICAgICAgICAgICAgYWNsLXR5cGUNCg0KICAgICAgICAgKy0tcm8gYWNsLW9wZXItZGF0
YQ0KDQogICAgICAgICArLS1ydyBhY2Nlc3MtbGlzdC1lbnRyaWVzDQoNCiAgICAgICAgICAgICst
LXJ3IGFjZSogW3J1bGUtbmFtZV0NCg0KICAgICAgICAgICAgICAgKy0tcncgcnVsZS1uYW1lICAg
ICAgICBzdHJpbmcNCg0KICAgICAgICAgICAgICAgKy0tcncgbWF0Y2hlcw0KDQogICAgICAgICAg
ICAgICB8ICArLS1ydyAoYWNlLXR5cGUpPw0KDQogICAgICAgICBsZWFmIGFjbC10eXBlIHsNCiAg
ICAgICAgICAgdHlwZSBhY2wtdHlwZTsNCiAgICAgICAgICAgZGVzY3JpcHRpb24NCiAgICAgICAg
ICJUeXBlIG9mIGFjY2VzcyBjb250cm9sIGxpc3QuIEluZGljYXRlcyB0aGUgcHJpbWFyeSBpbnRl
bmRlZA0KICAgICAgICAgdHlwZSBvZiBtYXRjaCBjcml0ZXJpYSAoZS5nLiBldGhlcm5ldCwgSVB2
NCwgSVB2NiwgbWl4ZWQsIGV0YykNCiAgICAgICAgIHVzZWQgaW4gdGhlIGxpc3QgaW5zdGFuY2Uu
IjsNCiAgICAgICAgIH0NCg0KDQoNClRoYW5rcw0KQWRyaWFuDQoNCg==

--_000_7F859F89F9B4DD4DB902232F9E2DAC083873C9ADESGSCMB103erics_
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy
bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt
YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6eD0idXJuOnNjaGVtYXMtbWljcm9z
b2Z0LWNvbTpvZmZpY2U6ZXhjZWwiIHhtbG5zOm09Imh0dHA6Ly9zY2hlbWFzLm1pY3Jvc29mdC5j
b20vb2ZmaWNlLzIwMDQvMTIvb21tbCIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnL1RSL1JFQy1o
dG1sNDAiPg0KPGhlYWQ+DQo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9
InRleHQvaHRtbDsgY2hhcnNldD11dGYtOCI+DQo8bWV0YSBuYW1lPSJQcm9nSWQiIGNvbnRlbnQ9
IldvcmQuRG9jdW1lbnQiPg0KPG1ldGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3Nv
ZnQgV29yZCAxNSI+DQo8bWV0YSBuYW1lPSJPcmlnaW5hdG9yIiBjb250ZW50PSJNaWNyb3NvZnQg
V29yZCAxNSI+DQo8bGluayByZWw9IkZpbGUtTGlzdCIgaHJlZj0iY2lkOmZpbGVsaXN0LnhtbEAw
MUQxRkNDMS4yMTZDMkMwMCI+PCEtLVtpZiBndGUgbXNvIDldPjx4bWw+DQo8bzpPZmZpY2VEb2N1
bWVudFNldHRpbmdzPg0KPG86QWxsb3dQTkcvPg0KPC9vOk9mZmljZURvY3VtZW50U2V0dGluZ3M+
DQo8L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OldvcmREb2N1
bWVudD4NCjx3OlNwZWxsaW5nU3RhdGU+Q2xlYW48L3c6U3BlbGxpbmdTdGF0ZT4NCjx3OkRvY3Vt
ZW50S2luZD5Eb2N1bWVudEVtYWlsPC93OkRvY3VtZW50S2luZD4NCjx3OlRyYWNrTW92ZXMvPg0K
PHc6VHJhY2tGb3JtYXR0aW5nLz4NCjx3OkVudmVsb3BlVmlzLz4NCjx3OlZhbGlkYXRlQWdhaW5z
dFNjaGVtYXMvPg0KPHc6U2F2ZUlmWE1MSW52YWxpZD5mYWxzZTwvdzpTYXZlSWZYTUxJbnZhbGlk
Pg0KPHc6SWdub3JlTWl4ZWRDb250ZW50PmZhbHNlPC93Oklnbm9yZU1peGVkQ29udGVudD4NCjx3
OkFsd2F5c1Nob3dQbGFjZWhvbGRlclRleHQ+ZmFsc2U8L3c6QWx3YXlzU2hvd1BsYWNlaG9sZGVy
VGV4dD4NCjx3OkRvTm90UHJvbW90ZVFGLz4NCjx3OkxpZFRoZW1lT3RoZXI+RU4tVVM8L3c6TGlk
VGhlbWVPdGhlcj4NCjx3OkxpZFRoZW1lQXNpYW4+WkgtQ048L3c6TGlkVGhlbWVBc2lhbj4NCjx3
OkxpZFRoZW1lQ29tcGxleFNjcmlwdD5YLU5PTkU8L3c6TGlkVGhlbWVDb21wbGV4U2NyaXB0Pg0K
PHc6Q29tcGF0aWJpbGl0eT4NCjx3OkRvTm90RXhwYW5kU2hpZnRSZXR1cm4vPg0KPHc6QnJlYWtX
cmFwcGVkVGFibGVzLz4NCjx3OlNwbGl0UGdCcmVha0FuZFBhcmFNYXJrLz4NCjx3OkVuYWJsZU9w
ZW5UeXBlS2VybmluZy8+DQo8L3c6Q29tcGF0aWJpbGl0eT4NCjxtOm1hdGhQcj4NCjxtOm1hdGhG
b250IG06dmFsPSJDYW1icmlhIE1hdGgiLz4NCjxtOmJya0JpbiBtOnZhbD0iYmVmb3JlIi8+DQo8
bTpicmtCaW5TdWIgbTp2YWw9IiYjNDU7LSIvPg0KPG06c21hbGxGcmFjIG06dmFsPSJvZmYiLz4N
CjxtOmRpc3BEZWYvPg0KPG06bE1hcmdpbiBtOnZhbD0iMCIvPg0KPG06ck1hcmdpbiBtOnZhbD0i
MCIvPg0KPG06ZGVmSmMgbTp2YWw9ImNlbnRlckdyb3VwIi8+DQo8bTp3cmFwSW5kZW50IG06dmFs
PSIxNDQwIi8+DQo8bTppbnRMaW0gbTp2YWw9InN1YlN1cCIvPg0KPG06bmFyeUxpbSBtOnZhbD0i
dW5kT3ZyIi8+DQo8L206bWF0aFByPjwvdzpXb3JkRG9jdW1lbnQ+DQo8L3htbD48IVtlbmRpZl0t
LT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjx3OkxhdGVudFN0eWxlcyBEZWZMb2NrZWRTdGF0
ZT0iZmFsc2UiIERlZlVuaGlkZVdoZW5Vc2VkPSJmYWxzZSIgRGVmU2VtaUhpZGRlbj0iZmFsc2Ui
IERlZlFGb3JtYXQ9ImZhbHNlIiBEZWZQcmlvcml0eT0iOTkiIExhdGVudFN0eWxlQ291bnQ9IjM3
MiI+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjAiIFFGb3JtYXQ9
InRydWUiIE5hbWU9Ik5vcm1hbCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI5IiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDEiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRpbmcgMiIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0iaGVhZGluZyAzIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjkiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJoZWFkaW5nIDQi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iOSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRydWUiIE5hbWU9ImhlYWRp
bmcgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI5IiBTZW1p
SGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1ZSIgTmFtZT0i
aGVhZGluZyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijki
IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBRRm9ybWF0PSJ0cnVlIiBO
YW1lPSJoZWFkaW5nIDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIFFGb3JtYXQ9InRy
dWUiIE5hbWU9ImhlYWRpbmcgOCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1h
dD0idHJ1ZSIgTmFtZT0iaGVhZGluZyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDEi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJp
bmRleCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1
ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImluZGV4IDQiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg
TmFtZT0iaW5kZXggNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA2Ii8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9
InRydWUiIE5hbWU9ImluZGV4IDciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaW5kZXggOCIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo
ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJpbmRleCA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSIgTmFtZT0idG9jIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2Mg
MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9InRvYyAzIi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBV
bmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJ0b2MgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9
InRvYyA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjM5IiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9jIDciLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzkiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0b2MgOCIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzOSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiIE5hbWU9InRvYyA5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vcm1hbCBJ
bmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iZm9vdG5vdGUgdGV4dCIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iaGVhZGVy
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3RlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJp
bmRleCBoZWFkaW5nIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjM1IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZvcm1hdD0idHJ1
ZSIgTmFtZT0iY2FwdGlvbiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI
aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJ0YWJsZSBvZiBmaWd1cmVz
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5o
aWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImVudmVsb3BlIGFkZHJlc3MiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSIgTmFtZT0iZW52ZWxvcGUgcmV0dXJuIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImZvb3Rub3Rl
IHJlZmVyZW5jZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJhbm5vdGF0aW9uIHJlZmVyZW5jZSIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJsaW5lIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1l
PSJwYWdlIG51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRk
ZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHJlZmVyZW5jZSIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJlbmRub3RlIHRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt
ZT0idGFibGUgb2YgYXV0aG9yaXRpZXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0ibWFjcm8iLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSIgTmFtZT0idG9hIGhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
TGlzdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi
IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl
IiBOYW1lPSJMaXN0IE51bWJlciIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDIiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgTmFtZT0iTGlzdCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgNCIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlz
dCBCdWxsZXQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IEJ1bGxldCAzIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiIE5hbWU9Ikxpc3QgQnVsbGV0IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlz
dCBCdWxsZXQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciAyIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiIE5hbWU9Ikxpc3QgTnVtYmVyIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iTGlz
dCBOdW1iZXIgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IE51bWJlciA1Ii8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjEwIiBRRm9ybWF0PSJ0cnVlIiBO
YW1lPSJUaXRsZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJDbG9zaW5nIi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRy
dWUiIE5hbWU9IlNpZ25hdHVyZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSIxIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
RGVmYXVsdCBQYXJhZ3JhcGggRm9udCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhp
ZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl
IiBOYW1lPSJMaXN0IENvbnRpbnVlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3QgQ29udGlu
dWUgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi
IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJMaXN0IENvbnRpbnVlIDMiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgTmFtZT0iTGlzdCBDb250aW51ZSA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ikxpc3Qg
Q29udGludWUgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZXNzYWdlIEhlYWRlciIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIxMSIgUUZvcm1hdD0idHJ1ZSIg
TmFtZT0iU3VidGl0bGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iU2FsdXRhdGlvbiIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBOYW1lPSJEYXRlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJvZHkgVGV4dCBG
aXJzdCBJbmRlbnQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu
PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQm9keSBUZXh0IEZpcnN0IEluZGVu
dCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg
VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik5vdGUgSGVhZGluZyIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVl
IiBOYW1lPSJCb2R5IFRleHQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNl
bWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgMyIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJCb2R5IFRleHQgSW5kZW50IDIiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSIgTmFtZT0iQm9keSBUZXh0IEluZGVudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkJsb2Nr
IFRleHQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVl
IiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUi
IE5hbWU9IkZvbGxvd2VkSHlwZXJsaW5rIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjIyIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJTdHJvbmciLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMjAiIFFGb3JtYXQ9InRydWUiIE5hbWU9
IkVtcGhhc2lzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkRvY3VtZW50IE1hcCIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJQbGFpbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkUtbWFpbCBT
aWduYXR1cmUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBUb3Agb2YgRm9ybSIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEJvdHRvbSBvZiBGb3JtIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5h
bWU9Ik5vcm1hbCAoV2ViKSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI
aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIEFjcm9ueW0iLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBBZGRyZXNzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9
IkhUTUwgQ2l0ZSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49
InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJIVE1MIENvZGUiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0i
dHJ1ZSIgTmFtZT0iSFRNTCBEZWZpbml0aW9uIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwg
S2V5Ym9hcmQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0
cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBQcmVmb3JtYXR0ZWQiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgTmFtZT0iSFRNTCBTYW1wbGUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iSFRN
TCBUeXBld3JpdGVyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IkhUTUwgVmFyaWFibGUiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgTmFtZT0iTm9ybWFsIFRhYmxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9ImFu
bm90YXRpb24gc3ViamVjdCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlI
aWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJObyBMaXN0Ii8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVz
ZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91
dGxpbmUgTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9Ik91dGxpbmUgTGlzdCAzIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hl
blVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9
IlRhYmxlIFNpbXBsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFNpbXBsZSAzIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRl
V2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgMSIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBO
YW1lPSJUYWJsZSBDbGFzc2ljIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBT
ZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ2xhc3Np
YyAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIg
VW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENsYXNzaWMgNCIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0
cnVlIiBOYW1lPSJUYWJsZSBDb2xvcmZ1bCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxl
IENvbG9yZnVsIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVu
PSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgQ29sb3JmdWwgMyIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo
ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt
ZT0iVGFibGUgQ29sdW1ucyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt
aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIENvbHVtbnMg
MyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb2x1bW5zIDQiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSIgTmFtZT0iVGFibGUgQ29sdW1ucyA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgU2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdy
aWQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi
IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDIiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSIgTmFtZT0iVGFibGUgR3JpZCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
U2VtaUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQg
NCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVu
aGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDUiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIg
TmFtZT0iVGFibGUgR3JpZCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt
aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIEdyaWQgNyIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlk
ZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBHcmlkIDgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt
ZT0iVGFibGUgTGlzdCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhp
ZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgMiIvPg0K
PHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdo
ZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
VGFibGUgTGlzdCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRl
bj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgNSIvPg0KPHc6
THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5V
c2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBMaXN0IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFi
bGUgTGlzdCA3Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0i
dHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIExpc3QgOCIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2Vk
PSJ0cnVlIiBOYW1lPSJUYWJsZSAzRCBlZmZlY3RzIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0i
VGFibGUgM0QgZWZmZWN0cyAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt
aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIDNEIGVmZmVj
dHMgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRydWUi
IFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJsZSBDb250ZW1wb3JhcnkiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNl
ZD0idHJ1ZSIgTmFtZT0iVGFibGUgRWxlZ2FudCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFNlbWlIaWRkZW49InRydWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJUYWJs
ZSBQcm9mZXNzaW9uYWwiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDEiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVX
aGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgU3VidGxlIDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFt
ZT0iVGFibGUgV2ViIDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlk
ZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDIiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVu
VXNlZD0idHJ1ZSIgTmFtZT0iVGFibGUgV2ViIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgTmFtZT0iQmFs
bG9vbiBUZXh0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjU5
IiBOYW1lPSJUYWJsZSBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2Vt
aUhpZGRlbj0idHJ1ZSIgVW5oaWRlV2hlblVzZWQ9InRydWUiIE5hbWU9IlRhYmxlIFRoZW1lIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgU2VtaUhpZGRlbj0idHJ1ZSIgTmFtZT0i
UGxhY2Vob2xkZXIgVGV4dCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSIxIiBRRm9ybWF0PSJ0cnVlIiBOYW1lPSJObyBTcGFjaW5nIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIi8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBM
aXN0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYyIiBOYW1l
PSJMaWdodCBHcmlkIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRpdW0gU2hhZGluZyAyIi8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIi8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRp
dW0gTGlzdCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3
IiBOYW1lPSJNZWRpdW0gR3JpZCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9y
ZnVsIFNoYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NzIiIE5hbWU9IkNvbG9yZnVsIExpc3QiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNl
IiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDEi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9Ikxp
Z2h0IExpc3QgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50
IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9
Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDEiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBTZW1pSGlkZGVuPSJ0cnVlIiBOYW1lPSJSZXZpc2lv
biIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSIzNCIgUUZvcm1h
dD0idHJ1ZSIgTmFtZT0iTGlzdCBQYXJhZ3JhcGgiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iMjkiIFFGb3JtYXQ9InRydWUiIE5hbWU9IlF1b3RlIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMwIiBRRm9ybWF0PSJ0cnVlIiBO
YW1lPSJJbnRlbnNlIFF1b3RlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBOYW1lPSJNZWRpdW0gR3JpZCAxIEFjY2Vu
dCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1l
PSJNZWRpdW0gR3JpZCAyIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3JpZCAzIEFjY2VudCAxIi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNj
ZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5h
bWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9yZnVsIExpc3QgQWNjZW50IDEiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzMiIE5hbWU9IkNvbG9yZnVs
IEdyaWQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9IkxpZ2h0IExpc3QgQWNjZW50IDIiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0
IEdyaWQgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNj
ZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5h
bWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBMaXN0IDIgQWNjZW50IDIiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlk
IDEgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1lZGl1bSBHcmlkIDMgQWNjZW50IDIiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzAiIE5hbWU9IkRhcmsg
TGlzdCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFtZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQg
MiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MyIgTmFtZT0i
Q29sb3JmdWwgR3JpZCBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGluZyBBY2NlbnQgMyIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2Nl
bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFt
ZT0iTGlnaHQgR3JpZCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMSBBY2NlbnQgMyIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRp
bmcgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0iTWVkaXVtIExpc3QgMiBBY2NlbnQgMyIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NyIgTmFtZT0iTWVk
aXVtIEdyaWQgMSBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIgTmFtZT0iTWVkaXVtIEdyaWQgMyBBY2Nl
bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFt
ZT0iRGFyayBMaXN0IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFkaW5nIEFjY2VudCAzIi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0
IEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9Ijcz
IiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjYwIiBOYW1lPSJMaWdodCBTaGFkaW5nIEFjY2VudCA0Ii8+DQo8
dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjYxIiBOYW1lPSJMaWdodCBM
aXN0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjYyIiBOYW1lPSJMaWdodCBHcmlkIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjYzIiBOYW1lPSJNZWRpdW0gU2hhZGluZyAxIEFjY2VudCA0Ii8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY0IiBOYW1lPSJNZWRp
dW0gU2hhZGluZyAyIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjY1IiBOYW1lPSJNZWRpdW0gTGlzdCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY2IiBOYW1lPSJNZWRpdW0gTGlzdCAyIEFj
Y2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY3IiBO
YW1lPSJNZWRpdW0gR3JpZCAxIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjY4IiBOYW1lPSJNZWRpdW0gR3JpZCAyIEFjY2VudCA0Ii8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjY5IiBOYW1lPSJNZWRpdW0gR3Jp
ZCAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjcwIiBOYW1lPSJEYXJrIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNzEiIE5hbWU9IkNvbG9yZnVsIFNoYWRpbmcgQWNjZW50IDQiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNzIiIE5hbWU9IkNvbG9y
ZnVsIExpc3QgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNzMiIE5hbWU9IkNvbG9yZnVsIEdyaWQgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjAiIE5hbWU9IkxpZ2h0IFNoYWRpbmcgQWNjZW50
IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjEiIE5hbWU9
IkxpZ2h0IExpc3QgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNjIiIE5hbWU9IkxpZ2h0IEdyaWQgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjMiIE5hbWU9Ik1lZGl1bSBTaGFkaW5nIDEgQWNj
ZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjQiIE5h
bWU9Ik1lZGl1bSBTaGFkaW5nIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNjUiIE5hbWU9Ik1lZGl1bSBMaXN0IDEgQWNjZW50IDUiLz4NCjx3
OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjYiIE5hbWU9Ik1lZGl1bSBM
aXN0IDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNjciIE5hbWU9Ik1lZGl1bSBHcmlkIDEgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjgiIE5hbWU9Ik1lZGl1bSBHcmlkIDIgQWNjZW50IDUi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNjkiIE5hbWU9Ik1l
ZGl1bSBHcmlkIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNzAiIE5hbWU9IkRhcmsgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MSIgTmFtZT0iQ29sb3JmdWwgU2hhZGluZyBBY2Nl
bnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI3MiIgTmFt
ZT0iQ29sb3JmdWwgTGlzdCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFs
c2UiIFByaW9yaXR5PSI3MyIgTmFtZT0iQ29sb3JmdWwgR3JpZCBBY2NlbnQgNSIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MCIgTmFtZT0iTGlnaHQgU2hhZGlu
ZyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2
MSIgTmFtZT0iTGlnaHQgTGlzdCBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI2MiIgTmFtZT0iTGlnaHQgR3JpZCBBY2NlbnQgNiIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2MyIgTmFtZT0iTWVkaXVtIFNoYWRp
bmcgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI2NCIgTmFtZT0iTWVkaXVtIFNoYWRpbmcgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NSIgTmFtZT0iTWVkaXVtIExpc3QgMSBBY2NlbnQg
NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2NiIgTmFtZT0i
TWVkaXVtIExpc3QgMiBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI2NyIgTmFtZT0iTWVkaXVtIEdyaWQgMSBBY2NlbnQgNiIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OCIgTmFtZT0iTWVkaXVtIEdyaWQgMiBB
Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI2OSIg
TmFtZT0iTWVkaXVtIEdyaWQgMyBBY2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI3MCIgTmFtZT0iRGFyayBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjcxIiBOYW1lPSJDb2xvcmZ1bCBTaGFk
aW5nIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjcyIiBOYW1lPSJDb2xvcmZ1bCBMaXN0IEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjczIiBOYW1lPSJDb2xvcmZ1bCBHcmlkIEFjY2VudCA2Ii8+
DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjE5IiBRRm9ybWF0PSJ0
cnVlIiBOYW1lPSJTdWJ0bGUgRW1waGFzaXMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iMjEiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgRW1waGFzaXMi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iMzEiIFFGb3JtYXQ9
InRydWUiIE5hbWU9IlN1YnRsZSBSZWZlcmVuY2UiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iMzIiIFFGb3JtYXQ9InRydWUiIE5hbWU9IkludGVuc2UgUmVmZXJl
bmNlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjMzIiBRRm9y
bWF0PSJ0cnVlIiBOYW1lPSJCb29rIFRpdGxlIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjM3IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1
ZSIgTmFtZT0iQmlibGlvZ3JhcGh5Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIg
UHJpb3JpdHk9IjM5IiBTZW1pSGlkZGVuPSJ0cnVlIiBVbmhpZGVXaGVuVXNlZD0idHJ1ZSIgUUZv
cm1hdD0idHJ1ZSIgTmFtZT0iVE9DIEhlYWRpbmciLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNDEiIE5hbWU9IlBsYWluIFRhYmxlIDEiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDIiIE5hbWU9IlBsYWluIFRhYmxlIDIiLz4N
Cjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDMiIE5hbWU9IlBsYWlu
IFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDQi
IE5hbWU9IlBsYWluIFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNDUiIE5hbWU9IlBsYWluIFRhYmxlIDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDAiIE5hbWU9IkdyaWQgVGFibGUgTGlnaHQiLz4NCjx3Okxz
ZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUg
MSBMaWdodCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIg
TmFtZT0iR3JpZCBUYWJsZSAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iR3JpZCBUYWJsZSA1IERhcmsi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9Ikdy
aWQgVGFibGUgNiBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI1MiIgTmFtZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIi8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQg
QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDci
IE5hbWU9IkdyaWQgVGFibGUgMiBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCAxIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxl
IDQgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NTAiIE5hbWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCAxIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwg
QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIi
IE5hbWU9IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFj
Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBO
YW1lPSJHcmlkIFRhYmxlIDIgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgMiIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0
IEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUw
IiBOYW1lPSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgMiIvPg0KPHc6THNkRXhjZXB0aW9uIExv
Y2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFj
Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBO
YW1lPSJHcmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2Nl
bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFt
ZT0iR3JpZCBUYWJsZSAyIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDMiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBB
Y2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIg
TmFtZT0iR3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2Nr
ZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2Nl
bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFt
ZT0iR3JpZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9j
a2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJHcmlkIFRhYmxlIDEgTGlnaHQgQWNjZW50
IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9
IkdyaWQgVGFibGUgMiBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI0OCIgTmFtZT0iR3JpZCBUYWJsZSAzIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJHcmlkIFRhYmxlIDQgQWNj
ZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5h
bWU9IkdyaWQgVGFibGUgNSBEYXJrIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2Vk
PSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJHcmlkIFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50
IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9
IkdyaWQgVGFibGUgNyBDb2xvcmZ1bCBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tl
ZD0iZmFsc2UiIFByaW9yaXR5PSI0NiIgTmFtZT0iR3JpZCBUYWJsZSAxIExpZ2h0IEFjY2VudCA1
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJH
cmlkIFRhYmxlIDIgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNDgiIE5hbWU9IkdyaWQgVGFibGUgMyBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iR3JpZCBUYWJsZSA0IEFjY2Vu
dCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1l
PSJHcmlkIFRhYmxlIDUgRGFyayBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI1MSIgTmFtZT0iR3JpZCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA1
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJH
cmlkIFRhYmxlIDcgQ29sb3JmdWwgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9
ImZhbHNlIiBQcmlvcml0eT0iNDYiIE5hbWU9IkdyaWQgVGFibGUgMSBMaWdodCBBY2NlbnQgNiIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iR3Jp
ZCBUYWJsZSAyIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjQ4IiBOYW1lPSJHcmlkIFRhYmxlIDMgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9IkdyaWQgVGFibGUgNCBBY2NlbnQg
NiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0i
R3JpZCBUYWJsZSA1IERhcmsgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNTEiIE5hbWU9IkdyaWQgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNiIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iR3Jp
ZCBUYWJsZSA3IENvbG9yZnVsIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJm
YWxzZSIgUHJpb3JpdHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlz
dCBUYWJsZSAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ5
IiBOYW1lPSJMaXN0IFRhYmxlIDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIi8+DQo8dzpMc2RFeGNlcHRpb24g
TG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwi
Lz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxp
c3QgVGFibGUgNyBDb2xvcmZ1bCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFBy
aW9yaXR5PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCAxIi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIg
QWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgi
IE5hbWU9Ikxpc3QgVGFibGUgMyBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0i
ZmFsc2UiIFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCAxIi8+DQo8dzpM
c2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxl
IDUgRGFyayBBY2NlbnQgMSIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9y
aXR5PSI1MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCAxIi8+DQo8dzpMc2RF
eGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcg
Q29sb3JmdWwgQWNjZW50IDEiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlv
cml0eT0iNDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgMiIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFj
Y2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBO
YW1lPSJMaXN0IFRhYmxlIDMgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZh
bHNlIiBQcmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgMiIvPg0KPHc6THNk
RXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1
IERhcmsgQWNjZW50IDIiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0
eT0iNTEiIE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgMiIvPg0KPHc6THNkRXhj
ZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENv
bG9yZnVsIEFjY2VudCAyIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3Jp
dHk9IjQ2IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2Nl
bnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFt
ZT0iTGlzdCBUYWJsZSAzIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxz
ZSIgUHJpb3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDMiLz4NCjx3OkxzZEV4
Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBE
YXJrIEFjY2VudCAzIi8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9
IjUxIiBOYW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDMiLz4NCjx3OkxzZEV4Y2Vw
dGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xv
cmZ1bCBBY2NlbnQgMyIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5
PSI0NiIgTmFtZT0iTGlzdCBUYWJsZSAxIExpZ2h0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ3IiBOYW1lPSJMaXN0IFRhYmxlIDIgQWNjZW50
IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDgiIE5hbWU9
Ikxpc3QgVGFibGUgMyBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2Ui
IFByaW9yaXR5PSI0OSIgTmFtZT0iTGlzdCBUYWJsZSA0IEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNl
cHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUwIiBOYW1lPSJMaXN0IFRhYmxlIDUgRGFy
ayBBY2NlbnQgNCIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1
MSIgTmFtZT0iTGlzdCBUYWJsZSA2IENvbG9yZnVsIEFjY2VudCA0Ii8+DQo8dzpMc2RFeGNlcHRp
b24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUyIiBOYW1lPSJMaXN0IFRhYmxlIDcgQ29sb3Jm
dWwgQWNjZW50IDQiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0i
NDYiIE5hbWU9Ikxpc3QgVGFibGUgMSBMaWdodCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0NyIgTmFtZT0iTGlzdCBUYWJsZSAyIEFjY2VudCA1
Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ4IiBOYW1lPSJM
aXN0IFRhYmxlIDMgQWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQ
cmlvcml0eT0iNDkiIE5hbWU9Ikxpc3QgVGFibGUgNCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0
aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MCIgTmFtZT0iTGlzdCBUYWJsZSA1IERhcmsg
QWNjZW50IDUiLz4NCjx3OkxzZEV4Y2VwdGlvbiBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTEi
IE5hbWU9Ikxpc3QgVGFibGUgNiBDb2xvcmZ1bCBBY2NlbnQgNSIvPg0KPHc6THNkRXhjZXB0aW9u
IExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI1MiIgTmFtZT0iTGlzdCBUYWJsZSA3IENvbG9yZnVs
IEFjY2VudCA1Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjQ2
IiBOYW1lPSJMaXN0IFRhYmxlIDEgTGlnaHQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNDciIE5hbWU9Ikxpc3QgVGFibGUgMiBBY2NlbnQgNiIv
Pg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFByaW9yaXR5PSI0OCIgTmFtZT0iTGlz
dCBUYWJsZSAzIEFjY2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJp
b3JpdHk9IjQ5IiBOYW1lPSJMaXN0IFRhYmxlIDQgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlv
biBMb2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTAiIE5hbWU9Ikxpc3QgVGFibGUgNSBEYXJrIEFj
Y2VudCA2Ii8+DQo8dzpMc2RFeGNlcHRpb24gTG9ja2VkPSJmYWxzZSIgUHJpb3JpdHk9IjUxIiBO
YW1lPSJMaXN0IFRhYmxlIDYgQ29sb3JmdWwgQWNjZW50IDYiLz4NCjx3OkxzZEV4Y2VwdGlvbiBM
b2NrZWQ9ImZhbHNlIiBQcmlvcml0eT0iNTIiIE5hbWU9Ikxpc3QgVGFibGUgNyBDb2xvcmZ1bCBB
Y2NlbnQgNiIvPg0KPHc6THNkRXhjZXB0aW9uIExvY2tlZD0iZmFsc2UiIFNlbWlIaWRkZW49InRy
dWUiIFVuaGlkZVdoZW5Vc2VkPSJ0cnVlIiBOYW1lPSJNZW50aW9uIi8+DQo8L3c6TGF0ZW50U3R5
bGVzPg0KPC94bWw+PCFbZW5kaWZdLS0+PHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMg
Ki8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6
MiA0IDUgMyA1IDQgNiAzIDIgNDsNCgltc28tZm9udC1hbHQ6IkNhbGlzdG8gTVQiOw0KCW1zby1m
b250LWNoYXJzZXQ6MTsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpyb21hbjsNCgltc28tZm9u
dC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3MDE0NSAxMTA3MzA1
NzI3IDAgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFu
b3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7DQoJbXNvLWZvbnQtYWx0OiJUaW1lcyBOZXcgUm9t
YW4iOw0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZhbWlseTpzd2lz
czsNCgltc28tZm9udC1waXRjaDp2YXJpYWJsZTsNCgltc28tZm9udC1zaWduYXR1cmU6LTUzNjg3
MDE0NSAxMDczNzg2MTExIDEgMCA0MTUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5Okxp
U3U7DQoJcGFub3NlLTE6MiAxIDUgOSA2IDEgMSAxIDEgMTsNCgltc28tZm9udC1hbHQ6U2ltU3Vu
Ow0KCW1zby1mb250LWNoYXJzZXQ6MTM0Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5Om1vZGVy
bjsNCgltc28tZm9udC1waXRjaDpmaXhlZDsNCgltc28tZm9udC1zaWduYXR1cmU6MSAxMzUxMzUy
MzIgMTYgMCAyNjIxNDQgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQg
WWFIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0Ow0KCW1zby1mb250LWFsdDo/
Pz8/Pz8/P8KoPz8/fD8/Pz8/Pz/Cpz8/Pz8/Pz8/Ow0KCW1zby1mb250LWNoYXJzZXQ6MTM0Ow0K
CW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxl
Ow0KCW1zby1mb250LXNpZ25hdHVyZTotMjE0NzQ4MzAwMSA2NzIwODcxMjIgMjIgMCAyNjIxNzUg
MDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OiJNaWNyb3NvZnQgWWFIZWkgVUkiOw0KCXBh
bm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MTM0Ow0KCW1z
by1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNzOw0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0K
CW1zby1mb250LXNpZ25hdHVyZTotMjE0NzQ4MzAwMSA2ODQ2NzAwMzQgMjIgMCAyNjIxNzUgMDt9
DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFzOw0KCXBhbm9zZS0xOjIgMTEgNiA5
IDIgMiA0IDMgMiA0Ow0KCW1zby1mb250LWNoYXJzZXQ6MDsNCgltc28tZ2VuZXJpYy1mb250LWZh
bWlseTptb2Rlcm47DQoJbXNvLWZvbnQtcGl0Y2g6Zml4ZWQ7DQoJbXNvLWZvbnQtc2lnbmF0dXJl
Oi01MjAwOTI5MjkgMTA3MzgwNjU5MSA5IDAgNDE1IDA7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseToiXEBNaWNyb3NvZnQgWWFIZWkiOw0KCXBhbm9zZS0xOjIgMTEgNSAzIDIgMiA0IDIgMiA0
Ow0KCW1zby1mb250LWNoYXJzZXQ6MTM0Ow0KCW1zby1nZW5lcmljLWZvbnQtZmFtaWx5OnN3aXNz
Ow0KCW1zby1mb250LXBpdGNoOnZhcmlhYmxlOw0KCW1zby1mb250LXNpZ25hdHVyZTotMjE0NzQ4
MzAwMSA2NzIwODcxMjIgMjIgMCAyNjIxNzUgMDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5
OiJcQE1pY3Jvc29mdCBZYUhlaSBVSSI7DQoJcGFub3NlLTE6MiAxMSA1IDMgMiAyIDQgMiAyIDQ7
DQoJbXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1pbHk6c3dpc3M7
DQoJbXNvLWZvbnQtcGl0Y2g6dmFyaWFibGU7DQoJbXNvLWZvbnQtc2lnbmF0dXJlOi0yMTQ3NDgz
MDAxIDY4NDY3MDAzNCAyMiAwIDI2MjE3NSAwO30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6
IlxATGlTdSI7DQoJbXNvLWZvbnQtY2hhcnNldDoxMzQ7DQoJbXNvLWdlbmVyaWMtZm9udC1mYW1p
bHk6bW9kZXJuOw0KCW1zby1mb250LXBpdGNoOmZpeGVkOw0KCW1zby1mb250LXNpZ25hdHVyZTox
IDEzNTEzNTIzMiAxNiAwIDI2MjE0NCAwO30NCi8qIFN0eWxlIERlZmluaXRpb25zICovDQpwLk1z
b05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21zby1zdHlsZS11bmhpZGU6
bm87DQoJbXNvLXN0eWxlLXFmb3JtYXQ6eWVzOw0KCW1zby1zdHlsZS1wYXJlbnQ6IiI7DQoJbWFy
Z2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJbXNvLXBhZ2luYXRpb246d2lkb3ct
b3JwaGFuOw0KCWZvbnQtc2l6ZToxMi4wcHQ7DQoJZm9udC1mYW1pbHk6IlRpbWVzIE5ldyBSb21h
biIsc2VyaWY7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6TGlTdTt9DQphOmxpbmssIHNwYW4u
TXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1ub3Nob3c6eWVzOw0KCW1zby1zdHlsZS1wcmlvcml0
eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11
bmRlcmxpbmU6c2luZ2xlO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0K
CXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6
cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJdGV4dC11bmRlcmxpbmU6c2lu
Z2xlO30NCnByZQ0KCXttc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjow
aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCW1zby1wYWdpbmF0aW9uOndpZG93LW9ycGhh
bjsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3VyaWVyIE5ldyI7DQoJbXNv
LWZhcmVhc3QtZm9udC1mYW1pbHk6TGlTdTt9DQpwLm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAs
IGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1uYW1lOm1zb25vcm1hbDsNCgltc28tc3R5bGUt
dW5oaWRlOm5vOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdodDowaW47
DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0KCW1zby1w
YWdpbmF0aW9uOndpZG93LW9ycGhhbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5
OiJUaW1lcyBOZXcgUm9tYW4iLHNlcmlmOw0KCW1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OkxpU3U7
fQ0Kc3Bhbi5hcHBsZS1jb252ZXJ0ZWQtc3BhY2UNCgl7bXNvLXN0eWxlLW5hbWU6YXBwbGUtY29u
dmVydGVkLXNwYWNlOw0KCW1zby1zdHlsZS11bmhpZGU6bm87fQ0Kc3Bhbi5zcGVsbGUNCgl7bXNv
LXN0eWxlLW5hbWU6c3BlbGxlOw0KCW1zby1zdHlsZS11bmhpZGU6bm87fQ0Kc3Bhbi5IVE1MUHJl
Zm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7
DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS11bmhpZGU6bm87DQoJbXNvLXN0eWxlLWxvY2tlZDp5ZXM7DQoJbXNvLXN0eWxlLWxpbms6
IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczsNCgltc28tYXNjaWkt
Zm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6TGlTdTsNCglt
c28taGFuc2ktZm9udC1mYW1pbHk6Q29uc29sYXM7DQoJbXNvLWJpZGktZm9udC1mYW1pbHk6Q29u
c29sYXM7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjINCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVw
bHk7DQoJbXNvLXN0eWxlLW5vc2hvdzp5ZXM7DQoJbXNvLXN0eWxlLXVuaGlkZTpubzsNCgltc28t
YW5zaS1mb250LXNpemU6MTEuMHB0Ow0KCW1zby1iaWRpLWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9u
dC1mYW1pbHk6Ik1pY3Jvc29mdCBZYUhlaSBVSSIsc2Fucy1zZXJpZjsNCgltc28tYXNjaWktZm9u
dC1mYW1pbHk6Ik1pY3Jvc29mdCBZYUhlaSBVSSI7DQoJbXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6
Ik1pY3Jvc29mdCBZYUhlaSBVSSI7DQoJY29sb3I6IzFGNDk3RDsNCglmb250LXdlaWdodDpub3Jt
YWw7DQoJZm9udC1zdHlsZTpub3JtYWw7DQoJdGV4dC1kZWNvcmF0aW9uOm5vbmU7DQoJdGV4dC11
bmRlcmxpbmU6bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZTsNCgl0ZXh0LWxpbmUtdGhyb3Vn
aDpub25lO30NCnNwYW4uU3BlbGxFDQoJe21zby1zdHlsZS1uYW1lOiIiOw0KCW1zby1zcGwtZTp5
ZXM7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNv
LWRlZmF1bHQtcHJvcHM6eWVzOw0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJbXNvLWFuc2ktZm9udC1z
aXplOjEwLjBwdDsNCgltc28tYmlkaS1mb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0
aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4w
aW47DQoJbXNvLWhlYWRlci1tYXJnaW46LjVpbjsNCgltc28tZm9vdGVyLW1hcmdpbjouNWluOw0K
CW1zby1wYXBlci1zb3VyY2U6MDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+PCEtLVtpZiBndGUgbXNvIDEwXT48c3R5bGU+LyogU3R5bGUgRGVm
aW5pdGlvbnMgKi8NCnRhYmxlLk1zb05vcm1hbFRhYmxlDQoJe21zby1zdHlsZS1uYW1lOiJUYWJs
ZSBOb3JtYWwiOw0KCW1zby10c3R5bGUtcm93YmFuZC1zaXplOjA7DQoJbXNvLXRzdHlsZS1jb2xi
YW5kLXNpemU6MDsNCgltc28tc3R5bGUtbm9zaG93OnllczsNCgltc28tc3R5bGUtcHJpb3JpdHk6
OTk7DQoJbXNvLXN0eWxlLXBhcmVudDoiIjsNCgltc28tcGFkZGluZy1hbHQ6MGluIDUuNHB0IDBp
biA1LjRwdDsNCgltc28tcGFyYS1tYXJnaW46MGluOw0KCW1zby1wYXJhLW1hcmdpbi1ib3R0b206
LjAwMDFwdDsNCgltc28tcGFnaW5hdGlvbjp3aWRvdy1vcnBoYW47DQoJZm9udC1zaXplOjEwLjBw
dDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIixzZXJpZjt9DQo8L3N0eWxlPjwhW2Vu
ZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0i
ZWRpdCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1z
byA5XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9
ImVkaXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8
L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSIgc3R5
bGU9InRhYi1pbnRlcnZhbDouNWluIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjttc28taGFuc2ktZm9u
dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPkhpIERl
YW4sPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJ
JnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBS
b21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDot
LjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVv
dDssc2Fucy1zZXJpZiI+Myk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDttc28t
ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDsiPiZuYnNwOyZu
YnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz
YW5zLXNlcmlmIj5XaXRoDQogdGhlIG1vZGVsIGRlZmluaXRpb24sIGV2ZW4gdGhlPHNwYW4gY2xh
c3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJTcGVs
bEUiPjxzcGFuIGNsYXNzPSJzcGVsbGUiPmFjbDwvc3Bhbj48L3NwYW4+LXR5cGUgaXMgY29uZmln
dXJlZCBhcyBFdGhlcm5ldCwgdGhlIG9wZXJhdG9yIHN0aWxsIGNhbiBjb25maWd1cmUgdGhlIG1h
dGNoZXMgb2YgYWNlIHVuZGVyIHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0iU3BlbGxFIj48c3BhbiBjbGFzcz0ic3BlbGxlIj5h
Y2w8L3NwYW4+PC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj5hcw0KIGlwdjQgb3IgaXB2NiwgcmlnaHQ/PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28t
ZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDou
NWluIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3
IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0
LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+Tm8sIGlmIEFDTCB0eXBl
IGlzDQo8c3BhbiBjbGFzcz0iU3BlbGxFIj5ldGhlcm5ldDwvc3Bhbj4sIHRoZW4gYWxsIEFDRXMg
YXJlIGV4cGVjdGVkIHRvIGJlIDxzcGFuIGNsYXNzPSJTcGVsbEUiPg0KZXRoZXJuZXQ8L3NwYW4+
LiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhl
aSBVSSZxdW90OyxzYW5zLXNlcmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO
ZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+W0Fkcmlhbl0gSSB1bmRlcnN0YW5kIHlvdXIg
cG9pbnQsIGJ1dCB0aGlzIGlzIG5vdCByZWZsZWN0ZWQgaW4gdGhlIG1vZGVsLCBpZiBhY2NvcmRp
bmcgdG8gdGhlIG1vZGVsLCB0aGUgb3BlcmF0b3INCiBzdGlsbCBjYW4gY29uZmlndXJlIHRoZSA8
c3BhbiBjbGFzcz0iU3BlbGxFIj5hY2w8L3NwYW4+LXR5cGUgYXMgRXRoZXJuZXQsIHdoaWxlIGNv
bmZpZ3VyZSB0aGUgYWNlIG9mIHRoZQ0KPHNwYW4gY2xhc3M9IlNwZWxsRSI+YWNsPC9zcGFuPiBh
cyBpcHY0LCBhbmQgdGhpcyBzaG91bGQgYmUgdmFsaWQgY29uZmlndXJhdGlvbi48L3NwYW4+PHNw
YW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90OyI+PGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6bGluZS1icmVhayI+DQo8IVtp
ZiAhc3VwcG9ydExpbmVCcmVha05ld0xpbmVdPjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFj
dGVyOmxpbmUtYnJlYWsiPg0KPCFbZW5kaWZdPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVp
biI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz
YW5zLXNlcmlmIj5pcyB0aGlzIHRoZSBtb2RlbCBkZXNpZ24gaW50ZW50aW9uPzwvc3Bhbj48c3Bh
biBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1
b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx
dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl
PSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPklm
DQo8c3BhbiBjbGFzcz0iU3BlbGxFIj5hY2w8L3NwYW4+LXR5cGUgaXMgb2Ygb25lIGZhbWlseSwg
dGhlbiBvbmx5IGFjZSB3aXRoIG1hdGNoIGNvbmRpdGlvbiBmcm9tIHRoYXQgZmFtaWx5IGFyZSBl
eHBlY3RlZCB0byBiZSBpbiB0aGUNCjxzcGFuIGNsYXNzPSJTcGVsbEUiPmFjbDwvc3Bhbj4uIElm
IHlvdSB3YW50IHRvIGNvbWJpbmUgdGhlbSwgcGxlYXNlIHVzZSBtaXhlZCB0eXBlLjxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5z
LXNlcmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7
Y29sb3I6IzFGNDk3RCI+W0Fkcmlhbl0gaWYgaXQ8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7bXNvLWFzY2lpLWZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZx
dW90Ozttc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVv
dDs7Y29sb3I6IzFGNDk3RCI+4oCZPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO21z
by1oYW5zaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFG
NDk3RCI+cw0KIG9ubHkgZXhwZWN0ZWQgdG8gYmUgdGhlIHNhbWUgYXMgdGhlIDxzcGFuIGNsYXNz
PSJTcGVsbEUiPmFjbDwvc3Bhbj4tdHlwZSwgYnV0IHdpdGhvdXQgdGhlIHJlc3RyaWN0aW9uIGlu
IHRoZSBtb2RlbCwgeW91IGNhbjwvc3Bhbj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtt
c28tYXNjaWktZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7O21zby1m
YXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90Oztjb2xvcjoj
MUY0OTdEIj7igJk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWhhbnNpLWZv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj50DQog
YXZvaWQgdGhlIG9wZXJhdG9yIGNvbmZpZ3VyYXRpb24gdG8gbWl4IHRoZSA8c3BhbiBjbGFzcz0i
U3BlbGxFIj5hY2w8L3NwYW4+LXR5cGUgYW5kIHRoZSBhY2UgbWF0Y2hlcy4gU28gbXkgdGhpbmtp
bmcgaXMgdGhhdCwgY2FuIHdlIGFkZCB0aGUgcmVzdHJpY3Rpb24gaW4gdGhlIG1vZGVsIGZvciB0
aGlzIGFzIGJlbG93IHRvIGJldHRlciByZWZsZWN0IHRoZSBtb2RlbCBkZXNpZ24gaW50ZW50aW9u
PzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZx
dW90OyxzYW5zLXNlcmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9t
YW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWhhbnNpLWZv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkm
cXVvdDssc2Fucy1zZXJpZjttc28taGFuc2ktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJv
bWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFt
aWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO21zby1oYW5zaS1m
b250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+Y29u
dGFpbmVyIG1hdGNoZXMgezxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jv
c29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVv
dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1z
cGFjZXJ1bjp5ZXMiPiZuYnNwOw0KPC9zcGFuPmRlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7
Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7bXNv
LWhhbnNpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0
OTdEIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8
L3NwYW4+JnF1b3Q7RGVmaW5pdGlvbnMgZm9yIG1hdGNoIGNyaXRlcmlhIGZvciB0aGlzIEFjY2Vz
cyBMaXN0PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVp
IFVJJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l
dyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5FbnRyeS4mcXVvdDs7PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7
bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3Nv
ZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjttc28taGFuc2ktZm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tc3Bh
Y2VydW46eWVzIj4mbmJzcDsNCjwvc3Bhbj5jb250YWluZXIgYWNlLWlwdjQgezxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNl
cmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29s
b3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOyZu
YnNwOw0KPC9zcGFuPndoZW4gJnF1b3Q7Li4vLi4vPHNwYW4gY2xhc3M9IlNwZWxsRSI+YWNsPC9z
cGFuPi10eXBlPSdpcHY0LWFjbCcmcXVvdDs7PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6
JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWhhbnNpLWZvbnQt
ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBz
dHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7DQo8L3NwYW4+ZGVzY3Jp
cHRpb24gJnF1b3Q7SVB2NCBBY2Nlc3MgTGlzdCBFbnRyeS4mcXVvdDs7PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7
bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
DQo8L3NwYW4+dXNlcyA8c3BhbiBjbGFzcz0iU3BlbGxFIj5wYWNrZXQtZmllbGRzOmFjbC1pcC1o
ZWFkZXItZmllbGRzPC9zcGFuPjs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtN
aWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjttc28taGFuc2ktZm9udC1mYW1pbHk6
JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJt
c28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj51c2VzIHBhY2tldC1m
aWVsZHM6YWNsLWlwdjQtaGVhZGVyLWZpZWxkczs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWls
eTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjttc28taGFuc2ktZm9u
dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFu
IHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsNCjwvc3Bhbj59PG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7
bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjoj
MUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7DQo8L3NwYW4+Y29u
dGFpbmVyIGFjZS1pcHY2IHs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNy
b3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjttc28taGFuc2ktZm9udC1mYW1pbHk6JnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28t
c3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsmbmJzcDsNCjwvc3Bhbj53aGVuICZxdW90Oy4uLy4u
LzxzcGFuIGNsYXNzPSJTcGVsbEUiPmFjbDwvc3Bhbj4tdHlwZT0naXB2Ni1hY2wnJnF1b3Q7Ozxv
OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90
OyxzYW5zLXNlcmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4m
cXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNw
OyZuYnNwOyZuYnNwOw0KPC9zcGFuPmRlc2NyaXB0aW9uICZxdW90O0lQdjYgQWNjZXNzIExpc3Qg
RW50cnkuJnF1b3Q7OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m
dCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1zcGFj
ZXJ1bjp5ZXMiPiZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPnVzZXMgPHNwYW4gY2xhc3M9IlNw
ZWxsRSI+cGFja2V0LWZpZWxkczphY2wtaXAtaGVhZGVyLWZpZWxkczwvc3Bhbj47PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMt
c2VyaWY7bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztj
b2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7DQo8L3NwYW4+dXNlcyBwYWNrZXQtZmllbGRzOmFjbC1pcHY2LWhlYWRlci1maWVsZHM7
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1
b3Q7LHNhbnMtc2VyaWY7bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21h
biZxdW90Oztjb2xvcjojMUY0OTdEIj48c3BhbiBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5i
c3A7DQo8L3NwYW4+fTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29m
dCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1zcGFj
ZXJ1bjp5ZXMiPiZuYnNwOw0KPC9zcGFuPmNvbnRhaW5lciBhY2UtZXRoIHs8bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJp
Zjttc28taGFuc2ktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9y
OiMxRjQ5N0QiPjxzcGFuIHN0eWxlPSJtc28tc3BhY2VydW46eWVzIj4mbmJzcDsmbmJzcDsmbmJz
cDsNCjwvc3Bhbj53aGVuICZxdW90Oy4uLy4uLzxzcGFuIGNsYXNzPSJTcGVsbEUiPmFjbDwvc3Bh
bj4tdHlwZT0nZXRoLTxzcGFuIGNsYXNzPSJTcGVsbEUiPmFjbDwvc3Bhbj4nJnF1b3Q7OzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90Oyxz
YW5zLXNlcmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVv
dDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZu
YnNwOyZuYnNwOw0KPC9zcGFuPmRlc2NyaXB0aW9uPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1p
bHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWhhbnNpLWZv
bnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj48c3Bh
biBzdHlsZT0ibXNvLXNwYWNlcnVuOnllcyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
DQo8L3NwYW4+JnF1b3Q7RXRoZXJuZXQgQWNjZXNzIExpc3QgZW50cnkuJnF1b3Q7OzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5z
LXNlcmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7
Y29sb3I6IzFGNDk3RCI+PHNwYW4gc3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOyZuYnNw
OyZuYnNwOw0KPC9zcGFuPnVzZXMgPHNwYW4gY2xhc3M9IlNwZWxsRSI+cGFja2V0LWZpZWxkczph
Y2wtZXRoLWhlYWRlci1maWVsZHM8L3NwYW4+OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5
OiZxdW90O01pY3Jvc29mdCBZYUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO21zby1oYW5zaS1mb250
LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PHNwYW4g
c3R5bGU9Im1zby1zcGFjZXJ1bjp5ZXMiPiZuYnNwOw0KPC9zcGFuPn08bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBw
dDtmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjtt
c28taGFuc2ktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMx
RjQ5N0QiPn0NCjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0
eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1p
bHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4g
c3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90
OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlh
SGVpIFVJJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWhhbnNpLWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz
IE5ldyBSb21hbiZxdW90Oztjb2xvcjojMUY0OTdEIj5UaGFua3M8bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdDtm
b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkgVUkmcXVvdDssc2Fucy1zZXJpZjttc28t
aGFuc2ktZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7O2NvbG9yOiMxRjQ5
N0QiPkFkcmlhbjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0O2ZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZ
YUhlaSBVSSZxdW90OyxzYW5zLXNlcmlmO21zby1oYW5zaS1mb250LWZhbWlseTomcXVvdDtUaW1l
cyBOZXcgUm9tYW4mcXVvdDs7Y29sb3I6IzFGNDk3RCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPGRpdj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0Ux
RTFFMSAxLjBwdDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEx
LjBwdDtmb250LWZhbWlseTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWY7bXNvLWZhcmVh
c3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5Gcm9tOjwvc3Bhbj48
L2I+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q2FsaWJy
aSZxdW90OyxzYW5zLXNlcmlmO21zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5l
dyBSb21hbiZxdW90OyI+DQogRGVhbiBCb2dkYW5vdmljIFttYWlsdG86aXZhbmRlYW5AZ21haWwu
Y29tXSA8YnI+DQo8Yj5TZW50OjwvYj4gTW9uZGF5LCBBdWd1c3QgMjIsIDIwMTYgNTozOSBQTTxi
cj4NCjxiPlRvOjwvYj4gQWRyaWFuIFBhbiAmbHQ7YWRyaWFuLnBhbkBlcmljc3Nvbi5jb20mZ3Q7
PGJyPg0KPGI+Q2M6PC9iPiBra291c2hpa0BjaXNjby5jb207IGx5aWh1YW5nMTZAZ21haWwuY29t
OyBkYmxhaXJAY2lzY28uY29tOyBuZXRtb2QgV0cgJmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+
DQo8Yj5TdWJqZWN0OjwvYj4gUmU6IFF1ZXN0aW9uIGFib3V0IGFjbC10eXBlIGluIGRyYWZ0LWll
dGYtbmV0bW9kLWFjbC1tb2RlbC0wODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPC9k
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDsiPigmIzQzO25ldG1vZCBtYWlsaW5nIGxpc3QpPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2lu
LWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1Rp
bWVzIE5ldyBSb21hbiZxdW90OyI+QWRyaWFuLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5
bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+
PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz
dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPlBsZWFzZSBzZWUgaW5s
aW5lPG86cD48L286cD48L3NwYW4+PC9wPg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt
Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5PbiBBdWcgMjIsIDIwMTYs
IGF0IDI6MjcgQU0sIEFkcmlhbiBQYW4gJmx0OzxhIGhyZWY9Im1haWx0bzphZHJpYW4ucGFuQGVy
aWNzc29uLmNvbSI+YWRyaWFuLnBhbkBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn
aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMt
c2VyaWYiPkRlYXIgYXV0aG9ycyw8L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQt
ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVv
dDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250
LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVm
dDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1
b3Q7LHNhbnMtc2VyaWYiPkkgaGF2ZSBzb21lIHF1ZXN0aW9ucyBhYm91dDxzcGFuIGNsYXNzPSJh
cHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0ic3BlbGxlIj5p
ZXRmPC9zcGFuPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48c3BhbiBjbGFzcz0ic3BlbGxlIj5hY2w8L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZl
cnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPm1vZGVsDQogYXMgYmVsb3csIHlvdXIgcmVwbHkgaXMg
YXBwcmVjaWF0ZWQuPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTom
cXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMt
c2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6
JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp
dj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
c3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWYiPjEpPC9z
cGFuPjxzcGFuIHN0eWxlPSJmb250LXNpemU6Ny4wcHQ7bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6
JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7Ij4mbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBw
bGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+SW4NCiB0aGUg
bW9kZWwgZGVmaW5pdGlvbjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNw
Ozwvc3Bhbj48c3BhbiBjbGFzcz0ic3BlbGxlIj5hY2w8L3NwYW4+LXR5cGUgaXMgb25lIGtleSBv
ZiB0aGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+PHNw
YW4gY2xhc3M9InNwZWxsZSI+YWNsPC9zcGFuPiwgYWxzbyBpbiB0aGUgZGVzY3JpcHRpb24gaXQg
c2F5cyB0aGF0IHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwv
c3Bhbj48c3BhbiBjbGFzcz0ic3BlbGxlIj5hY2w8L3NwYW4+LXR5cGUNCiBjb3VsZCBiZTxzcGFu
IGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0i
c3BlbGxlIj5ldGhlcm5ldDwvc3Bhbj4sIElQdjQsIElQdjYsIG1peGVkLCBpbiBjYXNlIHRoZTxz
cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFz
cz0ic3BlbGxlIj5hY2w8L3NwYW4+LXR5cGUgaXMgbWl4ZWQsIHdoYXQ8L3NwYW4+PHNwYW4gc3R5
bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+
4oCZPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkm
cXVvdDssc2Fucy1zZXJpZiI+cw0KIHRoZSBpZGVudGlmaWVyIHNob3VsZCBiZT88L3NwYW4+PHNw
YW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPGRpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW47dGV4dC1pbmRlbnQ6LS4yNWluIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2Vy
aWYiPlNob3VsZCBpdCBiZSBhdWdtZW50ZWQgYnkgZGlmZmVyZW50IHZlbmRvcj8gU2luY2UgSSBk
b248L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVz
IE5ldyBSb21hbiZxdW90OyI+4oCZPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv
dDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+dA0KIHNlZSB0aGUgZGVmaW5pdGlv
biBhYm91dCBpdC48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx
dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5
OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0
Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBO
ZXcgUm9tYW4mcXVvdDsiPkFzIG1peGVkIEFDTHMgYXJlIG5vdCBzdXBwb3J0ZWQgYnkgYWxsIHZl
bmRvcnMsIHRob3NlIGFyZSBub3QgcGFydCBvZiB0aGUgc3RhbmRhcmQgbW9kZWwuIElpdCBpcyB1
cCB0byB0aGUgdmVuZG9yIHRvIGF1Z21lbnQgdGhlIGFjZS10eXBlIGFuZCBzZWxlY3QgYW4gaWRl
bnRpZmllcg0KIHRvIHRoZWlyIGxpa2luZy4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh
biBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1
b3Q7Ij48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrIj4NCjwhW2lm
ICFzdXBwb3J0TGluZUJyZWFrTmV3TGluZV0+PGJyIHN0eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0
ZXI6bGluZS1icmVhayI+DQo8IVtlbmRpZl0+PG86cD48L286cD48L3NwYW4+PC9wPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2
Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz
dHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVudDotLjI1aW4iPjxzcGFuIHN0eWxlPSJm
b250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+Mik8L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDttc28tZmFyZWFzdC1mb250LWZhbWlseTom
cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDsiPiZuYnNwOyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBs
ZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmIj5Jbg0KIHRoZTxz
cGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNw
YW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZx
dW90OyI+4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQg
WWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+bWl4PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFz
dC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPuKAnTwvc3Bhbj48c3Bh
biBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48L3Nw
YW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz
YW5zLXNlcmlmIj5jYXNlLA0KIHRoZTxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2Ui
PiZuYnNwOzwvc3Bhbj48L3NwYW4+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5
OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+4oCcPC9zcGFuPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+bWF0Y2hlczwv
c3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3
IFJvbWFuJnF1b3Q7Ij7igJ08L3NwYW4+PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFj
ZSI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90Oyxz
YW5zLXNlcmlmIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom
cXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+dGhlDQogYWNlIGxpc3QgY2Fu
IGJlIHRoZSBjb21iaW5hdGlvbiBvZiBFdGhlcm5ldCxpcHY0LGlwdjYgZm9yIGRpZmZlcmVudCBh
Y2UsIHJpZ2h0Pzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1
b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4N
CjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl
PSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6
JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48
c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFu
JnF1b3Q7Ij5PciBhbm90aGVyIGNvbWJpbmF0aW9uLCBhZ2FpbiBkZXBlbmRzIG9uIHdoYXQgdGhh
dCBwYXJ0aWN1bGFyIHZlbmRvciBzdXBwb3J0cy48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJh
Y3RlcjpsaW5lLWJyZWFrIj4NCjwhW2lmICFzdXBwb3J0TGluZUJyZWFrTmV3TGluZV0+PGJyIHN0
eWxlPSJtc28tc3BlY2lhbC1jaGFyYWN0ZXI6bGluZS1icmVhayI+DQo8IVtlbmRpZl0+PG86cD48
L286cD48L3NwYW4+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFy
Z2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbjt0ZXh0LWluZGVu
dDotLjI1aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkm
cXVvdDssc2Fucy1zZXJpZiI+Myk8L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo3LjBwdDtt
c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDsiPiZuYnNw
OyZuYnNwOzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90
OyxzYW5zLXNlcmlmIj5XaXRoDQogdGhlIG1vZGVsIGRlZmluaXRpb24sIGV2ZW4gdGhlPHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJz
cGVsbGUiPmFjbDwvc3Bhbj4tdHlwZSBpcyBjb25maWd1cmVkIGFzIEV0aGVybmV0LCB0aGUgb3Bl
cmF0b3Igc3RpbGwgY2FuIGNvbmZpZ3VyZSB0aGUgbWF0Y2hlcyBvZiBhY2UgdW5kZXIgdGhlPHNw
YW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNz
PSJzcGVsbGUiPmFjbDwvc3Bhbj48c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4m
bmJzcDs8L3NwYW4+YXMNCiBpcHY0IG9yIGlwdjYsIHJpZ2h0Pzwvc3Bhbj48c3BhbiBzdHlsZT0i
bXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpw
PjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHls
ZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48
bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1m
YW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5ObywgaWYgQUNMIHR5cGUgaXMgZXRo
ZXJuZXQsIHRoZW4gYWxsIEFDRXMgYXJlIGV4cGVjdGVkIHRvIGJlIGV0aGVybmV0LiZuYnNwOzxi
ciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsiPg0KPCFbaWYgIXN1cHBv
cnRMaW5lQnJlYWtOZXdMaW5lXT48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5l
LWJyZWFrIj4NCjwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2
IHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt
YXJnaW4tbGVmdDouNWluO3RleHQtaW5kZW50Oi0uMjVpbiI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OiZxdW90O01pY3Jvc29mdCBZYUhlaSZxdW90OyxzYW5zLXNlcmlmIj5pcyB0aGlzIHRoZSBt
b2RlbCBkZXNpZ24gaW50ZW50aW9uPzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9u
dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3Qt
Zm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4t
bGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGlt
ZXMgTmV3IFJvbWFuJnF1b3Q7Ij5JZiBhY2wtdHlwZSBpcyBvZiBvbmUgZmFtaWx5LCB0aGVuIG9u
bHkgYWNlIHdpdGggbWF0Y2ggY29uZGl0aW9uIGZyb20gdGhhdCBmYW1pbHkgYXJlIGV4cGVjdGVk
IHRvIGJlIGluIHRoZSBhY2wuIElmIHlvdSB3YW50IHRvIGNvbWJpbmUgdGhlbSwgcGxlYXNlIHVz
ZSBtaXhlZA0KIHR5cGUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJt
c28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9u
dC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij5EZWFuPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxiciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxp
bmUtYnJlYWsiPg0KPCFbaWYgIXN1cHBvcnRMaW5lQnJlYWtOZXdMaW5lXT48YnIgc3R5bGU9Im1z
by1zcGVjaWFsLWNoYXJhY3RlcjpsaW5lLWJyZWFrIj4NCjwhW2VuZGlmXT48bzpwPjwvbzpwPjwv
c3Bhbj48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90
dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6c29saWQgI0NDQ0NDQyAxLjBw
dDtwYWRkaW5nOjguMHB0IDguMHB0IDguMHB0IDguMHB0O2JhY2tncm91bmQtcG9zaXRpb246aW5p
dGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+DQo8cHJlIHN0
eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRv
bTo3LjlwdDttYXJnaW4tbGVmdDouNWluO2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJy
ZWFrLWFsbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPm1vZHVsZTogPHNwYW4gY2xh
c3M9InNwZWxsZSI+aWV0Zjwvc3Bhbj4tYWNjZXNzLWNvbnRyb2wtbGlzdDwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln
aHQ6MGluO21hcmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6LjVpbjtiYWNrZ3JvdW5kOiNG
RkZERjU7d29yZC1icmVhazpicmVhay1hbGw7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGlu
aXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7ICYjNDM7LS08c3BhbiBjbGFzcz0ic3BlbGxlIj5y
dzwvc3Bhbj4gYWNjZXNzLWxpc3RzPC9zcGFuPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlIHN0eWxl
PSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo3
LjlwdDttYXJnaW4tbGVmdDouNWluO2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFr
LWFsbDtiYWNrZ3JvdW5kLXBvc2l0aW9uOmluaXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVh
dDppbml0aWFsIGluaXRpYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0Ij4mbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJiM0MzstLTxzcGFuIGNsYXNzPSJzcGVsbGUiPnJ3PC9z
cGFuPiA8c3BhbiBjbGFzcz0ic3BlbGxlIj5hY2w8L3NwYW4+KiBbPHNwYW4gY2xhc3M9InNwZWxs
ZSI+YWNsPC9zcGFuPi10eXBlIDxzcGFuIGNsYXNzPSJzcGVsbGUiPmFjbDwvc3Bhbj4tbmFtZV08
L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDow
aW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1sZWZ0Oi41aW47
YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JhY2tncm91bmQtcG9zaXRp
b246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tPHNwYW4gY2xhc3M9InNwZWxsZSI+cnc8L3NwYW4+
IDxzcGFuIGNsYXNzPSJzcGVsbGUiPmFjbDwvc3Bhbj4tbmFtZSZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBzdHJpbmc8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1t
YXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjcuOXB0O21h
cmdpbi1sZWZ0Oi41aW47YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2Jh
Y2tncm91bmQtcG9zaXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRp
YWwgaW5pdGlhbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tPHNwYW4gY2xhc3M9InNw
ZWxsZSI+cnc8L3NwYW4+IDxzcGFuIGNsYXNzPSJzcGVsbGUiPmFjbDwvc3Bhbj4tdHlwZSZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0ic3BlbGxlIj5hY2w8L3NwYW4+LXR5
cGU8L3NwYW4+PG86cD48L286cD48L3ByZT4NCjxwcmUgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs
dDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1sZWZ0Oi41
aW47YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsO2JhY2tncm91bmQtcG9z
aXRpb246aW5pdGlhbCBpbml0aWFsO2JhY2tncm91bmQtcmVwZWF0OmluaXRpYWwgaW5pdGlhbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmIzQzOy0tPHNwYW4gY2xhc3M9InNwZWxsZSI+cm88L3Nw
YW4+IDxzcGFuIGNsYXNzPSJzcGVsbGUiPmFjbDwvc3Bhbj4tPHNwYW4gY2xhc3M9InNwZWxsZSI+
b3Blcjwvc3Bhbj4tZGF0YTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206Ny45cHQ7
bWFyZ2luLWxlZnQ6LjVpbjtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7
YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5p
dGlhbCBpbml0aWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS08c3BhbiBjbGFzcz0i
c3BlbGxlIj5ydzwvc3Bhbj4gYWNjZXNzLWxpc3QtZW50cmllczwvc3Bhbj48bzpwPjwvbzpwPjwv
cHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGlu
O21hcmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6LjVpbjtiYWNrZ3JvdW5kOiNGRkZERjU7
d29yZC1icmVhazpicmVhay1hbGw7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7
YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS08c3BhbiBjbGFzcz0ic3BlbGxlIj5ydzwvc3Bhbj4g
YWNlKiBbcnVsZS1uYW1lXTwvc3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNv
LW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206Ny45cHQ7
bWFyZ2luLWxlZnQ6LjVpbjtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7
YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5p
dGlhbCBpbml0aWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7ICYjNDM7LS08c3BhbiBjbGFzcz0ic3BlbGxlIj5ydzwvc3Bhbj4gcnVs
ZS1uYW1lJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHN0cmluZzwv
c3Bhbj48bzpwPjwvbzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBp
bjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6LjVpbjti
YWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGw7YmFja2dyb3VuZC1wb3NpdGlv
bjppbml0aWFsIGluaXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICYj
NDM7LS08c3BhbiBjbGFzcz0ic3BlbGxlIj5ydzwvc3Bhbj4gbWF0Y2hlczwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZSBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmln
aHQ6MGluO21hcmdpbi1ib3R0b206Ny45cHQ7bWFyZ2luLWxlZnQ6LjVpbjtiYWNrZ3JvdW5kOiNG
RkZERjU7d29yZC1icmVhazpicmVhay1hbGw7YmFja2dyb3VuZC1wb3NpdGlvbjppbml0aWFsIGlu
aXRpYWw7YmFja2dyb3VuZC1yZXBlYXQ6aW5pdGlhbCBpbml0aWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjEwLjVwdCI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IHwmbmJzcDsgJiM0Mzst
LTxzcGFuIGNsYXNzPSJzcGVsbGUiPnJ3PC9zcGFuPiAoYWNlLXR5cGUpPzwvc3Bhbj48bzpwPjwv
bzpwPjwvcHJlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1h
cmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQg
WWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+Jm5ic3A7PC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFy
ZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+PC9vOnA+
PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOnNvbGlkICNDQ0NDQ0MgMS4w
cHQ7cGFkZGluZzo4LjBwdCA4LjBwdCA4LjBwdCA4LjBwdDtiYWNrZ3JvdW5kLXBvc2l0aW9uOmlu
aXRpYWwgaW5pdGlhbDtiYWNrZ3JvdW5kLXJlcGVhdDppbml0aWFsIGluaXRpYWwiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0
OjBpbjttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1sZWZ0Oi41aW47YmFja2dyb3VuZDojRkZG
REY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0
O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVk
LXNwYWNlIj4mbmJzcDs8L3NwYW4+bGVhZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3Bh
Y2UiPiZuYnNwOzwvc3Bhbj48c3BhbiBjbGFzcz0ic3BlbGxlIj5hY2w8L3NwYW4+LXR5cGUgezwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFy
Z2luLXRvcC1hbHQ6MGluO21hcmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo3LjlwdDttYXJn
aW4tbGVmdDouNWluO2JhY2tncm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8
c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5l
dyZxdW90OyI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7PHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPnR5cGU8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
PHNwYW4gY2xhc3M9InNwZWxsZSI+YWNsPC9zcGFuPi10eXBlOzwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6MGluO21h
cmdpbi1yaWdodDowaW47bWFyZ2luLWJvdHRvbTo3LjlwdDttYXJnaW4tbGVmdDouNWluO2JhY2tn
cm91bmQ6I0ZGRkRGNTt3b3JkLWJyZWFrOmJyZWFrLWFsbCI+DQo8c3BhbiBzdHlsZT0iZm9udC1z
aXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtDb3VyaWVyIE5ldyZxdW90OyI+Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7PHNwYW4g
Y2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9zcGFuPmRlc2NyaXB0aW9uPC9z
cGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn
aW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdp
bi1sZWZ0Oi41aW47YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxz
cGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3
JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8
c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+JnF1b3Q7VHlw
ZSBvZiBhY2Nlc3MgY29udHJvbCBsaXN0LiBJbmRpY2F0ZXMgdGhlIHByaW1hcnkgaW50ZW5kZWQ8
L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1h
cmdpbi10b3AtYWx0OjBpbjttYXJnaW4tcmlnaHQ6MGluO21hcmdpbi1ib3R0b206Ny45cHQ7bWFy
Z2luLWxlZnQ6LjVpbjtiYWNrZ3JvdW5kOiNGRkZERjU7d29yZC1icmVhazpicmVhay1hbGwiPg0K
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7Q291cmllciBO
ZXcmcXVvdDsiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OzxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj50eXBlIG9m
IG1hdGNoIGNyaXRlcmlhIChlLmcuPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+
Jm5ic3A7PC9zcGFuPjxzcGFuIGNsYXNzPSJzcGVsbGUiPmV0aGVybmV0PC9zcGFuPiwgSVB2NCwg
SVB2NiwgbWl4ZWQsPHNwYW4gY2xhc3M9ImFwcGxlLWNvbnZlcnRlZC1zcGFjZSI+Jm5ic3A7PC9z
cGFuPjxzcGFuIGNsYXNzPSJzcGVsbGUiPmV0Yzwvc3Bhbj4pPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFy
Z2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjcuOXB0O21hcmdpbi1sZWZ0Oi41aW47YmFja2dy
b3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWstYWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNp
emU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0NvdXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUt
Y29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+dXNlZCBpbiB0aGUgbGlzdCBpbnN0YW5jZS4m
cXVvdDs7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1zby1tYXJnaW4tdG9wLWFsdDowaW47bWFyZ2luLXJpZ2h0OjBpbjttYXJnaW4tYm90dG9tOjcu
OXB0O21hcmdpbi1sZWZ0Oi41aW47YmFja2dyb3VuZDojRkZGREY1O3dvcmQtYnJlYWs6YnJlYWst
YWxsIj4NCjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0Nv
dXJpZXIgTmV3JnF1b3Q7Ij4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDs8c3BhbiBjbGFzcz0iYXBwbGUtY29udmVydGVkLXNwYWNlIj4mbmJzcDs8L3NwYW4+
fTwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1
b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWYiPiZuYnNwOzwvc3Bhbj48c3BhbiBz
dHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7VGltZXMgTmV3IFJvbWFuJnF1b3Q7
Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxl
PSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxi
ciBzdHlsZT0ibXNvLXNwZWNpYWwtY2hhcmFjdGVyOmxpbmUtYnJlYWsiPg0KPCFbaWYgIXN1cHBv
cnRMaW5lQnJlYWtOZXdMaW5lXT48YnIgc3R5bGU9Im1zby1zcGVjaWFsLWNoYXJhY3RlcjpsaW5l
LWJyZWFrIj4NCjwhW2VuZGlmXT48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0
eWxlPSJmb250LWZhbWlseTomcXVvdDtNaWNyb3NvZnQgWWFIZWkmcXVvdDssc2Fucy1zZXJpZiI+
VGhhbmtzPC9zcGFuPjxzcGFuIHN0eWxlPSJtc28tZmFyZWFzdC1mb250LWZhbWlseTomcXVvdDtU
aW1lcyBOZXcgUm9tYW4mcXVvdDsiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7TWljcm9zb2Z0IFlhSGVpJnF1b3Q7LHNhbnMtc2VyaWYi
PkFkcmlhbjwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWZhcmVhc3QtZm9udC1mYW1pbHk6JnF1b3Q7
VGltZXMgTmV3IFJvbWFuJnF1b3Q7Ij48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rpdj4NCjwv
ZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0i
bWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWZvbnQtZmFtaWx5OiZx
dW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_7F859F89F9B4DD4DB902232F9E2DAC083873C9ADESGSCMB103erics_--


From nobody Mon Aug 22 08:59: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 5D0DC12D733 for ; Mon, 22 Aug 2016 08:59:43 -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 zN8M9nQznr6q for ; Mon, 22 Aug 2016 08:59:41 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8530912D66A for ; Mon, 22 Aug 2016 08:59:41 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B03D5926446; Mon, 22 Aug 2016 17:59:39 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9O9n4YG3vApS; Mon, 22 Aug 2016 17:59:39 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 8611F926452; Mon, 22 Aug 2016 17:59:39 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id f2kT0WFlTBvD; Mon, 22 Aug 2016 17:59:39 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 604A0926446; Mon, 22 Aug 2016 17:59:39 +0200 (CEST)
Message-ID: <57BB2169.9050100@transpacket.com>
Date: Mon, 22 Aug 2016 17:59:37 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Ladislav Lhotka , netmod@ietf.org
References:  <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>  <57BAF672.60308@transpacket.com> <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz>
In-Reply-To: <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 15:59:43 -0000

On 08/22/2016 03:36 PM, Ladislav Lhotka wrote:
>> This example is based on the bug I propose to be fixed. If you looked at the patch I propose in https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html sec. 7.1.6 of RFC 6020 is modified:
>>
>> ---
>> OLD:
>> 7.6.1.  The leaf's default value
>>
>>    The default value of a leaf is the value that the server uses if the
>>    leaf does not exist in the data tree.  The usage of the default value
>>    depends on the leaf's closest ancestor node in the schema tree that
>>    is not a non-presence container:
>>
>> NEW:
>> 7.6.1.  The leaf's default value
>>
>>    The default value of a leaf is the value that the server uses if the
>>    leaf does not exist in the data tree.  The usage of the default value
>>    depends on the leaf's closest ancestor node in the schema tree:
> This would effectively remove the distinction between presence and non-presence containers, and I am not in favour of doing so. In any case, this is not something to introduce in the AUTH48 stage.
The distinction in the context of the primary reason for introduction of 
the "presence" statement indicating explicit semantic meaning of the 
presence of a container is still there. However I do not see the value 
of distinction in terms of creation and deletion. And it is that 
distinction introducing the bulk of clarification texts. The now 
mandatory evaluation of all must statements in non-presence containers 
is going to introduce very high and unnecessary processing load. I gave 
an example with 96 interfaces switch with 20 non-presence containers in 
/interfaces/interface. How about top level SDN manager?
>
>> By introducing the Y41 "clarification" now they are conforming which is the only benefit at the cost of limited validation expression flexibility, higher validation workload, broken NACM and probably some other issues we are about to discover.
> I don't agree with this conclusion. NACM probably needs to be updated anyway.
Which of the 3 issues pointed in the conclusion you don't agree with and 
why {1. limited validation expression flexibility, 2. higher validation 
workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is 
predetermined from the fact of the reduced entropy attributed to a 
non-presence container - namely its existence now is determined by the 
existence of its parent (which reduces flexibility in a very certain way).
> I don't see it as a workaround and I don't think there is ANY limitation whatsoever due to this. The rules are now clear, which is a good thing.
>
> Lada
I have expressed my concerns. I did not find anything addressing the 3 
issues above on the list and I thought it was worth posting something in 
the context of the ongoing discussion. There may be different opinions 
of the significance of the issues but they do exist.

Vladimir


From nobody Mon Aug 22 09:10: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 28BC512D78D for ; Mon, 22 Aug 2016 09:10:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 DRMoyC5z0Px4 for ; Mon, 22 Aug 2016 09:10:18 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5F19212D784 for ; Mon, 22 Aug 2016 09:10:18 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 34660763; Mon, 22 Aug 2016 18:10:17 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id EcOAEe8djz_J; Mon, 22 Aug 2016 18:10:13 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Aug 2016 18:10:16 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87EE4200AB; Mon, 22 Aug 2016 18:10:16 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id i-rxIaLrMTQX; Mon, 22 Aug 2016 18:10:15 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AF9C7200A8; Mon, 22 Aug 2016 18:10:15 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2D8DF3C2C376; Mon, 22 Aug 2016 18:10:13 +0200 (CEST)
Date: Mon, 22 Aug 2016 18:10:12 +0200
From: Juergen Schoenwaelder 
To: Vladimir Vassilev 
Message-ID: <20160822161010.GA13668@elstar.local>
Mail-Followup-To: Vladimir Vassilev , Ladislav Lhotka , netmod@ietf.org
References: <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>  <57BAF672.60308@transpacket.com> <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz> <57BB2169.9050100@transpacket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57BB2169.9050100@transpacket.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
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, 22 Aug 2016 16:10:20 -0000

On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:

> Which of the 3 issues pointed in the conclusion you don't agree with and why
> {1. limited validation expression flexibility, 2. higher validation
> workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is
> predetermined from the fact of the reduced entropy attributed to a
> non-presence container - namely its existence now is determined by the
> existence of its parent (which reduces flexibility in a very certain way).

Can someone explain to me what exactly breaks NACM? An example would
help me.

/js (as contributor)

-- 
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 Aug 22 09:15: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 D2BF012D792 for ; Mon, 22 Aug 2016 09:15:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id agd4nXS7on0D for ; Mon, 22 Aug 2016 09:15:55 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB8B312D66A for ; Mon, 22 Aug 2016 09:15:54 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 0827A92639F; Mon, 22 Aug 2016 18:15:53 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZGbGTCZD987B; Mon, 22 Aug 2016 18:15:52 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id D27CC9263D3; Mon, 22 Aug 2016 18:15:52 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lM3BntxL6agO; Mon, 22 Aug 2016 18:15:52 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id B6ADD92639F; Mon, 22 Aug 2016 18:15:52 +0200 (CEST)
Message-ID: <57BB2536.7060702@transpacket.com>
Date: Mon, 22 Aug 2016 18:15:50 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Juergen Schoenwaelder ,  netmod@ietf.org
References: <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>  <57BAF672.60308@transpacket.com> <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz> <57BB2169.9050100@transpacket.com> <20160822161010.GA13668@elstar.local>
In-Reply-To: <20160822161010.GA13668@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 16:15:56 -0000

On 08/22/2016 06:10 PM, Juergen Schoenwaelder wrote:
> On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:
>
>> Which of the 3 issues pointed in the conclusion you don't agree with and why
>> {1. limited validation expression flexibility, 2. higher validation
>> workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is
>> predetermined from the fact of the reduced entropy attributed to a
>> non-presence container - namely its existence now is determined by the
>> existence of its parent (which reduces flexibility in a very certain way).
> Can someone explain to me what exactly breaks NACM? An example would
> help me.
>
> /js (as contributor)
>
"It is absolutely legal to configure "update" rights to /interfaces to a 
group of users reserving the "create" right to the superuser. How is 
this scenario handled by servers ignoring empty non-presence 
containers?" (this is excerpt from an earlier post on that thread)

If a non-presence container always exits in YANG 1.1 this usage example 
is not possible.


From nobody Mon Aug 22 09:32: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 68B9012D526 for ; Mon, 22 Aug 2016 09:32:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jQU-yyNbv-23 for ; Mon, 22 Aug 2016 09:32:17 -0700 (PDT)
Received: from mail-ua0-x22a.google.com (mail-ua0-x22a.google.com [IPv6:2607:f8b0:400c:c08::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 C19B812D124 for ; Mon, 22 Aug 2016 09:32:16 -0700 (PDT)
Received: by mail-ua0-x22a.google.com with SMTP id 97so198375603uav.3 for ; Mon, 22 Aug 2016 09:32:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=RNqpAF+RPoX3Z2Z+6jOEbvsqnH2U+03SWShCijlxOv4=; b=fwPa97Fwrsi9tBgoSdUmMtF+WklYjHyUZ442ZgX7sCofwnoc1IwCum1SESSwyYpqyH gH+KshKOGHQA9J8G0xTV8R2vfJW37x9ecRdmzEuebxDLCOwgxaIMJyAiaZdusV/7AbcE dzCIXIXUvMVsgc6jWN4Pj3IVRuE771b+PZrAszFJvD6NhOtn8A8xh1NOYHWOl8ZzQvrX v+zEEnl+LUrHWOFeqlo/O6//jt37d/Mkg/Dl72GW4kDTzpGryWqYfGmmHln4UuuXPkqE dV0Q7WwXAfxyPAbxX5siEZQQLcIvu+mCgXlz/JOzFoRU+tzQXqFwD3HG1p0XDtqxm/Xf 911Q==
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:from:date :message-id:subject:to:cc; bh=RNqpAF+RPoX3Z2Z+6jOEbvsqnH2U+03SWShCijlxOv4=; b=jH+o6HbEjA5k4RFqaL+DHRZqwaJoHYX+nFrmk6jENYRkZ8hirc4q49qsDL7pw6GyRF k7hcaaNYItPFOtZ83hcVkWhkNa8jV0oMJIrBiAcI09xDRk+GOMPLEAc6R6shPmzfU55q Cbvwt3ScrdNDK0WFqiTYAScJD7WGskIcL6GnXAHLg3Mb6ENUIunj+aq7duCpG180HloG 3Wv7/z3PoAKfbmZVgIah2gIXuIjqC/y/cPg2RJ9IVvbT107PYDbjf4jXEwzjdSRKZQHl zYKiGjstqc2bF+rMaN7Xcm3pV00O7BreFr14G37MZ2Ytkz5BMrFLLB0fY01IInSxlly1 t9AQ==
X-Gm-Message-State: AEkoouvuiebrGLC5EQYbI3XgtMP5LZUpFYfEFrLUBxF3FxlTnN0YjF3Kv9rwFDgjUR+QU1unuJ0R1DAuy8ugaw==
X-Received: by 10.31.192.2 with SMTP id q2mr5295879vkf.44.1471883535844; Mon, 22 Aug 2016 09:32:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.134 with HTTP; Mon, 22 Aug 2016 09:32:14 -0700 (PDT)
In-Reply-To: <57BB2536.7060702@transpacket.com>
References: <57AC713E.8080006@transpacket.com> <20160817.102821.2247775938129211118.mbj@tail-f.com> <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>  <57BAF672.60308@transpacket.com> <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz> <57BB2169.9050100@transpacket.com> <20160822161010.GA13668@elstar.local> <57BB2536.7060702@transpacket.com>
From: Andy Bierman 
Date: Mon, 22 Aug 2016 09:32:14 -0700
Message-ID: 
To: Vladimir Vassilev 
Content-Type: multipart/alternative; boundary=001a113bf06c4e2be7053aab975f
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 16:32:18 -0000

--001a113bf06c4e2be7053aab975f
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 22, 2016 at 9:15 AM, Vladimir Vassilev  wrote:

> On 08/22/2016 06:10 PM, Juergen Schoenwaelder wrote:
>
>> On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:
>>
>> Which of the 3 issues pointed in the conclusion you don't agree with and
>>> why
>>> {1. limited validation expression flexibility, 2. higher validation
>>> workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is
>>> predetermined from the fact of the reduced entropy attributed to a
>>> non-presence container - namely its existence now is determined by the
>>> existence of its parent (which reduces flexibility in a very certain
>>> way).
>>>
>> Can someone explain to me what exactly breaks NACM? An example would
>> help me.
>>
>> /js (as contributor)
>>
>> "It is absolutely legal to configure "update" rights to /interfaces to a
> group of users reserving the "create" right to the superuser. How is this
> scenario handled by servers ignoring empty non-presence containers?" (this
> is excerpt from an earlier post on that thread)
>
> If a non-presence container always exits in YANG 1.1 this usage example is
> not possible.
>
>
I have to agree that NACM does not have any special rules for NP containers.

I also find the concept of "has no semantics except to hold child nodes"
to be especially confusing.   The parent of all foo-things is in itself
semantic content,
especially when considering the NP-container used as the target of augments
or the target of a NACM rule.

IMO the only use-case for must-stmt in the container is to validate child
nodes,
so it is non-intuitive that must-stmt is always tested on NP-containers
without
any child nodes.  I think it can be made to work in the code, but it will
cause
customer astonishment.


Andy



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

--001a113bf06c4e2be7053aab975f
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Aug 22, 2016 at 9:15 AM, Vladimir Vassilev &l=
t;vladimir@tr=
anspacket.com> wrote:
On 08=
/22/2016 06:10 PM, Juergen Schoenwaelder wrote:



On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:





Which of the 3 issues pointed in the conclusion you don't agree with an=
d why

{1. limited validation expression flexibility, 2. higher validation

workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is

predetermined from the fact of the reduced entropy attributed to a

non-presence container - namely its existence now is determined by the

existence of its parent (which reduces flexibility in a very certain way).<=
br>


Can someone explain to me what exactly breaks NACM? An example would

help me.



/js (as contributor)





"It is absolutely legal to configure "update" rights to /int=
erfaces to a group of users reserving the "create" right to the s=
uperuser. How is this scenario handled by servers ignoring empty non-presen=
ce containers?" (this is excerpt from an earlier post on that thread)<=
br>


If a non-presence container always exits in YANG 1.1 this usage example is =
not possible.



I have to agree that NACM does not hav=
e any special rules for NP containers.

I also find=
 the concept of "has no semantics except to hold child nodes"
to be especially confusing. =C2=A0 The parent of all foo-things is i=
n itself semantic content,
especially when considering the NP-con=
tainer used as the target of augments
or the target of a NACM rul=
e.

IMO the only use-case for must-stmt in the cont=
ainer is to validate child nodes,
so it is non-intuitive that mus=
t-stmt is always tested on NP-containers without
any child nodes.=
=C2=A0 I think it can be made to work in the code, but it will cause
<=
div>customer astonishment.


Andy




_______________________________________________

netmod mailing list

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




--001a113bf06c4e2be7053aab975f--


From nobody Mon Aug 22 09:37: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 C985312D81E for ; Mon, 22 Aug 2016 09:37:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 gIPStswU22cj for ; Mon, 22 Aug 2016 09:37:55 -0700 (PDT)
Received: from atlas3.jacobs-university.de (atlas3.jacobs-university.de [212.201.44.18]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 23E4012D7D7 for ; Mon, 22 Aug 2016 09:37:24 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id E6B11A94; Mon, 22 Aug 2016 18:37:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 3KjvbaSVi4dZ; Mon, 22 Aug 2016 18:37:19 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Aug 2016 18:37:22 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10CF3200AC; Mon, 22 Aug 2016 18:37:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Zt2H0hGvZciA; Mon, 22 Aug 2016 18:37:21 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id DCCB8200B8; Mon, 22 Aug 2016 18:37:20 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id A8E2B3C2C5F0; Mon, 22 Aug 2016 18:37:19 +0200 (CEST)
Date: Mon, 22 Aug 2016 18:37:18 +0200
From: Juergen Schoenwaelder 
To: Vladimir Vassilev 
Message-ID: <20160822163714.GC13668@elstar.local>
Mail-Followup-To: Vladimir Vassilev , netmod@ietf.org
References: <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>  <57BAF672.60308@transpacket.com> <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz> <57BB2169.9050100@transpacket.com> <20160822161010.GA13668@elstar.local> <57BB2536.7060702@transpacket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57BB2536.7060702@transpacket.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
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, 22 Aug 2016 16:37:57 -0000

On Mon, Aug 22, 2016 at 06:15:50PM +0200, Vladimir Vassilev wrote:
> On 08/22/2016 06:10 PM, Juergen Schoenwaelder wrote:
> > On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:
> > 
> > > Which of the 3 issues pointed in the conclusion you don't agree with and why
> > > {1. limited validation expression flexibility, 2. higher validation
> > > workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is
> > > predetermined from the fact of the reduced entropy attributed to a
> > > non-presence container - namely its existence now is determined by the
> > > existence of its parent (which reduces flexibility in a very certain way).
> > Can someone explain to me what exactly breaks NACM? An example would
> > help me.
> > 
> > /js (as contributor)
> > 
> "It is absolutely legal to configure "update" rights to /interfaces to a
> group of users reserving the "create" right to the superuser. How is this
> scenario handled by servers ignoring empty non-presence containers?" (this
> is excerpt from an earlier post on that thread)
>
> If a non-presence container always exits in YANG 1.1 this usage example is
> not possible.

Should I read 'ignoring empty non-presence containers' as 'removing empty
non-presence containers (form the XML encoding)'?

Isn't the idea that non-presence container always exits in YANG 1.1
for the purpose of validation, that is in the XPATH context.

Back to your example, what is the client going to update in
/interfaces if /interfaces is empty? Or is the scenario that the group
of users have create and update rights within /interfaces but no
create right on /interfaces?  I am trying to understand what exactly
the situation is that you think causes problems.

/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 Aug 22 09:45:57 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 CCDC712D7AE for ; Mon, 22 Aug 2016 09:45:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 l7mieroT1FIN for ; Mon, 22 Aug 2016 09:45:45 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id DEA3A12D74D for ; Mon, 22 Aug 2016 09:45:44 -0700 (PDT)
Received: from localhost (h-85-226.a165.priv.bahnhof.se [94.254.85.226]) by mail.tail-f.com (Postfix) with ESMTPSA id EFB151AE00B6; Mon, 22 Aug 2016 18:45:43 +0200 (CEST)
Date: Mon, 22 Aug 2016 18:45:43 +0200 (CEST)
Message-Id: <20160822.184543.235535345519950294.mbj@tail-f.com>
To: vladimir@transpacket.com
From: Martin Bjorklund 
In-Reply-To: <57BB2169.9050100@transpacket.com>
References: <57BAF672.60308@transpacket.com> <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz> <57BB2169.9050100@transpacket.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] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 16:45:56 -0000

Vladimir Vassilev  wrote:
> On 08/22/2016 03:36 PM, Ladislav Lhotka wrote:
> >> This example is based on the bug I propose to be fixed. If you looked
> >> at the patch I propose in
> >> https://www.ietf.org/mail-archive/web/netconf/current/msg11637.html
> >> sec. 7.1.6 of RFC 6020 is modified:
> >>
> >> ---
> >> OLD:
> >> 7.6.1.  The leaf's default value
> >>
> >>    The default value of a leaf is the value that the server uses if the
> >>    leaf does not exist in the data tree.  The usage of the default value
> >>    depends on the leaf's closest ancestor node in the schema tree that
> >>    is not a non-presence container:
> >>
> >> NEW:
> >> 7.6.1.  The leaf's default value
> >>
> >>    The default value of a leaf is the value that the server uses if the
> >>    leaf does not exist in the data tree.  The usage of the default value
> >>    depends on the leaf's closest ancestor node in the schema tree:
> > This would effectively remove the distinction between presence and
> > non-presence containers, and I am not in favour of doing so. In any
> > case, this is not something to introduce in the AUTH48 stage.
> The distinction in the context of the primary reason for introduction
> of the "presence" statement indicating explicit semantic meaning of
> the presence of a container is still there. However I do not see the
> value of distinction in terms of creation and deletion. And it is that
> distinction introducing the bulk of clarification texts. The now
> mandatory evaluation of all must statements in non-presence containers
> is going to introduce very high and unnecessary processing load.

I disagree.  If the model needs to have some semantic validation
rules, the designer is going to put them in a place such that they are
evaluated when the need to be evaluated.



/martin


From nobody Mon Aug 22 09:49: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 85B3512D0A0 for ; Mon, 22 Aug 2016 09:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0X3P3vtc08n for ; Mon, 22 Aug 2016 09:49:07 -0700 (PDT)
Received: from mail-ua0-x22e.google.com (mail-ua0-x22e.google.com [IPv6:2607:f8b0:400c:c08::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 7B71212D630 for ; Mon, 22 Aug 2016 09:49:07 -0700 (PDT)
Received: by mail-ua0-x22e.google.com with SMTP id 74so199520326uau.0 for ; Mon, 22 Aug 2016 09:49:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=BituO0KHzjalDN5zDP4mbKIScORnGPpIuiqM+cFZ8GI=; b=UQNNlMhhUc23n/Cnsg3NN677e1F6gOVk5eN4Cuk6GDttZ34TtZgzER4q7SSwqIBqJN xymSUd+K6ZLPR64tU1uNctnHU/bR53hueeerjv7N8O3ydmhAHEpg0OXqvQwPZbAekV/S uRJtBUo1xK4Yj0pQY79HVvRXLT/vH9qIGxqBQFjB7Ai+M321tA1RyweZlWS88qSe/bKh LrH62RNEkKs6SSDoNyKGMQeT5EbxlCOW/mi6UgGKtgV4VYrzuZgjcZ5VrEisZx10dY7A ajr+kMo82GLbBVvprg8muMaBRa790ADU38Irqtmq082xTf+Hsd6PXzFyBmvGIbeHZwQ5 H+sg==
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:from:date :message-id:subject:to; bh=BituO0KHzjalDN5zDP4mbKIScORnGPpIuiqM+cFZ8GI=; b=iWWoEItP1970pSoE2hcuapDCh2qoazWAj1frXGemlTjNdOwgB1/PxHSTDQEBTRsTBH dTenmgxqViALUQ6DXxQBqPEHaQ5/8CUXa0mBpZ0lMBlyTnmWkAL6njOm5V6B0MRldgfl uwdKGQvH693jyEL0mVTVDpsxxO3asDAetEvaoqvxRk0BaSX9kkmiWRt7vgCGRindZUt/ RfJqjwvu3pURmjmpip4eUUkqUS6GHLNeiGnAUEQ27g19CMeRuyHdMt0dsCnEzrRW8jw2 fsMVCUnlAlARTOIvUqqX27e4okQxlJdeVzwN5nufI5pRFlq4dFwdBt8b6BUfeX/AocSB XgkQ==
X-Gm-Message-State: AEkoouuFlPvAddRTY3KBDD8fBirBDYxtZhgRlV2/SsZiMb7lYpPceVCHMmMgZRTNnMd7k6gfFVonQUhdcVFEzA==
X-Received: by 10.31.192.2 with SMTP id q2mr5337518vkf.44.1471884546536; Mon, 22 Aug 2016 09:49:06 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.134 with HTTP; Mon, 22 Aug 2016 09:49:05 -0700 (PDT)
In-Reply-To: <20160822163714.GC13668@elstar.local>
References: <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>  <57BAF672.60308@transpacket.com> <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz> <57BB2169.9050100@transpacket.com> <20160822161010.GA13668@elstar.local> <57BB2536.7060702@transpacket.com> <20160822163714.GC13668@elstar.local>
From: Andy Bierman 
Date: Mon, 22 Aug 2016 09:49:05 -0700
Message-ID: 
To: Juergen Schoenwaelder ,  Vladimir Vassilev , "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=001a113bf06c8c0181053aabd34d
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 16:49:09 -0000

--001a113bf06c8c0181053aabd34d
Content-Type: text/plain; charset=UTF-8

On Mon, Aug 22, 2016 at 9:37 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Mon, Aug 22, 2016 at 06:15:50PM +0200, Vladimir Vassilev wrote:
> > On 08/22/2016 06:10 PM, Juergen Schoenwaelder wrote:
> > > On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:
> > >
> > > > Which of the 3 issues pointed in the conclusion you don't agree with
> and why
> > > > {1. limited validation expression flexibility, 2. higher validation
> > > > workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is
> > > > predetermined from the fact of the reduced entropy attributed to a
> > > > non-presence container - namely its existence now is determined by
> the
> > > > existence of its parent (which reduces flexibility in a very certain
> way).
> > > Can someone explain to me what exactly breaks NACM? An example would
> > > help me.
> > >
> > > /js (as contributor)
> > >
> > "It is absolutely legal to configure "update" rights to /interfaces to a
> > group of users reserving the "create" right to the superuser. How is this
> > scenario handled by servers ignoring empty non-presence containers?"
> (this
> > is excerpt from an earlier post on that thread)
> >
> > If a non-presence container always exits in YANG 1.1 this usage example
> is
> > not possible.
>
> Should I read 'ignoring empty non-presence containers' as 'removing empty
> non-presence containers (form the XML encoding)'?
>
> Isn't the idea that non-presence container always exits in YANG 1.1
> for the purpose of validation, that is in the XPATH context.
>
>

This is an important point.
YANG 1.1 treats default nodes as if they always exist,
but this ifor conceptual XPath evaluation only.
The create and delete operations still fail on a node with a YANG default,
based on whether it actually exists in the implementation.
NP containers are no different than default nodes in this respect.


Back to your example, what is the client going to update in
> /interfaces if /interfaces is empty? Or is the scenario that the group
> of users have create and update rights within /interfaces but no
> create right on /interfaces?  I am trying to understand what exactly
> the situation is that you think causes problems.
>


In our NACM implementation there will be a check on node /interfaces.
The operation better be "none" if the user is not allowed to write to
that node.

Consider a file system where /home is an NP-container.
You don't give user 'foo' access to write to /home, just /home/foo.



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

--001a113bf06c8c0181053aabd34d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable




On Mon, Aug 22, 2016 at 9:37 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Aug 22, 2016 at 06:15:50PM +0200, Vladimir V=
assilev wrote:

> On 08/22/2016 06:10 PM, Juergen Schoenwaelder wrote:

> > On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote=
:

> >

> > > Which of the 3 issues pointed in the conclusion you don'=
t agree with and why

> > > {1. limited validation expression flexibility, 2. higher val=
idation

> > > workload, 3. broken NACM}? Difficult to not agree with 2. An=
d 1 is

> > > predetermined from the fact of the reduced entropy attribute=
d to a

> > > non-presence container - namely its existence now is determi=
ned by the

> > > existence of its parent (which reduces flexibility in a very=
 certain way).

> > Can someone explain to me what exactly breaks NACM? An example wo=
uld

> > help me.

> >

> > /js (as contributor)

> >

> "It is absolutely legal to configure "update" rights to=
 /interfaces to a

> group of users reserving the "create" right to the superuser=
. How is this

> scenario handled by servers ignoring empty non-presence containers?&qu=
ot; (this

> is excerpt from an earlier post on that thread)

>

> If a non-presence container always exits in YANG 1.1 this usage exampl=
e is

> not possible.



Should I read 'ignoring empty non-presence containers' as 'remo=
ving empty

non-presence containers (form the XML encoding)'?



Isn't the idea that non-presence container always exits in YANG 1.1

for the purpose of validation, that is in the XPATH context.




This is an important po=
int.
YANG 1.1 treats default nodes as if they always exist,
=

but this ifor conceptual XPath evaluation only.
The create a=
nd delete operations still fail on a node with a YANG default,
ba=
sed on whether it actually exists in the implementation.
NP conta=
iners are no different than default nodes in this respect.



Back to your example, what is the client going to update in

/interfaces if /interfaces is empty? Or is the scenario that the group

of users have create and update rights within /interfaces but no

create right on /interfaces?=C2=A0 I am trying to understand what exactly
the situation is that you think causes problems.

<=
/div>

In our NACM implementation there will be a check o=
n node /interfaces.
The operation better be "none" if t=
he user is not allowed to write to
that node.

Consider a file system where /home is an NP-container.
You =
don't give user 'foo' access to write to /home, just /home/foo.=






/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




--001a113bf06c8c0181053aabd34d--


From nobody Mon Aug 22 10:21: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 4EA8212D59A for ; Mon, 22 Aug 2016 10:21:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N3Ynv6yuPonM for ; Mon, 22 Aug 2016 10:21:11 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4CE9B12D0AB for ; Mon, 22 Aug 2016 10:21:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 06C15926456; Mon, 22 Aug 2016 19:21:09 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id NxgHyKL34_6M; Mon, 22 Aug 2016 19:21:08 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id CAFBF926455; Mon, 22 Aug 2016 19:21:08 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id i5L8DcRyHlqw; Mon, 22 Aug 2016 19:21:08 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id AB07D926449; Mon, 22 Aug 2016 19:21:08 +0200 (CEST)
Message-ID: <57BB3482.50800@transpacket.com>
Date: Mon, 22 Aug 2016 19:21:06 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Juergen Schoenwaelder ,  netmod@ietf.org
References: <20160817.111343.387561472405973484.mbj@tail-f.com> <08053DE7-EF6C-4A14-B926-79723F516405@gmail.com> <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>  <57BAF672.60308@transpacket.com> <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz> <57BB2169.9050100@transpacket.com> <20160822161010.GA13668@elstar.local> <57BB2536.7060702@transpacket.com> <20160822163714.GC13668@elstar.local>
In-Reply-To: <20160822163714.GC13668@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 17:21:13 -0000

On 08/22/2016 06:37 PM, Juergen Schoenwaelder wrote:
> On Mon, Aug 22, 2016 at 06:15:50PM +0200, Vladimir Vassilev wrote:
>> On 08/22/2016 06:10 PM, Juergen Schoenwaelder wrote:
>>> On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:
>>>
>>>> Which of the 3 issues pointed in the conclusion you don't agree with and why
>>>> {1. limited validation expression flexibility, 2. higher validation
>>>> workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is
>>>> predetermined from the fact of the reduced entropy attributed to a
>>>> non-presence container - namely its existence now is determined by the
>>>> existence of its parent (which reduces flexibility in a very certain way).
>>> Can someone explain to me what exactly breaks NACM? An example would
>>> help me.
>>>
>>> /js (as contributor)
>>>
>> "It is absolutely legal to configure "update" rights to /interfaces to a
>> group of users reserving the "create" right to the superuser. How is this
>> scenario handled by servers ignoring empty non-presence containers?" (this
>> is excerpt from an earlier post on that thread)
>>
>> If a non-presence container always exits in YANG 1.1 this usage example is
>> not possible.
> Should I read 'ignoring empty non-presence containers' as 'removing empty
> non-presence containers (form the XML encoding)'?
Yes the original post targeted the text: "If a container does not have a 
"presence" statement and the last
    child node is deleted, the NETCONF server MAY delete the container."

There is nothing indicating it is concerning only the XML encoding which 
I believe can be fixed with AUTH48 modification if we agree this is the 
intention.
>
> Isn't the idea that non-presence container always exits in YANG 1.1
> for the purpose of validation, that is in the XPATH context.
You have a point. The YANG 1.1 text addresses only the Xpath context:

     "If a node that exists in the accessible tree has a non-presence
     container as a child, then the non-presence container also exists in
     the tree. ".

However now we have introduced a separation between a data tree and 
Xpath context tree which only serves the case where data tree 
non-presence containers are removed from the data tree automatically 
(and not only from the XML encoding as assumed above). Or do you see any 
other justification? It is this logic that creates the confusion and the 
impression YANG 1.1 advocates the NACM unfriendly case of non-presence 
containers being auto deleted from the data tree.
>
> Back to your example, what is the client going to update in
> /interfaces if /interfaces is empty? Or is the scenario that the group
> of users have create and update rights within /interfaces but no
> create right on /interfaces?  I am trying to understand what exactly
> the situation is that you think causes problems.
>
> /js
Here I might experience revelation I always assumed update on a 
container means you can create children in it but you can not create it 
if it does not exist already if you only have update rights but no 
create rights. There is no text in NACM RFC 6536 detailing what updating 
container means. Are you saying one can only replace values of leafs 
that already exist?

Vladimir


From nobody Mon Aug 22 10:36: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 5BA6D12D5AD for ; Mon, 22 Aug 2016 10:36:01 -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 dacrfVfzvh_h for ; Mon, 22 Aug 2016 10:36:00 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5DF5B12D169 for ; Mon, 22 Aug 2016 10:36:00 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id EDFFA926457; Mon, 22 Aug 2016 19:35:58 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id m6if77Hr5YKS; Mon, 22 Aug 2016 19:35:58 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id C863992645B; Mon, 22 Aug 2016 19:35:58 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id SWFXiOe_Traf; Mon, 22 Aug 2016 19:35:58 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id A71FD926457; Mon, 22 Aug 2016 19:35:58 +0200 (CEST)
Message-ID: <57BB37FC.5000202@transpacket.com>
Date: Mon, 22 Aug 2016 19:35:56 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Martin Bjorklund , netmod@ietf.org
References: <57BAF672.60308@transpacket.com>	<3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz>	<57BB2169.9050100@transpacket.com> <20160822.184543.235535345519950294.mbj@tail-f.com>
In-Reply-To: <20160822.184543.235535345519950294.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 17:36:01 -0000

On 08/22/2016 06:45 PM, Martin Bjorklund wrote:
> I disagree.  If the model needs to have some semantic validation
> rules, the designer is going to put them in a place such that they are
> evaluated when the need to be evaluated.
So designers augmenting /interfaces/interface with non-presence 
container with child leaves should just pick one of the leaves in YANG 
1.1 and put the must statements there instead of the parent container. 
Yes this might work. There is no problem adding extra "../" in the Xpath 
expressions. But what is the justification of all that except the "If a 
container does not have a "presence" statement and the last child node 
is deleted, the NETCONF server MAY delete the container." text?


From nobody Mon Aug 22 11:12: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 6680C12B02F for ; Mon, 22 Aug 2016 11:12:37 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 QlzgT3Q5klLG for ; Mon, 22 Aug 2016 11:12: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 61B7A12D097 for ; Mon, 22 Aug 2016 11:12: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 34C45AC2; Mon, 22 Aug 2016 20:12:34 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id A2lLepWLOJ_6; Mon, 22 Aug 2016 20:12:29 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 22 Aug 2016 20:12:32 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id CD3AC200AC; Mon, 22 Aug 2016 20:12:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 3zIn415tdapM; Mon, 22 Aug 2016 20:12:31 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 856EA200AB; Mon, 22 Aug 2016 20:12:31 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 452C93C2CA70; Mon, 22 Aug 2016 20:12:29 +0200 (CEST)
Date: Mon, 22 Aug 2016 20:12:27 +0200
From: Juergen Schoenwaelder 
To: Vladimir Vassilev 
Message-ID: <20160822181224.GA13945@elstar.local>
Mail-Followup-To: Vladimir Vassilev , netmod@ietf.org
References: <20160820082922.GB9108@elstar.local> <57B890F2.9070605@transpacket.com>  <57BAF672.60308@transpacket.com> <3E4546FA-287B-4B6E-A335-74067A6AB3A5@nic.cz> <57BB2169.9050100@transpacket.com> <20160822161010.GA13668@elstar.local> <57BB2536.7060702@transpacket.com> <20160822163714.GC13668@elstar.local> <57BB3482.50800@transpacket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57BB3482.50800@transpacket.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
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, 22 Aug 2016 18:12:37 -0000

On Mon, Aug 22, 2016 at 07:21:06PM +0200, Vladimir Vassilev wrote:
> On 08/22/2016 06:37 PM, Juergen Schoenwaelder wrote:
> > On Mon, Aug 22, 2016 at 06:15:50PM +0200, Vladimir Vassilev wrote:
> > > On 08/22/2016 06:10 PM, Juergen Schoenwaelder wrote:
> > > > On Mon, Aug 22, 2016 at 05:59:37PM +0200, Vladimir Vassilev wrote:
> > > > 
> > > > > Which of the 3 issues pointed in the conclusion you don't agree with and why
> > > > > {1. limited validation expression flexibility, 2. higher validation
> > > > > workload, 3. broken NACM}? Difficult to not agree with 2. And 1 is
> > > > > predetermined from the fact of the reduced entropy attributed to a
> > > > > non-presence container - namely its existence now is determined by the
> > > > > existence of its parent (which reduces flexibility in a very certain way).
> > > > Can someone explain to me what exactly breaks NACM? An example would
> > > > help me.
> > > > 
> > > > /js (as contributor)
> > > > 
> > > "It is absolutely legal to configure "update" rights to /interfaces to a
> > > group of users reserving the "create" right to the superuser. How is this
> > > scenario handled by servers ignoring empty non-presence containers?" (this
> > > is excerpt from an earlier post on that thread)
> > > 
> > > If a non-presence container always exits in YANG 1.1 this usage example is
> > > not possible.
> > Should I read 'ignoring empty non-presence containers' as 'removing empty
> > non-presence containers (form the XML encoding)'?
> Yes the original post targeted the text: "If a container does not have a
> "presence" statement and the last
>    child node is deleted, the NETCONF server MAY delete the container."
> 
> There is nothing indicating it is concerning only the XML encoding which I
> believe can be fixed with AUTH48 modification if we agree this is the
> intention.
> > 
> > Isn't the idea that non-presence container always exits in YANG 1.1
> > for the purpose of validation, that is in the XPATH context.
> You have a point. The YANG 1.1 text addresses only the Xpath context:
> 
>     "If a node that exists in the accessible tree has a non-presence
>     container as a child, then the non-presence container also exists in
>     the tree. ".
> 
> However now we have introduced a separation between a data tree and Xpath
> context tree which only serves the case where data tree non-presence
> containers are removed from the data tree automatically (and not only from
> the XML encoding as assumed above). Or do you see any other justification?
> It is this logic that creates the confusion and the impression YANG 1.1
> advocates the NACM unfriendly case of non-presence containers being auto
> deleted from the data tree.

What we need is a clear problem statement people can agree on and a
clear proposal how to resolve the problem that people can also agree
on. I think we are not even close to a clear problem statement since
logic often appears circular.

> > Back to your example, what is the client going to update in
> > /interfaces if /interfaces is empty? Or is the scenario that the group
> > of users have create and update rights within /interfaces but no
> > create right on /interfaces?  I am trying to understand what exactly
> > the situation is that you think causes problems.
> > 
> > /js
> Here I might experience revelation I always assumed update on a container
> means you can create children in it but you can not create it if it does not
> exist already if you only have update rights but no create rights. There is
> no text in NACM RFC 6536 detailing what updating container means. Are you
> saying one can only replace values of leafs that already exist?

RFC 6536 says:

   o  Create: allows the client to add a new data node instance to a
      datastore.

   o  Update: allows the client to update an existing data node instance
      in a datastore.

For me, this means that create and update are different operations and
in the context of a container, update does not really make any sense
since a container node does not have a value that can be updated.

/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 Aug 22 11:35: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 D252612D732 for ; Mon, 22 Aug 2016 11:35:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] 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 ogcCPSiTDqe0 for ; Mon, 22 Aug 2016 11:35:31 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 89A2312B02F for ; Mon, 22 Aug 2016 11:27:17 -0700 (PDT)
Received: from localhost (h-85-226.a165.priv.bahnhof.se [94.254.85.226]) by mail.tail-f.com (Postfix) with ESMTPSA id 8A1D21AE00B6; Mon, 22 Aug 2016 20:27:15 +0200 (CEST)
Date: Mon, 22 Aug 2016 20:27:15 +0200 (CEST)
Message-Id: <20160822.202715.1748199491210115278.mbj@tail-f.com>
To: vladimir@transpacket.com
From: Martin Bjorklund 
In-Reply-To: <57BB37FC.5000202@transpacket.com>
References: <57BB2169.9050100@transpacket.com> <20160822.184543.235535345519950294.mbj@tail-f.com> <57BB37FC.5000202@transpacket.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] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 18:35:32 -0000

Vladimir Vassilev  wrote:
> On 08/22/2016 06:45 PM, Martin Bjorklund wrote:
> > I disagree.  If the model needs to have some semantic validation
> > rules, the designer is going to put them in a place such that they are
> > evaluated when the need to be evaluated.
> So designers augmenting /interfaces/interface with non-presence
> container with child leaves should just pick one of the leaves in YANG
> 1.1 and put the must statements there instead of the parent
> container.

Sorry I can't parse this.  What is "leaves in YANG 1.1"?

My point is that must expressions don't just exist w/o any reason for
the sake of theoretical arguments.  If there is a YANG 1.1 model with
a must expression in an NP-container, then there is probably a reason
for it - the designer wants it to be evaluated if its parent exist.
If we change the rules for when must expressions are evaluated, the
module designer will have to figure out some other way to add these
must expressions, and the performance will be the same.  So your
argument that many must expressions can lead to performance issues is
not really a problem in itself.


/martin

> Yes this might work. There is no problem adding extra "../"
> in the Xpath expressions. But what is the justification of all that
> except the "If a container does not have a "presence" statement and
> the last child node is deleted, the NETCONF server MAY delete the
> container." text?
> 


From nobody Mon Aug 22 12:41: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 11F2512D7D1 for ; Mon, 22 Aug 2016 12:41:15 -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 ePn9roSc8WMK for ; Mon, 22 Aug 2016 12:41:13 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 201FB12D1E0 for ; Mon, 22 Aug 2016 12:41:13 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 01DE7926472; Mon, 22 Aug 2016 21:41:11 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id DQ4yESh65d14; Mon, 22 Aug 2016 21:41:10 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id CDCEC926487; Mon, 22 Aug 2016 21:41:10 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id lAYB0wDUScTM; Mon, 22 Aug 2016 21:41:10 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id A6224926472; Mon, 22 Aug 2016 21:41:10 +0200 (CEST)
Message-ID: <57BB5554.2000400@transpacket.com>
Date: Mon, 22 Aug 2016 21:41:08 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Martin Bjorklund , netmod@ietf.org
References: <57BB2169.9050100@transpacket.com>	<20160822.184543.235535345519950294.mbj@tail-f.com>	<57BB37FC.5000202@transpacket.com> <20160822.202715.1748199491210115278.mbj@tail-f.com>
In-Reply-To: <20160822.202715.1748199491210115278.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 19:41:15 -0000

On 08/22/2016 08:27 PM, Martin Bjorklund wrote:
> Vladimir Vassilev  wrote:
>> On 08/22/2016 06:45 PM, Martin Bjorklund wrote:
>>> I disagree.  If the model needs to have some semantic validation
>>> rules, the designer is going to put them in a place such that they are
>>> evaluated when the need to be evaluated.
>> So designers augmenting /interfaces/interface with non-presence
>> container with child leaves should just pick one of the leaves in YANG
>> 1.1 and put the must statements there instead of the parent
>> container.
> Sorry I can't parse this.  What is "leaves in YANG 1.1"?
Well for example the designer wants to add container with multiple leaf 
children (leaves) to /interfaces/interface. Assume there is only 1 of 
the 96 interfaces on a switch that can have inet address for the purpose 
of managing the device:

augment "/if:interfaces/if:interface" {
     container inet {
         must "../name = 'me0'" {
             description
                  "The inet container is only valid for the management 
('me0') interface.";
         }
         leaf address {
             type inet:ip-prefix;
         }
     }
}

So in this example the must expression will be evaluated not only for 
interfaces the user attempts to create 
/interfaces/interface/inet/address but for all those he does not attempt 
to create it. This is not the case in YANG 1.0 and this is example how 
processing of validation expressions increases in YANG 1.1

In this case the designer can copy the must expression to the address 
leaf and it will be evaluated only when the user attempts to create that 
leaf ... however when it is not a single leaf in the container the 
workaround can get trickier.

>
> My point is that must expressions don't just exist w/o any reason for
> the sake of theoretical arguments.  If there is a YANG 1.1 model with
> a must expression in an NP-container, then there is probably a reason
> for it - the designer wants it to be evaluated if its parent exist.
Well this would be the case in YANG 1.1. In YANG 1.0 the designer wants 
it to be evaluated if the non-presence container itself exists not its 
parent. Now this changes because of the "clarification" from Y41.
> If we change the rules for when must expressions are evaluated, the
> module designer will have to figure out some other way to add these
> must expressions, and the performance will be the same.  So your
> argument that many must expressions can lead to performance issues is
> not really a problem in itself.
We are changing the rules from YANG 1.0. Auto evaluation of all 
non-presence containers must statements is now mandatory when their 
parent container exists. I still don't see how there is no problem with 
the increased must statement processing and believe there is 
misunderstanding somewhere.

Vladimir
>
>
> /martin
>
>> Yes this might work. There is no problem adding extra "../"
>> in the Xpath expressions. But what is the justification of all that
>> except the "If a container does not have a "presence" statement and
>> the last child node is deleted, the NETCONF server MAY delete the
>> container." text?
>>


From nobody Mon Aug 22 15:08: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 8F02A12D144 for ; Mon, 22 Aug 2016 15:08:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.548, 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 Y6mex1PYhyBD for ; Mon, 22 Aug 2016 15:08:21 -0700 (PDT)
Received: from mail-send.aviatnet.com (mail-send.aviatnet.com [192.147.115.52]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2787A12D1A5 for ; Mon, 22 Aug 2016 15:08:21 -0700 (PDT)
From: Alex Campbell 
To: Vladimir Vassilev 
Thread-Topic: [netmod] [Netconf] What should a server response be? - depending on NP-containers
Thread-Index: AQHR+ocq89Xw8H9xFUu/056uGxZN96BR+jEAgACT5QCAAsqiAIAAELgAgAALVICAACfjgIAADOKAgAAOBwCAAA5XgIAAFKQA//+y81Q=
Date: Mon, 22 Aug 2016 22:08:19 +0000
Message-ID: <1471903699434.77842@Aviatnet.com>
References: <57BB2169.9050100@transpacket.com> <20160822.184543.235535345519950294.mbj@tail-f.com> <57BB37FC.5000202@transpacket.com> <20160822.202715.1748199491210115278.mbj@tail-f.com>, <57BB5554.2000400@transpacket.com>
In-Reply-To: <57BB5554.2000400@transpacket.com>
Accept-Language: en-NZ, en-US
Content-Language: en-NZ
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.15.6.10]
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 22 Aug 2016 22:08:22 -0000

The intention in this case is obviously to evaluate the 'must' statement if=
=0A=
the container contains any values; what would break if we said that=0A=
=0A=
   A non-presence container exists in the data tree if and only if it has=
=0A=
   any children which exist in the data tree.=0A=
=0A=
thus disallowing the existence of empty NP-containers in the data tree?=0A=
=0A=
________________________________________=0A=
From: netmod  on behalf of Vladimir Vassilev =0A=
Sent: Tuesday, 23 August 2016 7:41 a.m.=0A=
To: Martin Bjorklund; netmod@ietf.org=0A=
Subject: Re: [netmod] [Netconf] What should a server response be? - dependi=
ng on NP-containers=0A=
=0A=
On 08/22/2016 08:27 PM, Martin Bjorklund wrote:=0A=
> Vladimir Vassilev  wrote:=0A=
>> On 08/22/2016 06:45 PM, Martin Bjorklund wrote:=0A=
>>> I disagree.  If the model needs to have some semantic validation=0A=
>>> rules, the designer is going to put them in a place such that they are=
=0A=
>>> evaluated when the need to be evaluated.=0A=
>> So designers augmenting /interfaces/interface with non-presence=0A=
>> container with child leaves should just pick one of the leaves in YANG=
=0A=
>> 1.1 and put the must statements there instead of the parent=0A=
>> container.=0A=
> Sorry I can't parse this.  What is "leaves in YANG 1.1"?=0A=
Well for example the designer wants to add container with multiple leaf=0A=
children (leaves) to /interfaces/interface. Assume there is only 1 of=0A=
the 96 interfaces on a switch that can have inet address for the purpose=0A=
of managing the device:=0A=
=0A=
augment "/if:interfaces/if:interface" {=0A=
     container inet {=0A=
         must "../name =3D 'me0'" {=0A=
             description=0A=
                  "The inet container is only valid for the management=0A=
('me0') interface.";=0A=
         }=0A=
         leaf address {=0A=
             type inet:ip-prefix;=0A=
         }=0A=
     }=0A=
}=0A=
=0A=
So in this example the must expression will be evaluated not only for=0A=
interfaces the user attempts to create=0A=
/interfaces/interface/inet/address but for all those he does not attempt=0A=
to create it. This is not the case in YANG 1.0 and this is example how=0A=
processing of validation expressions increases in YANG 1.1=0A=
=0A=
In this case the designer can copy the must expression to the address=0A=
leaf and it will be evaluated only when the user attempts to create that=0A=
leaf ... however when it is not a single leaf in the container the=0A=
workaround can get trickier.=0A=
=0A=
>=0A=
> My point is that must expressions don't just exist w/o any reason for=0A=
> the sake of theoretical arguments.  If there is a YANG 1.1 model with=0A=
> a must expression in an NP-container, then there is probably a reason=0A=
> for it - the designer wants it to be evaluated if its parent exist.=0A=
Well this would be the case in YANG 1.1. In YANG 1.0 the designer wants=0A=
it to be evaluated if the non-presence container itself exists not its=0A=
parent. Now this changes because of the "clarification" from Y41.=0A=
> If we change the rules for when must expressions are evaluated, the=0A=
> module designer will have to figure out some other way to add these=0A=
> must expressions, and the performance will be the same.  So your=0A=
> argument that many must expressions can lead to performance issues is=0A=
> not really a problem in itself.=0A=
We are changing the rules from YANG 1.0. Auto evaluation of all=0A=
non-presence containers must statements is now mandatory when their=0A=
parent container exists. I still don't see how there is no problem with=0A=
the increased must statement processing and believe there is=0A=
misunderstanding somewhere.=0A=
=0A=
Vladimir=0A=
>=0A=
>=0A=
> /martin=0A=
>=0A=
>> Yes this might work. There is no problem adding extra "../"=0A=
>> in the Xpath expressions. But what is the justification of all that=0A=
>> except the "If a container does not have a "presence" statement and=0A=
>> the last child node is deleted, the NETCONF server MAY delete the=0A=
>> container." text?=0A=
>>=0A=
=0A=
_______________________________________________=0A=
netmod mailing list=0A=
netmod@ietf.org=0A=
https://www.ietf.org/mailman/listinfo/netmod=0A=


From nobody Mon Aug 22 23:41: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 CCC7312B04D for ; Mon, 22 Aug 2016 23:41:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RemZuEKd6NVS for ; Mon, 22 Aug 2016 23:41:37 -0700 (PDT)
Received: from mail-ua0-x235.google.com (mail-ua0-x235.google.com [IPv6:2607:f8b0:400c:c08::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 6EAF612B006 for ; Mon, 22 Aug 2016 23:41:37 -0700 (PDT)
Received: by mail-ua0-x235.google.com with SMTP id 97so229039075uav.3 for ; Mon, 22 Aug 2016 23:41:37 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;  h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=/59NUl0k2ojOckf4uiFD8ckfAiWr88TpxEf7ZsgUu1A=; b=h1tcje7d5KXVpDZPtiR4uCPDaitWGRx5vhq2CFNzRaXtmQBuDTdIIOfa97AqQfa7hu mkqv/a7iZFRKuHLFHNiWSDSSLYn/Cu6WAZrbqK4vhrwt9XcK0FDCU7kb7TP1OF/yoaG5 Yeo7UhSWwtPFSmU4H4Tc6M/fJfxzWWJvZgOdTtCnzpkg11uIuIiRcuqPYhpnS9XWEyVg Q3iG5ivZjh7ZNxnBxaSXjE+lK5hrWXK1LyPbITF+Ynb8YVW5G3OXrloXq3jBLNswGvH8 FeP2XzaL/uoY6g+5WCHjPV5x9PSSaNCRMnxaPl6J4LevwX0UI5tkyjXcOb433bE0YF/G rm2g==
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:from:date :message-id:subject:to:cc; bh=/59NUl0k2ojOckf4uiFD8ckfAiWr88TpxEf7ZsgUu1A=; b=iJCKLjVjBDJ9M/BRCgDKqd6jBUtxdbXMFt2FMUZ+grTDrR/ZHXIc4PITPI8eEXgZue DiDHC9Bc4hkCzFJDJtyS2mg5ihbUInm8mqIhcHkggpnrq3bQL90Bv6WKBvHnM6FvFQvI 5ZajFOth5sVewL6SlNWHy20AbI30XWhddMQfo80ZeBxT9f1HK0tsvF50NiqJUch2Acnv rBMPvbOIkLy/PuAkwyWNdfCIbzpMCxNWYvxL1AEonuHxe7M9iO7TfT4+GVL1QOl4wqEm RP0JmPavxJc394bXoSjHbXwA/xp171SsavOhuDumevpJiY1lhEXLnpcRZwu3pWA5CMtG tWEQ==
X-Gm-Message-State: AEkoouu6dWdzbRtBncTaU0SsJzpUhw1AlvIgdtZq0susNOiZmzRCOsRaWAYJ3IIMxkJv9Fjmug9PhEZAlFIbQg==
X-Received: by 10.31.227.196 with SMTP id a187mr3485653vkh.89.1471934496443; Mon, 22 Aug 2016 23:41:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.176.7.41 with HTTP; Mon, 22 Aug 2016 23:41:35 -0700 (PDT)
In-Reply-To: <7F859F89F9B4DD4DB902232F9E2DAC083873C9AD@ESGSCMB103.ericsson.se>
References: <7F859F89F9B4DD4DB902232F9E2DAC083873C373@ESGSCMB103.ericsson.se>  <7F859F89F9B4DD4DB902232F9E2DAC083873C9AD@ESGSCMB103.ericsson.se>
From: Sam Aldrin 
Date: Mon, 22 Aug 2016 23:41:35 -0700
Message-ID: 
To: Adrian Pan 
Content-Type: multipart/alternative; boundary=001a114e0198cb11ce053ab7743d
Archived-At: 
Cc: netmod WG , "kkoushik@cisco.com" 
Subject: Re: [netmod] Question about acl-type in draft-ietf-netmod-acl-model-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: Tue, 23 Aug 2016 06:41:40 -0000

--001a114e0198cb11ce053ab7743d
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Model design shouldn't be limited by the device capabilities, rather it
should be agnostic.
The existing IETF model is more of a YANG version of CLI, which is rather
limiting from operational perspective.

How do we (operators) like to see ACL model should be? take a look at the
model we published (work in progress) at <
https://github.com/openconfig/public/tree/master/release/models/acl>

-sam

On Mon, Aug 22, 2016 at 7:04 AM, Adrian Pan  wrote=
:

> Hi Dean,
>
>
>
> 3)   With the model definition, even the acl-type is configured as
> Ethernet, the operator still can configure the matches of ace under the
> acl as ipv4 or ipv6, right?
>
>
>
> No, if ACL type is ethernet, then all ACEs are expected to be ethernet.
>
> [Adrian] I understand your point, but this is not reflected in the model,
> if according to the model, the operator still can configure the acl-type
> as Ethernet, while configure the ace of the acl as ipv4, and this should
> be valid configuration.
>
> is this the model design intention?
>
>
>
> If acl-type is of one family, then only ace with match condition from
> that family are expected to be in the acl. If you want to combine them,
> please use mixed type.
>
> [Adrian] if it=E2=80=99s only expected to be the same as the acl-type, bu=
t
> without the restriction in the model, you can=E2=80=99t avoid the operato=
r
> configuration to mix the acl-type and the ace matches. So my thinking is
> that, can we add the restriction in the model for this as below to better
> reflect the model design intention?
>
>
>
>
>
>
>
> container matches {
>
>   description
>
>     "Definitions for match criteria for this Access List
>
> Entry.";
>
>
>
>   container ace-ipv4 {
>
>     when "../../acl-type=3D'ipv4-acl'";
>
>     description "IPv4 Access List Entry.";
>
>     uses packet-fields:acl-ip-header-fields;
>
>     uses packet-fields:acl-ipv4-header-fields;
>
>   }
>
>   container ace-ipv6 {
>
>     when "../../acl-type=3D'ipv6-acl'";
>
>     description "IPv6 Access List Entry.";
>
>     uses packet-fields:acl-ip-header-fields;
>
>     uses packet-fields:acl-ipv6-header-fields;
>
>   }
>
>   container ace-eth {
>
>     when "../../acl-type=3D'eth-acl'";
>
>     description
>
>       "Ethernet Access List entry.";
>
>     uses packet-fields:acl-eth-header-fields;
>
>   }
>
> }
>
>
>
>
>
> Thanks
>
> Adrian
>
>
>
> *From:* Dean Bogdanovic [mailto:ivandean@gmail.com]
> *Sent:* Monday, August 22, 2016 5:39 PM
> *To:* Adrian Pan 
> *Cc:* kkoushik@cisco.com; lyihuang16@gmail.com; dblair@cisco.com; netmod
> WG 
> *Subject:* Re: Question about acl-type in draft-ietf-netmod-acl-model-08
>
>
>
> (+netmod mailing list)
>
> Adrian,
>
>
>
> Please see inline
>
> On Aug 22, 2016, at 2:27 AM, Adrian Pan  wrote:
>
>
>
> Dear authors,
>
>
>
> I have some questions about ietf acl model as below, your reply is
> appreciated.
>
>
>
> 1)   In the model definition acl-type is one key of the acl, also in the
> description it says that the acl-type could be ethernet, IPv4, IPv6,
> mixed, in case the acl-type is mixed, what=E2=80=99s the identifier shoul=
d be?
>
> Should it be augmented by different vendor? Since I don=E2=80=99t see the
> definition about it.
>
>
>
> As mixed ACLs are not supported by all vendors, those are not part of the
> standard model. Iit is up to the vendor to augment the ace-type and selec=
t
> an identifier to their liking.
>
>
>
> 2)   In the =E2=80=9Cmix=E2=80=9D case, the =E2=80=9Cmatches=E2=80=9D the=
 ace list can be the combination
> of Ethernet,ipv4,ipv6 for different ace, right?
>
>
>
> Or another combination, again depends on what that particular vendor
> supports.
>
> 3)   With the model definition, even the acl-type is configured as
> Ethernet, the operator still can configure the matches of ace under the
> acl as ipv4 or ipv6, right?
>
>
>
> No, if ACL type is ethernet, then all ACEs are expected to be ethernet.
>
> is this the model design intention?
>
>
>
> If acl-type is of one family, then only ace with match condition from tha=
t
> family are expected to be in the acl. If you want to combine them, please
> use mixed type.
>
>
>
> Dean
>
>
>
> module: ietf-access-control-list
>
>    +--rw access-lists
>
>       +--rw acl* [acl-type acl-name]
>
>          +--rw acl-name               string
>
>          +--rw acl-type               acl-type
>
>          +--ro acl-oper-data
>
>          +--rw access-list-entries
>
>             +--rw ace* [rule-name]
>
>                +--rw rule-name        string
>
>                +--rw matches
>
>                |  +--rw (ace-type)?
>
>
>
>          leaf acl-type {
>
>            type acl-type;
>
>            description
>
>          "Type of access control list. Indicates the primary intended
>
>          type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)
>
>          used in the list instance.";
>
>          }
>
>
>
>
>
> Thanks
>
> Adrian
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

--001a114e0198cb11ce053ab7743d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Model design shouldn't be limited by the device capabi=
lities, rather it should be agnostic.
The existing IETF model is more o=
f a YANG version of CLI, which is rather limiting from operational perspect=
ive.

How do we (operators) like to see ACL model s=
hould be? take a look at the model we published (work in progress) at <<=
a href=3D"https://github.com/openconfig/public/tree/master/release/models/a=
cl">https://github.com/openconfig/public/tree/master/release/models/acl=
>

-sam
On Mon, Aug 22, 2016 at 7:04 AM, Adrian Pan <adrian.pan@ericsson.com> wrote:













Hi Dean,


=C2=A0


3)=C2=A0=C2=A0=C2=A0With
 the model definition, even the=C2=A0acl-type is configured as Ethernet, the operator still can configure the m=
atches of ace under the=C2=A0acl=C2=A0as
 ipv4 or ipv6, right?


=C2=A0


No, if ACL type is
ethernet, then all ACEs are expected to be 
ethernet.=C2=A0


[Adrian] I understa=
nd your point, but this is not reflected in the model, if according to the =
model, the operator
 still can configure the acl-type as Ethernet, while configure=
 the ace of the
acl as ipv4, and this should be valid configuration.






is this the model design intentio=
n?


=C2=A0


If
acl-type is of one family, then only ace with match condition =
from that family are expected to be in the
acl. If you want to combine them, please use mixed type.


[Adrian] if it=E2=80=99s
 only expected to be the same as the acl-type, but without the=
 restriction in the model, you can=E2=80=99t
 avoid the operator configuration to mix the acl-type and the =
ace matches. So my thinking is that, can we add the restriction in the mode=
l for this as below to better reflect the model design intention?=



=C2=A0


=C2=A0


=C2=A0


container matches {=



=C2=A0
description


=C2=A0=C2=A0=C2=A0
"Definitions for match criteria for this Access List<=
/u>


Entry.";


=C2=A0


=C2=A0
container ace-ipv4 {


=C2=A0=C2=A0=C2=A0
when "../../acl-type=3D'ipv4-acl'";


=C2=A0=C2=A0=C2=A0
description "IPv4 Access List Entry.";


=C2=A0=C2=A0=C2=A0
uses packet-fields:acl-ip-header-fields;=



=C2=A0=C2=A0=C2=A0
uses packet-fields:acl-ipv4-header-fields;=



=C2=A0
}


=C2=A0
container ace-ipv6 {


=C2=A0=C2=A0=C2=A0
when "../../acl-type=3D'ipv6-acl'";


=C2=A0=C2=A0=C2=A0
description "IPv6 Access List Entry.";


=C2=A0=C2=A0=C2=A0
uses packet-fields:acl-ip-header-fields;=



=C2=A0=C2=A0=C2=A0
uses packet-fields:acl-ipv6-header-fields;=



=C2=A0
}


=C2=A0
container ace-eth {


=C2=A0=C2=A0=C2=A0
when "../../acl-type=3D'eth-acl&#=
39;";


=C2=A0=C2=A0=C2=A0
description


=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0
"Ethernet Access List entry.";


=C2=A0=C2=A0=C2=A0
uses packet-fields:acl-eth-header-fields;


=C2=A0
}


}



=C2=A0


=C2=A0


Thanks


Adrian


=C2=A0






From:
 Dean Bogdanovic [mailto:ivandean@gmail.com] 

Sent: Monday, August 22, 2016 5:39 PM

To: Adrian Pan <adrian.pan@ericsson.com>

Cc: kkoushik=
@cisco.com; l=
yihuang16@gmail.com; dblair@cisco.com; netmod WG <netmod@ietf.org>

Subject: Re: Question about acl-type in draft-ietf-netmod-acl-model-=
08






=C2=A0




(+netmod mailing li=
st)




Adrian,




=C2=A0






Please see inline








On Aug 22, 2016, at=
 2:27 AM, Adrian Pan <adrian.pan@ericsson.com> wrote:




=C2=A0






Dear authors,=







=C2=A0=







I have some questions about=
=C2=A0ietf=C2=A0acl=C2=
=A0model
 as below, your reply is appreciated.






=C2=A0=







1)=C2=A0=C2=A0=C2=A0In
 the model definition=C2=A0acl-type is one key of=
 the=C2=A0acl, also in the description it says th=
at the=C2=A0acl-type
 could be=C2=A0ethernet, IPv4, IPv6, mixed, in ca=
se the=C2=A0acl-type is mixed, what=
=E2=80=99s
 the identifier should be?














Should it be augmented by differe=
nt vendor? Since I don=E2=80=99t
 see the definition about it.










=C2=A0






As mixed ACLs are n=
ot supported by all vendors, those are not part of the standard model. Iit =
is up to the vendor to augment the ace-type and select an identifier
 to their liking.=C2=A0

















2)=C2=A0=C2=A0=C2=A0In
 the=C2=A0=E2=80=9Cmix=E2=80=9D=
=C2=A0case,
 the=C2=A0=E2=80=9Cmatches=E2=80=9D=C2=A0the
 ace list can be the combination of Ethernet,ipv4,ipv6 for different ace, r=
ight?










=C2=A0




Or another combinat=
ion, again depends on what that particular vendor supports.












3)=C2=A0=C2=A0=C2=A0With
 the model definition, even the=C2=A0acl-type is =
configured as Ethernet, the operator still can configure the matches of ace=
 under the=C2=A0acl=C2=A0as
 ipv4 or ipv6, right?










=C2=A0




No, if ACL type is =
ethernet, then all ACEs are expected to be ethernet.=C2=A0












is this the model design intentio=
n?










=C2=A0




If acl-type is of o=
ne family, then only ace with match condition from that family are expected=
 to be in the acl. If you want to combine them, please use mixed
 type.






=C2=A0






Dean<=
/span>



















module: =
ietf-access-control-list


=C2=A0=C2=A0 =
+--rw access-lists


=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0 +--rw acl* [acl-t=
ype acl-name]


=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw acl-na=
me=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 string


=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw acl-ty=
pe=C2=A0=C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0acl-type


=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro acl-oper-data


=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw access-list-entries=



=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--rw a=
ce* [rule-name]


=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-=
-rw rule-name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 string=



=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +-=
-rw matches


=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=
=C2=A0 +--rw (ace-type)?






=C2=A0=








=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0leaf=C2=
=A0acl-type {



=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0ty=
pe=C2=A0acl-type;



=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0de=
scription



=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"Type of =
access control list. Indicates the primary intended


=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0type of match =
criteria (e.g.=C2=A0ethernet, IPv4, IPv6, mixed,<=
span>=C2=A0etc)



=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0used in the li=
st instance.";



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






=C2=A0=






















Thanks=







Adrian=











=C2=A0









_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a114e0198cb11ce053ab7743d--


From nobody Mon Aug 22 23:42: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 0E93912B04D for ; Mon, 22 Aug 2016 23:42: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, 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 FvpLVb4hQRZA for ; Mon, 22 Aug 2016 23:42:36 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E9D412B006 for ; Mon, 22 Aug 2016 23:42:36 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 9138C9265A8; Tue, 23 Aug 2016 08:42:34 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ryhQ2nke0c2c; Tue, 23 Aug 2016 08:42:34 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 637129265A5; Tue, 23 Aug 2016 08:42:34 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id LrbkwVZ-ox6X; Tue, 23 Aug 2016 08:42:34 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 40F5892659F; Tue, 23 Aug 2016 08:42:34 +0200 (CEST)
Message-ID: <57BBF05A.7040006@transpacket.com>
Date: Tue, 23 Aug 2016 08:42:34 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Alex Campbell , netmod@ietf.org
References: <57BB2169.9050100@transpacket.com>	<20160822.184543.235535345519950294.mbj@tail-f.com>	<57BB37FC.5000202@transpacket.com> <20160822.202715.1748199491210115278.mbj@tail-f.com>, <57BB5554.2000400@transpacket.com> <1471903699434.77842@Aviatnet.com>
In-Reply-To: <1471903699434.77842@Aviatnet.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Aug 2016 06:42:38 -0000

On 08/23/2016 12:08 AM, Alex Campbell wrote:
> The intention in this case is obviously to evaluate the 'must' statement if
> the container contains any values; what would break if we said that
>
>     A non-presence container exists in the data tree if and only if it has
>     any children which exist in the data tree.
>
> thus disallowing the existence of empty NP-containers in the data tree?

The question is where is the misunderstanding.

    "If a node that exists in the accessible tree has a non-presence
    container as a child, then the non-presence container also exists in
    the tree."

What does this mean? I believe there is confusion based on "the tree" 
refering not to the data tree but the Xpath context. At least I hoped 
until I realized the text was introduced as a solution to Y41 
'clarification of "must" in NP-container'. That definitely means it 
addresses the must statements in the non-presence containers and it 
means "the tree" as in the data tree.

1. If "then the non-presence container also exists in the tree." is 
refering to the Xpath context and not the data tree (which is not 
obvious since nowhere is the Xpath context introduced as "the tree") 
then the Xpath validation statements in the non-presence container do 
not have to be evaluated. The only effect is that other Xpath 
expressions testing for the existence of the non-presence container will 
return true.

2. If the meaning is that the non-presence container exists virtually in 
the data tree and its pertaining Xpath expressions have to be evaluated 
then there is a problem. Then it is not only that many unnecessary Xpath 
evaluations will be processed but also designers have to make sure their 
Xpath expressions do not fail when the non-presence container is not 
even created (it is not a problem if the user attempts to create it 
empty then at least there is some bad initiative from him asking for 
error message). Like in the example there will be 95 errors for all 
containers not part of the interface named "me0". There can never be a 
valid configuration for YANG 1.1 for this example. If the must statement 
is modified from must "../name = 'me0'" to "../name='me0' or not 
(./address)" then it will work as intended in YANG 1.0 with the overhead 
of 95 unnecessary evaluations.

If the text you propose is added without the current text removed it 
will be even more difficult to understand the clarification.

Vladimir



From nobody Tue Aug 23 00:34: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 0E1C512D876 for ; Tue, 23 Aug 2016 00:34:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 8QWZiurNY6wM for ; Tue, 23 Aug 2016 00:33:58 -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 B310212D81A for ; Tue, 23 Aug 2016 00:33:57 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 330B793F; Tue, 23 Aug 2016 09:33:56 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id gFFK2dTiwzmO; Tue, 23 Aug 2016 09:33:47 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 23 Aug 2016 09:33:53 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1684E200AB; Tue, 23 Aug 2016 09:33:53 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id V8bPl16Bu1hw; Tue, 23 Aug 2016 09:33:51 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AFEC4200AC; Tue, 23 Aug 2016 09:33:50 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 36C0E3C2E226; Tue, 23 Aug 2016 09:33:48 +0200 (CEST)
Date: Tue, 23 Aug 2016 09:33:48 +0200
From: Juergen Schoenwaelder 
To: Vladimir Vassilev 
Message-ID: <20160823073348.GA15044@elstar.local>
Mail-Followup-To: Vladimir Vassilev , Alex Campbell , netmod@ietf.org
References: <57BB2169.9050100@transpacket.com> <20160822.184543.235535345519950294.mbj@tail-f.com> <57BB37FC.5000202@transpacket.com> <20160822.202715.1748199491210115278.mbj@tail-f.com> <57BB5554.2000400@transpacket.com> <1471903699434.77842@Aviatnet.com> <57BBF05A.7040006@transpacket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57BBF05A.7040006@transpacket.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
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, 23 Aug 2016 07:34:00 -0000

On Tue, Aug 23, 2016 at 08:42:34AM +0200, Vladimir Vassilev wrote:
> On 08/23/2016 12:08 AM, Alex Campbell wrote:
> > The intention in this case is obviously to evaluate the 'must' statement if
> > the container contains any values; what would break if we said that
> > 
> >     A non-presence container exists in the data tree if and only if it has
> >     any children which exist in the data tree.
> > 
> > thus disallowing the existence of empty NP-containers in the data tree?
> 
> The question is where is the misunderstanding.
> 
>    "If a node that exists in the accessible tree has a non-presence
>    container as a child, then the non-presence container also exists in
>    the tree."
> 
> What does this mean? I believe there is confusion based on "the tree"
> refering not to the data tree but the Xpath context. At least I hoped until
> I realized the text was introduced as a solution to Y41 'clarification of
> "must" in NP-container'. That definitely means it addresses the must
> statements in the non-presence containers and it means "the tree" as in the
> data tree.

My reading is that 'tree' refers to the 'accessible tree' used earlier
in the sentence. The accessible tree itself is defined just above the
quoted sentence. If my reading of the text is correct, then the
obvious clarification would be:

OLD

   If a node that exists in the accessible tree has a non-presence
   container as a child, then the non-presence container also exists in
   the tree.

NEW

   If a node that exists in the accessible tree has a non-presence
   container as a child, then the non-presence container also exists in
   the accessible tree.

/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 Aug 23 00:37: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 9236F12D758 for ; Tue, 23 Aug 2016 00:37:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.698
X-Spam-Level: 
X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=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 e4IEBbSZ08Ie for ; Tue, 23 Aug 2016 00:37:03 -0700 (PDT)
Received: from mail-oi0-x22d.google.com (mail-oi0-x22d.google.com [IPv6:2607:f8b0:4003:c06::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 279D112B042 for ; Tue, 23 Aug 2016 00:37:03 -0700 (PDT)
Received: by mail-oi0-x22d.google.com with SMTP id f189so185245893oig.3 for ; Tue, 23 Aug 2016 00:37:03 -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 :content-transfer-encoding:message-id:references:to; bh=UJM0THFfiHrLOlA5VconNjlwSfNmVaII6pnmOuTCcrY=; b=SVPlWnNxz+1kpLnwAvVI+UfXy4gJpd1xmwO38N5EI9N4M6ByJMuvUVgkwpAmFN1q04 iELfsl7Cf0Zzc9Lh10IS7pWiekUs/qKMo+cJ0+HKvF1mf02vlSZ5fvOXCxM7PBMCsmH3 tgoKvmtBfVrjtd+eMSYGjt6kR4iQNDJZA0gYziDdxB7G2yq203LmdletYXpDMUCowxz7 bwSzqedEUEtJsYyPfYqTOcttdckM6fmv2/J8+AsJ7yVhbtUwCTw7pX/pP8zrOTzvwm47 LXODMR0AzkzAfuolumSXa7abzrr+4LkZsvtQaWEuIg9q4pqg7/yTUaQgtbTvLKWVf4XT ZOIQ==
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 :content-transfer-encoding:message-id:references:to; bh=UJM0THFfiHrLOlA5VconNjlwSfNmVaII6pnmOuTCcrY=; b=HSvZ3yMpkZZxUMeFNHK9VuOXdw1p54cFMozvibcewx60XUqqqPloUwIGIcczuBtF+L OmGSewqzBHgqP6ITE0EtRatEv9PvJQJRHGgKWgry0jogGIQPmGlz2MAlUf23X1XjJGcD 60aqhCnleHVcrbuDJRWl3lpYakG7x+HSqmDj5DPTlwhJG+pJZ5uLsEp3saHAwvDNppr/ 3LMIngbptxNB6XlhUfh3iTJTeAupz7qjsFhnez4f6QW7SEUrJlPjcxGOQYDP5uOm6oG/ rCwTrRtf6tKiwPmOlmlDzrHCkHO2VwtsWxucAqf8DHFqSMIAxj3HXtJxpW+ZVW1Y+WoT mPOw==
X-Gm-Message-State: AEkoouvZ6Ii5S+kr0L6nifihLr7c8c255HverLeeuxuVwLhnGH4Rx55MwRwmdTdYrdTzeg==
X-Received: by 10.157.16.83 with SMTP id o19mr16653476oto.194.1471937822387; Tue, 23 Aug 2016 00:37:02 -0700 (PDT)
Received: from [10.250.45.108] (mobile-107-92-62-95.mycingular.net. [107.92.62.95]) by smtp.gmail.com with ESMTPSA id g56sm1129889otc.15.2016.08.23.00.37.00 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Tue, 23 Aug 2016 00:37:01 -0700 (PDT)
Content-Type: multipart/alternative; boundary=Apple-Mail-1E490CAD-9266-43C4-A075-7009369F1684
Mime-Version: 1.0 (1.0)
From: Jeff Tantsura 
X-Mailer: iPhone Mail (13G35)
In-Reply-To: 
Date: Tue, 23 Aug 2016 15:36:56 +0800
Content-Transfer-Encoding: 7bit
Message-Id: <31EE1959-75BA-4B60-A0C2-8189C3B407D6@gmail.com>
References: <7F859F89F9B4DD4DB902232F9E2DAC083873C373@ESGSCMB103.ericsson.se>  <7F859F89F9B4DD4DB902232F9E2DAC083873C9AD@ESGSCMB103.ericsson.se> 
To: Sam Aldrin 
Archived-At: 
Cc: "kkoushik@cisco.com" , netmod WG 
Subject: Re: [netmod] Question about acl-type in draft-ietf-netmod-acl-model-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: Tue, 23 Aug 2016 07:37:05 -0000

--Apple-Mail-1E490CAD-9266-43C4-A075-7009369F1684
Content-Type: text/plain;
	charset=windows-1251
Content-Transfer-Encoding: quoted-printable

+1

It should represent business logic rather than a  subset of existing feature=
s.

Regards,
Jeff

> On Aug 23, 2016, at 2:41 PM, Sam Aldrin  wrote:
>=20
> Model design shouldn't be limited by the device capabilities, rather it sh=
ould be agnostic.
> The existing IETF model is more of a YANG version of CLI, which is rather l=
imiting from operational perspective.
>=20
> How do we (operators) like to see ACL model should be? take a look at the m=
odel we published (work in progress) at 
>=20
> -sam
>=20
>> On Mon, Aug 22, 2016 at 7:04 AM, Adrian Pan  wro=
te:
>> Hi Dean,
>>=20
>> =20
>>=20
>> 3)   With the model definition, even the acl-type is configured as Ethern=
et, the operator still can configure the matches of ace under the acl as ipv=
4 or ipv6, right?
>>=20
>> =20
>>=20
>> No, if ACL type is ethernet, then all ACEs are expected to be ethernet.=20=

>>=20
>> [Adrian] I understand your point, but this is not reflected in the model,=
 if according to the model, the operator still can configure the acl-type as=
 Ethernet, while configure the ace of the acl as ipv4, and this should be va=
lid configuration.
>>=20
>>=20
>> is this the model design intention?
>>=20
>> =20
>>=20
>> If acl-type is of one family, then only ace with match condition from tha=
t family are expected to be in the acl. If you want to combine them, please u=
se mixed type.
>>=20
>> [Adrian] if it=92s only expected to be the same as the acl-type, but with=
out the restriction in the model, you can=92t avoid the operator configurati=
on to mix the acl-type and the ace matches. So my thinking is that, can we a=
dd the restriction in the model for this as below to better reflect the mode=
l design intention?
>>=20
>> =20
>>=20
>> =20
>>=20
>> =20
>>=20
>> container matches {
>>=20
>>   description
>>=20
>>     "Definitions for match criteria for this Access List
>>=20
>> Entry.";
>>=20
>> =20
>>=20
>>   container ace-ipv4 {
>>=20
>>     when "../../acl-type=3D'ipv4-acl'";
>>=20
>>     description "IPv4 Access List Entry.";
>>=20
>>     uses packet-fields:acl-ip-header-fields;
>>=20
>>     uses packet-fields:acl-ipv4-header-fields;
>>=20
>>   }
>>=20
>>   container ace-ipv6 {
>>=20
>>     when "../../acl-type=3D'ipv6-acl'";
>>=20
>>     description "IPv6 Access List Entry.";
>>=20
>>     uses packet-fields:acl-ip-header-fields;
>>=20
>>     uses packet-fields:acl-ipv6-header-fields;
>>=20
>>   }
>>=20
>>   container ace-eth {
>>=20
>>     when "../../acl-type=3D'eth-acl'";
>>=20
>>     description
>>=20
>>       "Ethernet Access List entry.";
>>=20
>>     uses packet-fields:acl-eth-header-fields;
>>=20
>>   }
>>=20
>> }
>>=20
>> =20
>>=20
>> =20
>>=20
>> Thanks
>>=20
>> Adrian
>>=20
>> =20
>>=20
>> From: Dean Bogdanovic [mailto:ivandean@gmail.com]=20
>> Sent: Monday, August 22, 2016 5:39 PM
>> To: Adrian Pan 
>> Cc: kkoushik@cisco.com; lyihuang16@gmail.com; dblair@cisco.com; netmod WG=
 
>> Subject: Re: Question about acl-type in draft-ietf-netmod-acl-model-08
>>=20
>> =20
>>=20
>> (+netmod mailing list)
>>=20
>> Adrian,
>>=20
>> =20
>>=20
>> Please see inline
>>=20
>> On Aug 22, 2016, at 2:27 AM, Adrian Pan  wrote:
>>=20
>> =20
>>=20
>> Dear authors,
>>=20
>> =20
>>=20
>> I have some questions about ietf acl model as below, your reply is apprec=
iated.
>>=20
>> =20
>>=20
>> 1)   In the model definition acl-type is one key of the acl, also in the d=
escription it says that the acl-type could be ethernet, IPv4, IPv6, mixed, i=
n case the acl-type is mixed, what=92s the identifier should be?
>>=20
>> Should it be augmented by different vendor? Since I don=92t  see the defi=
nition about it.
>>=20
>> =20
>>=20
>> As mixed ACLs are not supported by all vendors, those are not part of the=
 standard model. Iit is up to the vendor to augment the ace-type and select a=
n identifier to their liking.=20
>>=20
>>=20
>>=20
>>=20
>> 2)   In the =93mix=94 case, the =93matches=94 the ace list can be the com=
bination of Ethernet,ipv4,ipv6 for different ace, right?
>>=20
>> =20
>>=20
>> Or another combination, again depends on what that particular vendor supp=
orts.
>>=20
>>=20
>> 3)   With the model definition, even the acl-type is configured as Ethern=
et, the operator still can configure the matches of ace under the acl as ipv=
4 or ipv6, right?
>>=20
>> =20
>>=20
>> No, if ACL type is ethernet, then all ACEs are expected to be ethernet.=20=

>>=20
>>=20
>> is this the model design intention?
>>=20
>> =20
>>=20
>> If acl-type is of one family, then only ace with match condition from tha=
t family are expected to be in the acl. If you want to combine them, please u=
se mixed type.
>>=20
>> =20
>>=20
>> Dean
>>=20
>>=20
>>=20
>>=20
>> module: ietf-access-control-list
>>    +--rw access-lists
>>       +--rw acl* [acl-type acl-name]
>>          +--rw acl-name               string
>>          +--rw acl-type               acl-type
>>          +--ro acl-oper-data
>>          +--rw access-list-entries
>>             +--rw ace* [rule-name]
>>                +--rw rule-name        string
>>                +--rw matches
>>                |  +--rw (ace-type)?
>> =20
>>=20
>>          leaf acl-type {
>>=20
>>            type acl-type;
>>=20
>>            description
>>=20
>>          "Type of access control list. Indicates the primary intended
>>=20
>>          type of match criteria (e.g. ethernet, IPv4, IPv6, mixed, etc)
>>=20
>>          used in the list instance.";
>>=20
>>          }
>>=20
>> =20
>>=20
>>=20
>>=20
>>=20
>> Thanks
>>=20
>> Adrian
>>=20
>> =20
>>=20
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

--Apple-Mail-1E490CAD-9266-43C4-A075-7009369F1684
Content-Type: text/html;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable


+1

It should represent business logic=
 rather than a  subset of existing features.

Regards,
Jeff

On Aug 23, 2016, at 2:41 PM, S=
am Aldrin <aldrin.ietf@gmail.com=
> wrote:

Model design shouldn't be limited by the device capabilities, rather it sho=
uld be agnostic.
The existing IETF model is more of a YANG version of CL=
I, which is rather limiting from operational perspective.

How do we (operators) like to see ACL model should be? take a look at=
 the model we published (work in progress) at <https://github.com/ope=
nconfig/public/tree/master/release/models/acl>

-sam

On Mon, Aug 22, 2016 at 7:04 AM, Adrian Pan <adrian.pan@ericsson.com> wrote:













Hi Dean,


 <=
/p>

3)   With
 the model definition, even the acl-type is configured as Ethernet, the operator still can configure the mat=
ches of ace under the acl&=
nbsp;as
 ipv4 or ipv6, right?


 =



No, if ACL type is
ethernet, then all ACEs are expected to be 
ethernet. 


[Adrian] I understand=
 your point, but this is not reflected in the model, if according to the mod=
el, the operator
 still can configure the acl-type as Ethernet, while configure t=
he ace of the
acl as ipv4, and this should be valid configuration.






is this the model design intention?=



 =



If
acl-type is of one family, then only ace with match condition f=
rom that family are expected to be in the
acl. If you want to combine them, please use mixed type.=



[Adrian] if it=
=E2=80=99s
 only expected to be the same as the acl-type, but without the r=
estriction in the model, you can=E2=80=99t
 avoid the operator configuration to mix the acl-type and the a=
ce matches. So my thinking is that, can we add the restriction in the model f=
or this as below to better reflect the model design intention?=



 <=
/p>

 <=
/p>

 <=
/p>

container matches {


 
description


   
"Definitions for match criteria for this Access List


Entry.";


 <=
/p>

 
container ace-ipv4 {


   
when "../../acl-type=3D'ipv4-acl'";=



   
description "IPv4 Access List Entry.";


   
uses packet-fields:acl-ip-header-fields;<=
/u>


   
uses packet-fields:acl-ipv4-header-fields;<=
/p>

 
}


 
container ace-ipv6 {


   
when "../../acl-type=3D'ipv6-acl'";=



   
description "IPv6 Access List Entry.";


   
uses packet-fields:acl-ip-header-fields;<=
/u>


   
uses packet-fields:acl-ipv6-header-fields;<=
/p>

 
}


 
container ace-eth {


   
when "../../acl-type=3D'eth-acl'";


   
description


   &nbs=
p; 
"Ethernet Access List entry.";


   
uses packet-fields:acl-eth-header-fields;=



 
}


}



 =



 =



Thanks<=
/p>

Adrian<=
/p>

 <=
/p>





From:
 Dean Bogdanovic [mailto:ivandean@gmail.com] 

Sent: Monday, August 22, 2016 5:39 PM

To: Adrian Pan <adrian.pan@ericsson.com>

Cc: kkoushik@=
cisco.com; lyi=
huang16@gmail.com; dblair@cisco.com; netmod WG <netmod@ietf.org>

Subject: Re: Question about acl-type in draft-ietf-netmod-acl-model-0=
8






 




(+netmod mailing lis=
t)




Adrian,




 =







Please see inline=









On Aug 22, 2016, at 2=
:27 AM, Adrian Pan <adrian.pan@ericsson.com> wrote:




 =







Dear authors,






 






I have some questions about&n=
bsp;ietf acl <=
/span>model
 as below, your reply is appreciated.






 






1)   In
 the model definition acl-type is one key of t=
he acl, also in the description it says that t=
he acl-type
 could be ethernet, IPv4, IPv6, mixed, in cas=
e the acl-type is mixed, what=E2=
=80=99s
 the identifier should be?














Should it be augmented by different=
 vendor? Since I don=E2=80=99t
 see the definition about it.










 =







As mixed ACLs are no=
t supported by all vendors, those are not part of the standard model. Iit is=
 up to the vendor to augment the ace-type and select an identifier
 to their liking. 

















2)   In
 the =E2=80=9Cmix=E2=80=9D<=
span>&nbs=
p;case,
 the =E2=80=9Cmatches=E2=80=9D=
 the
 ace list can be the combination of Ethernet,ipv4,ipv6 for different ace, ri=
ght?










 =





Or another combinati=
on, again depends on what that particular vendor supports.












3)   With
 the model definition, even the acl-type is c=
onfigured as Ethernet, the operator still can configure the matches of ace u=
nder the acl as
 ipv4 or ipv6, right?










 =





No, if ACL type is e=
thernet, then all ACEs are expected to be ethernet. 












is this the model design intention?=











 =





If acl-type is of on=
e family, then only ace with match condition from that family are expected t=
o be in the acl. If you want to combine them, please use mixed
 type.






 =







Dean



















module: ietf-access-control-list


   +--=
rw access-lists


  &nbs=
p;   +--rw acl* [acl-type <=
span>acl-name]


  &nbs=
p;      +--rw acl-name&nb=
sp;            &=
nbsp; string


  &nbs=
p;      +--rw acl-type&nb=
sp;             =
 acl-type


  &nbs=
p;      +--ro acl-o=
per-data


  &nbs=
p;      +--rw access-list-entries


  &nbs=
p;         +--rw ace* [=
rule-name]


  &nbs=
p;            +--rw rule-name        string


  &nbs=
p;            +--rw matches


  &nbs=
p;            | =
 +--rw (ace-type)?






 







 &=
nbsp;       leaf =
acl-type {



 &=
nbsp;         type=
 acl-type;



 &=
nbsp;         desc=
ription



 &=
nbsp;       "Type of access c=
ontrol list. Indicates the primary intended



 &=
nbsp;       type of match cr=
iteria (e.g. ethernet, IPv4, IPv6, mixed, etc)



 &=
nbsp;       used in the list=
 instance.";



 &=
nbsp;       }<=
u>






 





















Thanks






Adrian










 =










_______________________________________________

netmod mailing list

netmod@ietf.org

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





____________________=
___________________________
netmod mailing list
netmod@ietf.org
<=
a href=3D"https://www.ietf.org/mailman/listinfo/netmod">https://www.ietf.org=
/mailman/listinfo/netmod
=

--Apple-Mail-1E490CAD-9266-43C4-A075-7009369F1684--


From nobody Tue Aug 23 01:10: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 6BFFB12D758 for ; Tue, 23 Aug 2016 01:10:16 -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 6q7X9vyrmFp6 for ; Tue, 23 Aug 2016 01:10:15 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DAF9212D87C for ; Tue, 23 Aug 2016 01:10:14 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B9C57926600; Tue, 23 Aug 2016 10:10:12 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id Wmmc9hMdedWS; Tue, 23 Aug 2016 10:10:12 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 8D2C89265FE; Tue, 23 Aug 2016 10:10:12 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Jah66hV9ywfL; Tue, 23 Aug 2016 10:10:12 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 616409265F2; Tue, 23 Aug 2016 10:10:12 +0200 (CEST)
Message-ID: <57BC04E4.6090308@transpacket.com>
Date: Tue, 23 Aug 2016 10:10:12 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Juergen Schoenwaelder ,  netmod@ietf.org
References: <57BB2169.9050100@transpacket.com> <20160822.184543.235535345519950294.mbj@tail-f.com> <57BB37FC.5000202@transpacket.com> <20160822.202715.1748199491210115278.mbj@tail-f.com> <57BB5554.2000400@transpacket.com> <1471903699434.77842@Aviatnet.com> <57BBF05A.7040006@transpacket.com> <20160823073348.GA15044@elstar.local>
In-Reply-To: <20160823073348.GA15044@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Aug 2016 08:10:16 -0000

On 08/23/2016 09:33 AM, Juergen Schoenwaelder wrote:
> On Tue, Aug 23, 2016 at 08:42:34AM +0200, Vladimir Vassilev wrote:
>> On 08/23/2016 12:08 AM, Alex Campbell wrote:
>>> The intention in this case is obviously to evaluate the 'must' statement if
>>> the container contains any values; what would break if we said that
>>>
>>>      A non-presence container exists in the data tree if and only if it has
>>>      any children which exist in the data tree.
>>>
>>> thus disallowing the existence of empty NP-containers in the data tree?
>> The question is where is the misunderstanding.
>>
>>     "If a node that exists in the accessible tree has a non-presence
>>     container as a child, then the non-presence container also exists in
>>     the tree."
>>
>> What does this mean? I believe there is confusion based on "the tree"
>> refering not to the data tree but the Xpath context. At least I hoped until
>> I realized the text was introduced as a solution to Y41 'clarification of
>> "must" in NP-container'. That definitely means it addresses the must
>> statements in the non-presence containers and it means "the tree" as in the
>> data tree.
> My reading is that 'tree' refers to the 'accessible tree' used earlier
> in the sentence. The accessible tree itself is defined just above the
> quoted sentence. If my reading of the text is correct, then the
> obvious clarification would be:
>
> OLD
>
>     If a node that exists in the accessible tree has a non-presence
>     container as a child, then the non-presence container also exists in
>     the tree.
>
> NEW
>
>     If a node that exists in the accessible tree has a non-presence
>     container as a child, then the non-presence container also exists in
>     the accessible tree.
>
> /js
>
So should the must statements defined in the non-presence container 
which is now part of the accessible tree be evaluated or not?

Vladimir


From nobody Tue Aug 23 01:16: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 2F87212D87C for ; Tue, 23 Aug 2016 01:16:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 DoHrM51raEdz for ; Tue, 23 Aug 2016 01:16:16 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id BCBC712B00C for ; Tue, 23 Aug 2016 01:16:15 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 7926C1AE018C; Tue, 23 Aug 2016 10:16:14 +0200 (CEST)
Date: Tue, 23 Aug 2016 10:15:17 +0200 (CEST)
Message-Id: <20160823.101517.293640528041965584.mbj@tail-f.com>
To: vladimir@transpacket.com
From: Martin Bjorklund 
In-Reply-To: <57BC04E4.6090308@transpacket.com>
References: <57BBF05A.7040006@transpacket.com> <20160823073348.GA15044@elstar.local> <57BC04E4.6090308@transpacket.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Aug 2016 08:16:17 -0000

Vladimir Vassilev  wrote:
> On 08/23/2016 09:33 AM, Juergen Schoenwaelder wrote:
> > On Tue, Aug 23, 2016 at 08:42:34AM +0200, Vladimir Vassilev wrote:
> >> On 08/23/2016 12:08 AM, Alex Campbell wrote:
> >>> The intention in this case is obviously to evaluate the 'must'
> >>> statement if
> >>> the container contains any values; what would break if we said that
> >>>
> >>>      A non-presence container exists in the data tree if and only if it
> >>>      has
> >>>      any children which exist in the data tree.
> >>>
> >>> thus disallowing the existence of empty NP-containers in the data
> >>> tree?
> >> The question is where is the misunderstanding.
> >>
> >>     "If a node that exists in the accessible tree has a non-presence
> >>     container as a child, then the non-presence container also exists in
> >>     the tree."
> >>
> >> What does this mean? I believe there is confusion based on "the tree"
> >> refering not to the data tree but the Xpath context. At least I hoped
> >> until
> >> I realized the text was introduced as a solution to Y41 'clarification
> >> of
> >> "must" in NP-container'. That definitely means it addresses the must
> >> statements in the non-presence containers and it means "the tree" as
> >> in the
> >> data tree.
> > My reading is that 'tree' refers to the 'accessible tree' used earlier
> > in the sentence. The accessible tree itself is defined just above the
> > quoted sentence. If my reading of the text is correct, then the
> > obvious clarification would be:
> >
> > OLD
> >
> >     If a node that exists in the accessible tree has a non-presence
> >     container as a child, then the non-presence container also exists in
> >     the tree.
> >
> > NEW
> >
> >     If a node that exists in the accessible tree has a non-presence
> >     container as a child, then the non-presence container also exists in
> >     the accessible tree.
> >
> > /js
> >
> So should the must statements defined in the non-presence container
> which is now part of the accessible tree be evaluated or not?

They are evaluated.  See Section 7.5.3:

   When a datastore is validated, all "must" constraints are
   conceptually evaluated once for each node in the accessible tree (see
   Section 6.4.1).


/martin


From nobody Tue Aug 23 01:18: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 9B20B12D885 for ; Tue, 23 Aug 2016 01:18:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 QNimjcflnLQ2 for ; Tue, 23 Aug 2016 01:17:59 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3213512D880 for ; Tue, 23 Aug 2016 01:17:59 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 19FF31AE018C; Tue, 23 Aug 2016 10:17:58 +0200 (CEST)
Date: Tue, 23 Aug 2016 10:17:03 +0200 (CEST)
Message-Id: <20160823.101703.2185386434861015146.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20160823073348.GA15044@elstar.local>
References: <1471903699434.77842@Aviatnet.com> <57BBF05A.7040006@transpacket.com> <20160823073348.GA15044@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Aug 2016 08:18:01 -0000

Juergen Schoenwaelder  wrote:
> On Tue, Aug 23, 2016 at 08:42:34AM +0200, Vladimir Vassilev wrote:
> > On 08/23/2016 12:08 AM, Alex Campbell wrote:
> > > The intention in this case is obviously to evaluate the 'must' statement if
> > > the container contains any values; what would break if we said that
> > > 
> > >     A non-presence container exists in the data tree if and only if it has
> > >     any children which exist in the data tree.
> > > 
> > > thus disallowing the existence of empty NP-containers in the data tree?
> > 
> > The question is where is the misunderstanding.
> > 
> >    "If a node that exists in the accessible tree has a non-presence
> >    container as a child, then the non-presence container also exists in
> >    the tree."
> > 
> > What does this mean? I believe there is confusion based on "the tree"
> > refering not to the data tree but the Xpath context. At least I hoped until
> > I realized the text was introduced as a solution to Y41 'clarification of
> > "must" in NP-container'. That definitely means it addresses the must
> > statements in the non-presence containers and it means "the tree" as in the
> > data tree.
> 
> My reading is that 'tree' refers to the 'accessible tree' used earlier
> in the sentence. The accessible tree itself is defined just above the
> quoted sentence. If my reading of the text is correct, then the
> obvious clarification would be:
> 
> OLD
> 
>    If a node that exists in the accessible tree has a non-presence
>    container as a child, then the non-presence container also exists in
>    the tree.
> 
> NEW
> 
>    If a node that exists in the accessible tree has a non-presence
>    container as a child, then the non-presence container also exists in
>    the accessible tree.

I think this is a useful and correct clarification.


/martin


From nobody Tue Aug 23 01:26: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 6D4E312D886 for ; Tue, 23 Aug 2016 01:26:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 r5RqdiAK-WIw for ; Tue, 23 Aug 2016 01:26:03 -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 242C412D87C for ; Tue, 23 Aug 2016 01:26:03 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id EAF07A80; Tue, 23 Aug 2016 10:26:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id qUVh7mb69o4F; Tue, 23 Aug 2016 10:25:54 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Tue, 23 Aug 2016 10:26:00 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id CC37A200AC; Tue, 23 Aug 2016 10:26:00 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id i4Y6pwo-Bsw3; Tue, 23 Aug 2016 10:25:59 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 437AC200AB; Tue, 23 Aug 2016 10:25:59 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 2B82A3C2E3C9; Tue, 23 Aug 2016 10:25:59 +0200 (CEST)
Date: Tue, 23 Aug 2016 10:25:59 +0200
From: Juergen Schoenwaelder 
To: Vladimir Vassilev 
Message-ID: <20160823082559.GC15044@elstar.local>
Mail-Followup-To: Vladimir Vassilev , netmod@ietf.org
References: <57BB2169.9050100@transpacket.com> <20160822.184543.235535345519950294.mbj@tail-f.com> <57BB37FC.5000202@transpacket.com> <20160822.202715.1748199491210115278.mbj@tail-f.com> <57BB5554.2000400@transpacket.com> <1471903699434.77842@Aviatnet.com> <57BBF05A.7040006@transpacket.com> <20160823073348.GA15044@elstar.local> <57BC04E4.6090308@transpacket.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <57BC04E4.6090308@transpacket.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
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, 23 Aug 2016 08:26:04 -0000

On Tue, Aug 23, 2016 at 10:10:12AM +0200, Vladimir Vassilev wrote:
> On 08/23/2016 09:33 AM, Juergen Schoenwaelder wrote:
> > On Tue, Aug 23, 2016 at 08:42:34AM +0200, Vladimir Vassilev wrote:
> > > On 08/23/2016 12:08 AM, Alex Campbell wrote:
> > > > The intention in this case is obviously to evaluate the 'must' statement if
> > > > the container contains any values; what would break if we said that
> > > > 
> > > >      A non-presence container exists in the data tree if and only if it has
> > > >      any children which exist in the data tree.
> > > > 
> > > > thus disallowing the existence of empty NP-containers in the data tree?
> > > The question is where is the misunderstanding.
> > > 
> > >     "If a node that exists in the accessible tree has a non-presence
> > >     container as a child, then the non-presence container also exists in
> > >     the tree."
> > > 
> > > What does this mean? I believe there is confusion based on "the tree"
> > > refering not to the data tree but the Xpath context. At least I hoped until
> > > I realized the text was introduced as a solution to Y41 'clarification of
> > > "must" in NP-container'. That definitely means it addresses the must
> > > statements in the non-presence containers and it means "the tree" as in the
> > > data tree.
> > My reading is that 'tree' refers to the 'accessible tree' used earlier
> > in the sentence. The accessible tree itself is defined just above the
> > quoted sentence. If my reading of the text is correct, then the
> > obvious clarification would be:
> > 
> > OLD
> > 
> >     If a node that exists in the accessible tree has a non-presence
> >     container as a child, then the non-presence container also exists in
> >     the tree.
> > 
> > NEW
> > 
> >     If a node that exists in the accessible tree has a non-presence
> >     container as a child, then the non-presence container also exists in
> >     the accessible tree.
> > 
> > /js
> > 
> So should the must statements defined in the non-presence container which is
> now part of the accessible tree be evaluated or not?
>

I think we need to carefully dissect things in order to make
progress. The above text is about XPATH contexts and accessible
trees. It is not about what needs to be checked during
validation. This is defined in section 8 and in particular section
8.1.

   The following properties are true in a valid data tree:

   o  All "must" constraints MUST evaluate to "true".

This clearly talks about the data tree. The resolution of issue 42
says:

   2014-07-21 meeting proposal: Clarify that for validation purposes,
   NP containers always exist.

Putting these pieces together, it seems to me that for the purpose of
validation, an NP container is assumed to always exist in the data
tree and its MUST statement is evaluated.

/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 Aug 23 01:33: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 F044512D88F for ; Tue, 23 Aug 2016 01:33:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 N_Vu5_eHu0dt for ; Tue, 23 Aug 2016 01:33:56 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9A2612D897 for ; Tue, 23 Aug 2016 01:33:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 1CD0C926608; Tue, 23 Aug 2016 10:33:54 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 9QKqRZFYfkaJ; Tue, 23 Aug 2016 10:33:54 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id AFF6C92660F; Tue, 23 Aug 2016 10:33:53 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id 7byoWafbXFHQ; Tue, 23 Aug 2016 10:33:53 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 8DC48926608; Tue, 23 Aug 2016 10:33:53 +0200 (CEST)
Message-ID: <57BC0A70.1080006@transpacket.com>
Date: Tue, 23 Aug 2016 10:33:52 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Martin Bjorklund , netmod@ietf.org
References: <57BBF05A.7040006@transpacket.com>	<20160823073348.GA15044@elstar.local>	<57BC04E4.6090308@transpacket.com> <20160823.101517.293640528041965584.mbj@tail-f.com>
In-Reply-To: <20160823.101517.293640528041965584.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Aug 2016 08:33:57 -0000

On 08/23/2016 10:15 AM, Martin Bjorklund wrote:
> They are evaluated.  See Section 7.5.3:
>
>     When a datastore is validated, all "must" constraints are
>     conceptually evaluated once for each node in the accessible tree (see
>     Section 6.4.1).
>
>
> /martin
Then we have the case I objected to and the example:

YANG 1.0:

augment "/if:interfaces/if:interface" {
     container inet {
         must "../name = 'me0'" {
             description
                  "The inet container is only valid for the management 
('me0') interface.";
         }
         leaf address {
             type inet:ip-prefix;
         }
     }
}

YANG 1.1 (replace "../name = 'me0'" with "../name='me0' or not 
(./address)" and process 95 unnecessary Xpath evaluations).

I think this proves the argument that there will be more unnecessary 
Xpath processing. In addition it illustrates how a simple task requires 
ugly patch (the ".. or not (./address)" added to the must expression) 
just to ensure the expression does not fail in the default case where 
the interface is not named "me0" and the user has not even attempted to 
create empty /interfaces/interface/inet container in YANG 1.1.

Vladimir


From nobody Tue Aug 23 02:10: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 DD62912D8D0 for ; Tue, 23 Aug 2016 02:10:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 PQTywIho1MOV for ; Tue, 23 Aug 2016 02:10: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 2220512D8CF for ; Tue, 23 Aug 2016 02:10:21 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 3F6551AE018C; Tue, 23 Aug 2016 11:10:18 +0200 (CEST)
Date: Tue, 23 Aug 2016 11:09:24 +0200 (CEST)
Message-Id: <20160823.110924.2249827059453254780.mbj@tail-f.com>
To: vladimir@transpacket.com
From: Martin Bjorklund 
In-Reply-To: <57BC0A70.1080006@transpacket.com>
References: <57BC04E4.6090308@transpacket.com> <20160823.101517.293640528041965584.mbj@tail-f.com> <57BC0A70.1080006@transpacket.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Aug 2016 09:10:23 -0000

Vladimir Vassilev  wrote:
> On 08/23/2016 10:15 AM, Martin Bjorklund wrote:
> > They are evaluated.  See Section 7.5.3:
> >
> >     When a datastore is validated, all "must" constraints are
> >     conceptually evaluated once for each node in the accessible tree (see
> >     Section 6.4.1).
> >
> >
> > /martin
> Then we have the case I objected to and the example:
> 
> YANG 1.0:
> 
> augment "/if:interfaces/if:interface" {
>     container inet {
>         must "../name = 'me0'" {

This should have been a 'when' expression, not 'must'.  Alternatively,
it should have been a P-container, since obviously the container has
some semantics.  Or alternatively, the must expression should have
been on the address leaf, since this is what you really checked.



/martin


>             description
>                  "The inet container is only valid for the management ('me0')
>                  interface.";
>         }
>         leaf address {
>             type inet:ip-prefix;
>         }
>     }
> }
> 
> YANG 1.1 (replace "../name = 'me0'" with "../name='me0' or not
> (./address)" and process 95 unnecessary Xpath evaluations).
> 
> I think this proves the argument that there will be more unnecessary
> Xpath processing.  In addition it illustrates how a simple task
> requires ugly patch (the ".. or not (./address)" added to the must
> expression) just to ensure the expression does not fail in the default
> case where the interface is not named "me0" and the user has not even
> attempted to create empty /interfaces/interface/inet container in YANG
> 1.1.
> 
> Vladimir
> 


From nobody Tue Aug 23 03:28: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 CB60112B044 for ; Tue, 23 Aug 2016 03:28:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 mXdie2aA-mnm for ; Tue, 23 Aug 2016 03:28:26 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BDF8012D90C for ; Tue, 23 Aug 2016 03:28:24 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:998e:ff6a:8065:9f67] (unknown [IPv6:2001:718:1a02:1:998e:ff6a:8065:9f67]) by mail.nic.cz (Postfix) with ESMTPSA id 2028D60B7D; Tue, 23 Aug 2016 12:28:23 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471948103; bh=7PskThZ+wGWXsv8pNnAwXMcXws0xFTe2h3lhE0VwK44=; h=From:Date:To; b=rTON72Ss/gGCFq36MUIKwdk7xl76jW5u7GJduAFHR2egG58H64Ms0A1t2v81t72QT /bVGmp8gzcj378nm5JerPsH7TcNG90QrPdtL+vKe7dPYcZCGVnixMB7avpViM65GaN XL69qZLWgTML87CPhJRNVKgWjaw/NsxGBg8v1Ky0=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160823082559.GC15044@elstar.local>
Date: Tue, 23 Aug 2016 12:28:23 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <78AC9EDF-19A4-4F84-8F0E-CD67DAB22554@nic.cz>
References: <57BB2169.9050100@transpacket.com> <20160822.184543.235535345519950294.mbj@tail-f.com> <57BB37FC.5000202@transpacket.com> <20160822.202715.1748199491210115278.mbj@tail-f.com> <57BB5554.2000400@transpacket.com> <1471903699434.77842@Aviatnet.com> <57BBF05A.7040006@transpacket.com> <20160823073348.GA15044@elstar.local> <57BC04E4.6090308@transpacket.com> <20160823082559.GC15044@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] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Aug 2016 10:28:28 -0000

> On 23 Aug 2016, at 10:25, Juergen Schoenwaelder =
 wrote:
>=20
> On Tue, Aug 23, 2016 at 10:10:12AM +0200, Vladimir Vassilev wrote:
>> On 08/23/2016 09:33 AM, Juergen Schoenwaelder wrote:
>>> On Tue, Aug 23, 2016 at 08:42:34AM +0200, Vladimir Vassilev wrote:
>>>> On 08/23/2016 12:08 AM, Alex Campbell wrote:
>>>>> The intention in this case is obviously to evaluate the 'must' =
statement if
>>>>> the container contains any values; what would break if we said =
that
>>>>>=20
>>>>>     A non-presence container exists in the data tree if and only =
if it has
>>>>>     any children which exist in the data tree.
>>>>>=20
>>>>> thus disallowing the existence of empty NP-containers in the data =
tree?
>>>> The question is where is the misunderstanding.
>>>>=20
>>>>    "If a node that exists in the accessible tree has a non-presence
>>>>    container as a child, then the non-presence container also =
exists in
>>>>    the tree."
>>>>=20
>>>> What does this mean? I believe there is confusion based on "the =
tree"
>>>> refering not to the data tree but the Xpath context. At least I =
hoped until
>>>> I realized the text was introduced as a solution to Y41 =
'clarification of
>>>> "must" in NP-container'. That definitely means it addresses the =
must
>>>> statements in the non-presence containers and it means "the tree" =
as in the
>>>> data tree.
>>> My reading is that 'tree' refers to the 'accessible tree' used =
earlier
>>> in the sentence. The accessible tree itself is defined just above =
the
>>> quoted sentence. If my reading of the text is correct, then the
>>> obvious clarification would be:
>>>=20
>>> OLD
>>>=20
>>>    If a node that exists in the accessible tree has a non-presence
>>>    container as a child, then the non-presence container also exists =
in
>>>    the tree.
>>>=20
>>> NEW
>>>=20
>>>    If a node that exists in the accessible tree has a non-presence
>>>    container as a child, then the non-presence container also exists =
in
>>>    the accessible tree.
>>>=20
>>> /js
>>>=20
>> So should the must statements defined in the non-presence container =
which is
>> now part of the accessible tree be evaluated or not?
>>=20
>=20
> I think we need to carefully dissect things in order to make
> progress. The above text is about XPATH contexts and accessible
> trees. It is not about what needs to be checked during
> validation. This is defined in section 8 and in particular section
> 8.1.
>=20
>   The following properties are true in a valid data tree:
>=20
>   o  All "must" constraints MUST evaluate to "true".
>=20
> This clearly talks about the data tree. The resolution of issue 42
> says:
>=20
>   2014-07-21 meeting proposal: Clarify that for validation purposes,
>   NP containers always exist.
>=20
> Putting these pieces together, it seems to me that for the purpose of
> validation, an NP container is assumed to always exist in the data
> tree and its MUST statement is evaluated.

But only if the closest ancestor that is not an NP-container exists, or =
there is no such ancestor.

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         
>=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 Aug 23 03:46: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 A2C0E12B04B for ; Tue, 23 Aug 2016 03:46:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 H-0jC9ckwpHd for ; Tue, 23 Aug 2016 03:45:59 -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 2F6CB12B044 for ; Tue, 23 Aug 2016 03:45:59 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:998e:ff6a:8065:9f67] (unknown [IPv6:2001:718:1a02:1:998e:ff6a:8065:9f67]) by mail.nic.cz (Postfix) with ESMTPSA id DDD5D60DD7; Tue, 23 Aug 2016 12:45:57 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1471949157; bh=rV3QOtc8JzVbKl9mr4mupZEFJuuKZNi+784l6ZAZ8rs=; h=From:Date:To; b=vnPJ2qaprmgM6/cMtiBGyWSIvnUzQ3KVcb//yJgtddyI1Vul6rDfjyuVg09S5u+UF HxK9TGoITSDtIBybDg23AqRjI6D4jOatte+QVMnuXLBXaIe01GRGDLV+Bd/63OFwoY 4KrF6NLhxOREBMzQjdqKgAOl7ZDe68QJm++T7cjE=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160823.110924.2249827059453254780.mbj@tail-f.com>
Date: Tue, 23 Aug 2016 12:45:58 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <57BC04E4.6090308@transpacket.com> <20160823.101517.293640528041965584.mbj@tail-f.com> <57BC0A70.1080006@transpacket.com> <20160823.110924.2249827059453254780.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
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] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Aug 2016 10:46:00 -0000

> On 23 Aug 2016, at 11:09, Martin Bjorklund  wrote:
>=20
> Vladimir Vassilev  wrote:
>> On 08/23/2016 10:15 AM, Martin Bjorklund wrote:
>>> They are evaluated.  See Section 7.5.3:
>>>=20
>>>    When a datastore is validated, all "must" constraints are
>>>    conceptually evaluated once for each node in the accessible tree =
(see
>>>    Section 6.4.1).
>>>=20
>>>=20
>>> /martin
>> Then we have the case I objected to and the example:
>>=20
>> YANG 1.0:
>>=20
>> augment "/if:interfaces/if:interface" {
>>    container inet {
>>        must "../name =3D 'me0'" {
>=20
> This should have been a 'when' expression, not 'must'.  Alternatively,

An interesting case would be if there is the "when" statement as you =
suggest, and then also one or more "must" statements. IMO, in this case =
the "when" statement needs to be evaluated first using the procedure of =
sec. 7.21.5, and if (and only if) the result is true, then the "must" =
statements are evaluated. Again, an NP-container is no different from a =
leaf with a default value.

Lada

> it should have been a P-container, since obviously the container has
> some semantics.  Or alternatively, the must expression should have
> been on the address leaf, since this is what you really checked.
>=20
>=20
>=20
> /martin
>=20
>=20
>>            description
>>                 "The inet container is only valid for the management =
('me0')
>>                 interface.";
>>        }
>>        leaf address {
>>            type inet:ip-prefix;
>>        }
>>    }
>> }
>>=20
>> YANG 1.1 (replace "../name =3D 'me0'" with "../name=3D'me0' or not
>> (./address)" and process 95 unnecessary Xpath evaluations).
>>=20
>> I think this proves the argument that there will be more unnecessary
>> Xpath processing.  In addition it illustrates how a simple task
>> requires ugly patch (the ".. or not (./address)" added to the must
>> expression) just to ensure the expression does not fail in the =
default
>> case where the interface is not named "me0" and the user has not even
>> attempted to create empty /interfaces/interface/inet container in =
YANG
>> 1.1.
>>=20
>> Vladimir
>>=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 Tue Aug 23 03:47: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 5848812D92E for ; Tue, 23 Aug 2016 03:47:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 uAPrZfe0-vkF for ; Tue, 23 Aug 2016 03:47:37 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id E9EE212D920 for ; Tue, 23 Aug 2016 03:47:36 -0700 (PDT)
Received: from localhost (unknown [173.38.220.38]) by mail.tail-f.com (Postfix) with ESMTPSA id 9EFAF1AE018C; Tue, 23 Aug 2016 12:47:32 +0200 (CEST)
Date: Tue, 23 Aug 2016 12:46:40 +0200 (CEST)
Message-Id: <20160823.124640.1502573929755855289.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <57BC0A70.1080006@transpacket.com> <20160823.110924.2249827059453254780.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Aug 2016 10:47:38 -0000

Ladislav Lhotka  wrote:
> 
> > On 23 Aug 2016, at 11:09, Martin Bjorklund  wrote:
> > 
> > Vladimir Vassilev  wrote:
> >> On 08/23/2016 10:15 AM, Martin Bjorklund wrote:
> >>> They are evaluated.  See Section 7.5.3:
> >>> 
> >>>    When a datastore is validated, all "must" constraints are
> >>>    conceptually evaluated once for each node in the accessible tree (see
> >>>    Section 6.4.1).
> >>> 
> >>> 
> >>> /martin
> >> Then we have the case I objected to and the example:
> >> 
> >> YANG 1.0:
> >> 
> >> augment "/if:interfaces/if:interface" {
> >>    container inet {
> >>        must "../name = 'me0'" {
> > 
> > This should have been a 'when' expression, not 'must'.  Alternatively,
> 
> An interesting case would be if there is the "when" statement as you
> suggest, and then also one or more "must" statements. IMO, in this
> case the "when" statement needs to be evaluated first using the
> procedure of sec. 7.21.5, and if (and only if) the result is true,
> then the "must" statements are evaluated.

Exactly.  This is no different from any other node w/ both 'when' and
'must' (or 'mandatory', or 'min-elements')


/martin

> Again, an NP-container is no
> different from a leaf with a default value.




> 
> Lada
> 
> > it should have been a P-container, since obviously the container has
> > some semantics.  Or alternatively, the must expression should have
> > been on the address leaf, since this is what you really checked.
> > 
> > 
> > 
> > /martin
> > 
> > 
> >>            description
> >>                 "The inet container is only valid for the management
> >>                 ('me0')
> >>                 interface.";
> >>        }
> >>        leaf address {
> >>            type inet:ip-prefix;
> >>        }
> >>    }
> >> }
> >> 
> >> YANG 1.1 (replace "../name = 'me0'" with "../name='me0' or not
> >> (./address)" and process 95 unnecessary Xpath evaluations).
> >> 
> >> I think this proves the argument that there will be more unnecessary
> >> Xpath processing.  In addition it illustrates how a simple task
> >> requires ugly patch (the ".. or not (./address)" added to the must
> >> expression) just to ensure the expression does not fail in the default
> >> case where the interface is not named "me0" and the user has not even
> >> attempted to create empty /interfaces/interface/inet container in YANG
> >> 1.1.
> >> 
> >> Vladimir
> >> 
> > 
> > _______________________________________________
> > 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 Aug 23 04:36: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 73FCA12B01B for ; Tue, 23 Aug 2016 04:36:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 1lnZa89ygheV for ; Tue, 23 Aug 2016 04:36:20 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B81712B018 for ; Tue, 23 Aug 2016 04:36:20 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 56C64926791; Tue, 23 Aug 2016 13:36:18 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id 3UB9yHU3He1T; Tue, 23 Aug 2016 13:36:18 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 2D46992678E; Tue, 23 Aug 2016 13:36:18 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id Yw8we7F6jzI2; Tue, 23 Aug 2016 13:36:18 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 0965A926786; Tue, 23 Aug 2016 13:36:18 +0200 (CEST)
Message-ID: <57BC3531.2020603@transpacket.com>
Date: Tue, 23 Aug 2016 13:36:17 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Martin Bjorklund , netmod@ietf.org
References: <57BC04E4.6090308@transpacket.com>	<20160823.101517.293640528041965584.mbj@tail-f.com>	<57BC0A70.1080006@transpacket.com> <20160823.110924.2249827059453254780.mbj@tail-f.com>
In-Reply-To: <20160823.110924.2249827059453254780.mbj@tail-f.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] [Netconf] What should a server response be? - depending on NP-containers
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 23 Aug 2016 11:36:22 -0000

On 08/23/2016 11:09 AM, Martin Bjorklund wrote:
> Vladimir Vassilev  wrote:
>> On 08/23/2016 10:15 AM, Martin Bjorklund wrote:
>>> They are evaluated.  See Section 7.5.3:
>>>
>>>      When a datastore is validated, all "must" constraints are
>>>      conceptually evaluated once for each node in the accessible tree (see
>>>      Section 6.4.1).
>>>
>>>
>>> /martin
>> Then we have the case I objected to and the example:
>>
>> YANG 1.0:
>>
>> augment "/if:interfaces/if:interface" {
>>      container inet {
>>          must "../name = 'me0'" {
> This should have been a 'when' expression, not 'must'.  Alternatively,
> it should have been a P-container, since obviously the container has
> some semantics.  Or alternatively, the must expression should have
> been on the address leaf, since this is what you really checked.
I claim that any example of a must statement in non-presence container 
is affected in a similar way (Has anyone example that proves the 
contrary?). 'when' statements are alternative when the 'must' statement 
depends on data nodes that are not child nodes (which I admit is the 
case in this example). The thing with 'must' expressions in non-presence 
container is they are used in complicated models where 'mandatory' and 
'choice' solutions are not an option and for whatever reason the design 
got to that point the fact is that by introducing the auto-evaluation of 
non-presence containers it is even more complicated to use them. Here an 
example that stops working in YANG 1.1:

augment "/if:interfaces/if:interface" {
     container 2-company-3-crowd {
         must "(a and b and not(c)) or (not(a) and b and c) or (a and 
not(b) and c)" {
         }
         leaf a {
             type string;
         }
         leaf b {
             type string;
         }
         leaf c {
             type string;
         }
     }
}

... to make it work one has to accept to not deny the creation of 
/interfaces/interface/2-company-3-crowd as empty container and modify 
the expression adding ...or (not(a) and not(b) and not(c)).


That said I admit it is not often one needs non-presence container must 
statements. But in the cases one needs them the YANG 1.1 text is not 
helping. It causes all the statements to be processed when no one 
attempts to create them or child nodes residing in them. I find no 
justification for that.

>
>
>
> /martin
>
>
>>              description
>>                   "The inet container is only valid for the management ('me0')
>>                   interface.";
>>          }
>>          leaf address {
>>              type inet:ip-prefix;
>>          }
>>      }
>> }
>>
>> YANG 1.1 (replace "../name = 'me0'" with "../name='me0' or not
>> (./address)" and process 95 unnecessary Xpath evaluations).
>>
>> I think this proves the argument that there will be more unnecessary
>> Xpath processing.  In addition it illustrates how a simple task
>> requires ugly patch (the ".. or not (./address)" added to the must
>> expression) just to ensure the expression does not fail in the default
>> case where the interface is not named "me0" and the user has not even
>> attempted to create empty /interfaces/interface/inet container in YANG
>> 1.1.
>>
>> Vladimir
>>


From nobody Tue Aug 23 07:17: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 C4BFF12DA11 for ; Tue, 23 Aug 2016 07:17:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.148
X-Spam-Level: 
X-Spam-Status: No, score=-1.148 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.548, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=mg-soft.si
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0227euPdsvdD for ; Tue, 23 Aug 2016 07:17:18 -0700 (PDT)
Received: from galileo.mg-soft.si (gate.mg-soft.si [212.30.73.66]) by ietfa.amsl.com (Postfix) with ESMTP id 9E44312D186 for ; Tue, 23 Aug 2016 07:13:27 -0700 (PDT)
Received: from jernejthpPC (tp-x61t.mg-soft.si [10.0.0.222]) by galileo.mg-soft.si (Postfix) with ESMTP id A07BEC417623 for ; Tue, 23 Aug 2016 16:13:25 +0200 (CEST)
DKIM-Filter: OpenDKIM Filter v2.10.3 galileo.mg-soft.si A07BEC417623
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mg-soft.si; s=default; t=1471961605; bh=BkeQc2InkgrgjF27fPRx5CpeWYEvO9xVQCHoqY8M314=; h=From:To:Subject:Date:From; b=M/oRmogZYg2LQVd4zs//2owlF414F2EzddslsJHLQZKjl695BXEn2490adpWxS105 twVuAyRiRZaaOlkmx+vUmCgQT++FKpX1ZWdl5HSmcdH6Ak056k05TC7TCUdhwJZdFb q5lOZjodxrCUyuX2aIyulw73VZomBNiqoal6Od0VToeSPowAanf6XjVr/jBAmZNmMR mav8B7b0llktjhASv/OE6vhoejni70wRXRvmIRq7i0/kQuEHKykgpfiScZxV33H03g Cdg2ewdo8gUcsg7BLMOal2wV5UeT/mfVDBbFRrUmdkmvJUNzZs9iMJOMSw+BUUoYZn DvtWKqddVz4Jw==
From: "Jernej Tuljak" 
To: 
Date: Tue, 23 Aug 2016 16:13:23 +0200
Message-ID: <062e01d1fd48$82309670$8691c350$@mg-soft.si>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_062F_01D1FD59.45BA50D0"
X-Mailer: Microsoft Outlook 15.0
Content-Language: sl
Thread-Index: AdH9PDOosJZHyj+xTeCmHE6QS46nDg==
Archived-At: 
Subject: [netmod] Is this leafref path example valid in YANG 1?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 23 Aug 2016 14:17:25 -0000

This is a multipart message in MIME format.

------=_NextPart_000_062F_01D1FD59.45BA50D0
Content-Type: text/plain;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

Hi,

=20

this is a YANG 1, not 1.1 question.=20

=20

For the following example:

=20

module main {

    namespace "uri:main";

    prefix "m";

    include a;

    include b;

}

=20

submodule a {

    belongs-to main {

        prefix "a";

    }

    include b;

    container top {

        leaf top-leaf {

            type string;

        }

        uses foo;

    }   =20

}

=20

submodule b {

    belongs-to main {

        prefix "b";

    }

    grouping foo {

        leaf some-leaf {

            type leafref {

                path "/top/top-leaf";

            }

        }

    }

}

=20

Note the "path" expression that is referencing names that do not seem to =
be in b's scope. Is this a valid "path" expression (names resolved upon =
usage) or should all names inside the "grouping" be resolved where the =
"grouping" is defined?=20

=20

Jernej


------=_NextPart_000_062F_01D1FD59.45BA50D0
Content-Type: text/html;
	charset="UTF-8"
Content-Transfer-Encoding: quoted-printable


Hi,
 
this is a YANG 1, not 1.1 question. =

 
For the following example:
 
module main =
{
=C2=A0=C2=A0=C2=A0 namespace =
"uri:main";
=C2=A0=C2=A0=C2=A0 prefix =
"m";
=C2=A0=C2=A0=C2=A0 include a;
=C2=A0=C2=A0=C2=A0 include =
b;
}
 
submodule a {
=C2=A0=C2=A0=C2=A0 belongs-to main =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prefix =
"a";
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 include =
b;
=C2=A0=C2=A0=C2=A0 container top {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf top-leaf =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 type string;
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
}
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 uses =
foo;
=C2=A0=C2=A0=C2=A0 }=C2=A0=C2=A0=C2=A0 =

}
 
submodule b {
=C2=A0=C2=A0=C2=A0 belongs-to main =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 prefix =
"b";
=C2=A0=C2=A0=C2=A0 }
=C2=A0=C2=A0=C2=A0 grouping foo =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 leaf some-leaf =
{
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 type leafref {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 path =
"/top/top-leaf";
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 }
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
}
=C2=A0=C2=A0=C2=A0 }
}
 
Note the "path" =
expression that is referencing names that do not seem to be in b's =
scope. Is this a valid "path" expression (names resolved upon =
usage) or should all names inside the "grouping" be resolved =
where the "grouping" is defined? 
 
Jernej

------=_NextPart_000_062F_01D1FD59.45BA50D0--


From nobody Wed Aug 24 08:56:06 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 6709712DB29 for ; Wed, 24 Aug 2016 08:56:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.17
X-Spam-Level: 
X-Spam-Status: No, score=-103.17 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, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 IkMq3uWOZdps for ; Wed, 24 Aug 2016 08:56:04 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15F1812D952 for ; Wed, 24 Aug 2016 08:52:59 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 04A50B80AE0; Wed, 24 Aug 2016 08:52:59 -0700 (PDT)
To: j.schoenwaelder@jacobs-university.de, bclaise@cisco.com, joelja@bogus.com,  lberger@labn.net, kwatsen@juniper.net
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20160824155259.04A50B80AE0@rfc-editor.org>
Date: Wed, 24 Aug 2016 08:52:59 -0700 (PDT)
Archived-At: 
Cc: netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Technical Errata Reported] RFC6643 (4786)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 24 Aug 2016 15:56:05 -0000

The following errata report has been submitted for RFC6643,
"Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6643&eid=4786

--------------------------------------
Type: Technical
Reported by: Martin Björklund 

Section: 9.1

Original Text
-------------
      If the current object belongs to a conceptual table,
      then a sequence of leaf statements is generated for each INDEX
      object of the conceptual table.  These leafs are named after the
      INDEX objects and of type leafref.


Corrected Text
--------------
      If the current object belongs to a conceptual table,
      then a sequence of leaf statements is generated for each INDEX
      object of the conceptual table, except that a leaf statement is
      not generated for the current object if it is also an INDEX
      object. These leafs are named after the INDEX objects and of type
      leafref.


Notes
-----
The original text would lead to duplicate leaf nodes if the current object is also part of the INDEX.  Section 9.2 contains an example which shows such a situation, without any duplicates.

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6643 (draft-ietf-netmod-smi-yang-05)
--------------------------------------
Title               : Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules
Publication Date    : July 2012
Author(s)           : J. Schoenwaelder
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Wed Aug 24 09:36: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 3D41A12D182 for ; Wed, 24 Aug 2016 09:36:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 ThZZ_PAKaGjB for ; Wed, 24 Aug 2016 09:36:02 -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 577BA12D128 for ; Wed, 24 Aug 2016 09:36:02 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 264DD80E; Wed, 24 Aug 2016 18:36:01 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id fKEA06VP64Xm; Wed, 24 Aug 2016 18:35:47 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 24 Aug 2016 18:36:00 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 644DE200AC; Wed, 24 Aug 2016 18:36:00 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 9Kemya_mzaO7; Wed, 24 Aug 2016 18:35:59 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 4AD36200A3; Wed, 24 Aug 2016 18:35:59 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 3BFFC3C311EF; Wed, 24 Aug 2016 18:35:57 +0200 (CEST)
Date: Wed, 24 Aug 2016 18:35:57 +0200
From: Juergen Schoenwaelder 
To: RFC Errata System 
Message-ID: <20160824163557.GA17567@elstar.local>
Mail-Followup-To: RFC Errata System , bclaise@cisco.com, joelja@bogus.com, lberger@labn.net, kwatsen@juniper.net, mbj@tail-f.com, netmod@ietf.org
References: <20160824155259.04A50B80AE0@rfc-editor.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160824155259.04A50B80AE0@rfc-editor.org>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org, joelja@bogus.com
Subject: Re: [netmod] [Technical Errata Reported] RFC6643 (4786)
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, 24 Aug 2016 16:36:05 -0000

On Wed, Aug 24, 2016 at 08:52:59AM -0700, RFC Errata System wrote:
> The following errata report has been submitted for RFC6643,
> "Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules".
> 
> --------------------------------------
> You may review the report below and at:
> http://www.rfc-editor.org/errata_search.php?rfc=6643&eid=4786
> 
> --------------------------------------
> Type: Technical
> Reported by: Martin Bj??rklund 
> 
> Section: 9.1
> 
> Original Text
> -------------
>       If the current object belongs to a conceptual table,
>       then a sequence of leaf statements is generated for each INDEX
>       object of the conceptual table.  These leafs are named after the
>       INDEX objects and of type leafref.
> 
> 
> Corrected Text
> --------------
>       If the current object belongs to a conceptual table,
>       then a sequence of leaf statements is generated for each INDEX
>       object of the conceptual table, except that a leaf statement is
>       not generated for the current object if it is also an INDEX
>       object. These leafs are named after the INDEX objects and of type
>       leafref.
>

I agree that the original text needs correction to avoid creation of
duplicate leafs.

/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 Aug 24 11:29:37 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 A1D4712DA83 for ; Wed, 24 Aug 2016 11:29:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.45
X-Spam-Level: 
X-Spam-Status: No, score=-2.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 CjJQcwxPIccp for ; Wed, 24 Aug 2016 11:29:34 -0700 (PDT)
Received: from mailbox.snmp.com (mailbox.snmp.com [192.147.142.80]) by ietfa.amsl.com (Postfix) with ESMTP id CC21C12D595 for ; Wed, 24 Aug 2016 11:29:33 -0700 (PDT)
Received: from rh7.snmp.com (rh7.snmp.com [192.147.142.222]) by mailbox.snmp.com (8.9.3p2-20030922/m.0080228) with ESMTP id OAA08078; Wed, 24 Aug 2016 14:29:26 -0400 (EDT)
Received: from snmp.com (rh7 [IPv6:::1]) by rh7.snmp.com (Postfix) with ESMTP id 78BA05213B6; Wed, 24 Aug 2016 14:29:30 -0400 (EDT)
To: Juergen Schoenwaelder 
From: David Reid 
In-reply-to: Your message of Wed, 24 Aug 2016 18:35:57 +0200. <20160824163557.GA17567@elstar.local>
Date: Wed, 24 Aug 2016 14:29:30 -0400
Sender: reid@snmp.com
Message-Id: <20160824182930.78BA05213B6@rh7.snmp.com>
Archived-At: 
Cc: joelja@bogus.com, netmod@ietf.org, RFC Errata System 
Subject: Re: [netmod] [Technical Errata Reported] RFC6643 (4786)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
Reply-To: David Reid 
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 24 Aug 2016 18:29:35 -0000

> On Wed, Aug 24, 2016 at 08:52:59AM -0700, RFC Errata System wrote:
> > The following errata report has been submitted for RFC6643,
> > "Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules".
> > 
> > --------------------------------------
> > You may review the report below and at:
> > http://www.rfc-editor.org/errata_search.php?rfc=6643&eid=4786
> > 
> > --------------------------------------
> > Type: Technical
> > Reported by: Martin Bj??rklund 
> > 
> > Section: 9.1
> > 
> > Original Text
> > -------------
> >       If the current object belongs to a conceptual table,
> >       then a sequence of leaf statements is generated for each INDEX
> >       object of the conceptual table.  These leafs are named after the
> >       INDEX objects and of type leafref.
> > 
> > 
> > Corrected Text
> > --------------
> >       If the current object belongs to a conceptual table,
> >       then a sequence of leaf statements is generated for each INDEX
> >       object of the conceptual table, except that a leaf statement is
> >       not generated for the current object if it is also an INDEX
> >       object. These leafs are named after the INDEX objects and of type
> >       leafref.
> >
> 
> I agree that the original text needs correction to avoid creation of
> duplicate leafs.
> 
> /js

I also agree.

When I implemented this, it never occurred to me to create a duplicate leaf. 
That is, I think the intent is clear even if the text is not quite right.
In any case, I agree with the correction.

-David Reid


From nobody Thu Aug 25 00:19: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 7ACC612D1A5 for ; Thu, 25 Aug 2016 00:19:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 JhGPRvapj-NK for ; Thu, 25 Aug 2016 00:19:31 -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 1E05612D61D for ; Thu, 25 Aug 2016 00:19:31 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id A5AEDEF6 for ; Thu, 25 Aug 2016 09:19:29 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 9E2SXmoAfRNa for ; Thu, 25 Aug 2016 09:19:12 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu, 25 Aug 2016 09:19:27 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 794FB200AC for ; Thu, 25 Aug 2016 09:19:27 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id KiUX35rZ4Tiu; Thu, 25 Aug 2016 09:19:26 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D39DF200AB; Thu, 25 Aug 2016 09:19:25 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id D5B8B3C322B4; Thu, 25 Aug 2016 09:19:24 +0200 (CEST)
Date: Thu, 25 Aug 2016 09:19:23 +0200
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20160825071923.GA18414@elstar.local>
Mail-Followup-To: netmod@ietf.org
References: <20160818100201.GA4794@elstar.local>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160818100201.GA4794@elstar.local>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Subject: Re: [netmod] YANG 1.1 bug fix last call (was YANG 1.1: XML naming restriction)
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, 25 Aug 2016 07:19:33 -0000

Hi,

since nobody raised any concerns, we will make the change to align
YANG 1.1 with XML 1.0 5th edition (including the yang-identifier
example update mentioned in a subsequent post by Martin).

/js

On Thu, Aug 18, 2016 at 12:02:01PM +0200, Juergen Schoenwaelder wrote:
> Hi,
> 
> as discussed in the thread 'YANG 1.1: XML naming restriction', it
> seems that the restriction that identifiers may not start with "xml"
> is not necessary according to XML 1.0 (5th edition). In addition, it
> seems the YANG 1.1 specification should have an explicit normative
> reference to the XML specification it is based on. The suggested
> document changes are detailed below (thanks to Martin for writing this
> up). Please let the WG know by August 24th if you object against
> implementing this change before YANG 1.1 is published.
> 
> /js (with my RFC6020bis document shepherd hat on)
> 
> Section 1:
> 
> OLD:
> 
>    This document describes the syntax and semantics of version 1.1 of
>    the YANG language.  It also describes how a data model defined in a
>    YANG module is encoded in the Extensible Markup Language (XML), and
> 
> NEW:
> 
>    This document describes the syntax and semantics of version 1.1 of
>    the YANG language.  It also describes how a data model defined in a
>    YANG module is encoded in the Extensible Markup Language (XML)
>    [XML], and
> 
> 
> Section 1.1:
> 
> OLD:
> 
>    o  Allow type empty in a key.
> 
>    The following changes have been done to the NETCONF mapping:
> 
> NEW:
> 
>    o  Allow type empty in a key.
> 
>    o  Removed the restriction that identifiers could not start with
>       the characters "xml".
> 
>    The following changes have been done to the NETCONF mapping:
> 
> 
> Section 14:
> 
> OLD:
> 
>    ;; An identifier MUST NOT start with (('X'|'x') ('M'|'m') ('L'|'l'))
>    identifier          = (ALPHA / "_")
>                          *(ALPHA / DIGIT / "_" / "-" / ".")
> 
> NEW:
> 
>    identifier          = (ALPHA / "_")
>                          *(ALPHA / DIGIT / "_" / "-" / ".")
> 
> 
> Section 21.1:
> 
> NEW:
> 
>    [XML]      Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
>               F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
>               Edition)", World Wide Web Consortium Recommendation REC-
>               xml-20081126, November 2008,
>               .
> 
> 
> -- 
> 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 Thu Aug 25 18:20:57 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 2F85D12B059 for ; Thu, 25 Aug 2016 18:20:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2b6bM2mDDIKv for ; Thu, 25 Aug 2016 18:20:51 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0113.outbound.protection.outlook.com [104.47.32.113]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C193812B016 for ; Thu, 25 Aug 2016 18:20:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=YB2H+g9tZoLQTh8WQ7NMjVTuyS+nM2JVHy0cLCYzr84=; b=Y5pZ3jQvMuzHlCenr6mYJlIY6b+Pglc7jhdo7Xsvs5c7uzNma/GjugNcC+p9JApzuoCXWfc/ZKY7oprGDfcnhqY3Ts5N/EAUlm4DTm3CbSJL7ub8el3Yqa6LUk5RNdEciRKBWo/gpolSppU6KEOWU9Ovo801qqnnGV+RfuV6PNc=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1453.namprd05.prod.outlook.com (10.161.224.150) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.2; Fri, 26 Aug 2016 01:20:47 +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.0599.001; Fri, 26 Aug 2016 01:20:48 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: draft minutes from the netmod 96 sessions
Thread-Index: AQHR/zgTIWKAiMDvsE2aAqUZuL9Wrw==
Date: Fri, 26 Aug 2016 01:20:48 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 65d84525-b680-4d07-2360-08d3cd4f3603
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1453; 6:uEhLfzK60KrpyGEyG5yjNhxSp4cWg4c2MpcxtZnwO+nh9TCSlzyjcWueHSo5d2Mfdoi6O/ObRHubxlYT+JCuCyT36X5xo2Rsm4Ueetb5m64mJZzqa/j5+0EO5RJJOjaTNEb8k9czGvKYenACPITyosiEyif3PMY3IgYtqfT1gr6J4p/vD8zRopgSabNg6JHLbAUyNh+jvkzGrwsZIEb9eGD6D/b/WkQMZoujiF6SFDihPRcUwKqq6Z5XKKi85L0/n6Pu6lbQUHh3G0mfQfgVvP1UPu9XWb57PkZiVImB2XWvk48BtUIok0GaP22Z4cuSRTE+ohsTuAdp1s3LQLFz9Q==; 5:vm4fAkUtlj1TGeIjjqBxZ9MT9PAKaHQGPAMQgB/gIJZTaqWDnIn/rKD9OQj/7QBVxMaXd3DFcFEEHj59I/VN8f9PQinTZ+qzSxAkrEbELlMUNo0QqUGqMqsbmth5tjC4R61d+Ky8Shzic/CQFo64oQ==; 24:HOZAY73Nzd4/aPIvCBrGRfz/53gjAN90A930zV6Rro/GQOmMQ5aVmDw9vFZogbyJt2ugIbPXD1al7nvslXDRQttAZiZldkExuT+PKRfNnGM=; 7:7VLOh9aXKCf9tzyufvomhz/Xutkip2akF7D8gwnE69Dn1/UaLgIePDtn4HhgZNePls/B0eG9yhQnT3e/ypluOhqBuqZEfjW6eGdilrGnVZj6lh5tvXy4X5fNKwMVHpGtkkCU0E8ZL7M21qyJTvm8nWHSQDjla/8WoNwpyW2Mmchvu/2osr1gklxp+3MMNIUA77icQtsHepd8Y9f+X2MLZRy0iC07YbD001hmZ0deYKThCkHUxEYH05vPu2rTec39
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1453;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(102415321)(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:DM2PR0501MB1453; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1453; 
x-forefront-prvs: 00462943DE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(50986999)(106116001)(2501003)(3846002)(6116002)(66066001)(2906002)(5640700001)(68736007)(102836003)(83506001)(5890100001)(99936001)(82746002)(86362001)(5660300001)(19580395003)(19300405004)(586003)(105586002)(54356999)(83716003)(87936001)(1730700003)(2900100001)(8936002)(81156014)(8676002)(558084003)(19625215002)(81166006)(7736002)(7846002)(99286002)(16236675004)(33656002)(2351001)(122556002)(10400500002)(92566002)(101416001)(36756003)(106356001)(189998001)(3660700001)(110136002)(5002640100001)(107886002)(77096005)(3280700002)(4001350100001)(229853001)(450100001)(15975445007)(97736004)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1453; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/mixed; boundary="_004_C3FA72FFE0EB46C492764C1AA9791E6Ajunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2016 01:20:48.0546 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1453
Archived-At: 
Subject: [netmod] draft minutes from the netmod 96 sessions
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 01:20:55 -0000

--_004_C3FA72FFE0EB46C492764C1AA9791E6Ajunipernet_
Content-Type: multipart/alternative;
	boundary="_000_C3FA72FFE0EB46C492764C1AA9791E6Ajunipernet_"

--_000_C3FA72FFE0EB46C492764C1AA9791E6Ajunipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpBdHRhY2hlZCBhcmUgZHJhZnQgbWludXRlcyBmcm9tIHRoZSBORVRNT0QgV0cgc2Vzc2lvbnMg
YXQgSUVURiA5NiAoQmVybGluKS4NCg0KTG91IGFuZCBJIHNjcnViYmVkIHRoZSBtaW51dGVzIGZy
b20gdGhlIHNlc3Npb24gcmVjb3JkaW5ncy4gIFBsZWFzZSByZXZpZXcNCnRoZW0gYW5kIHNlbmQg
YW55IGNvcnJlY3Rpb25zIHlvdeKAmWQgbGlrZSB0byBzZWUgdG8gdXMgYmVmb3JlIGEgd2VlayBm
cm9tDQp0b21vcnJvdyAoU2VwIDJuZCkuDQoNClRoYW5rcywNCktlbnQgKGFuZCBMb3UpDQoNCg0K

--_000_C3FA72FFE0EB46C492764C1AA9791E6Ajunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpzcGFu
LkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1jb21wb3NlOw0KCWZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJY29sb3I6d2luZG93dGV4dDt9DQpzcGFuLm1zb0lucw0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3Jk
U2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGlu
IDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9z
dHlsZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0i
IzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+QXR0YWNoZWQgYXJlIGRyYWZ0IG1pbnV0ZXMgZnJvbSB0aGUgTkVU
TU9EIFdHIHNlc3Npb25zIGF0IElFVEYgOTYgKEJlcmxpbikuPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij5Mb3UgYW5kIEkgc2NydWJiZWQgdGhlIG1pbnV0ZXMgZnJv
bSB0aGUgc2Vzc2lvbiByZWNvcmRpbmdzLiZuYnNwOyBQbGVhc2UgcmV2aWV3PG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPnRoZW0gYW5kIHNlbmQgYW55IGNvcnJlY3Rpb25zIHlvdeKAmWQgbGlrZSB0byBzZWUg
dG8gdXMgYmVmb3JlIGEgd2VlayBmcm9tDQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+dG9tb3Jyb3cgKFNl
cCAybmQpLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhhbmtz
LDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6MTEuMHB0Ij5LZW50IChhbmQgTG91KTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9kaXY+
DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_C3FA72FFE0EB46C492764C1AA9791E6Ajunipernet_--

--_004_C3FA72FFE0EB46C492764C1AA9791E6Ajunipernet_
Content-Type: text/plain; name="notes-ietf-96-netmod.txt"
Content-Description: notes-ietf-96-netmod.txt
Content-Disposition: attachment; filename="notes-ietf-96-netmod.txt";
	size=31205; creation-date="Fri, 26 Aug 2016 01:20:47 GMT";
	modification-date="Fri, 26 Aug 2016 01:20:47 GMT"
Content-ID: <124F179708CB8D48A602B0F356DC171B@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

CgpNaW51dGVzIGZvciBORVRNT0QgV0cgU2Vzc2lvbnMgYXQgSUVURiA5NiAoQmVybGluKQo9PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQoKClNlc3Npb24g
MTogTU9OREFZLCBKdWx5IDE4LCAyMDE2CiAgICAgICAgICAgMTU0MC0xNzQwICBBZnRlcm5vb24g
U2Vzc2lvbiBJSQogICAgICAgICAgIFJvb206IFNjaG9lbmViZXJnCiAgICAgICAgICAgVmlkZW86
IGh0dHA6Ly9yZWNzLmNvbmYubWVldGVjaG8uY29tL1BsYXlvdXQvd2F0Y2guanNwP3JlY29yZGlu
Zz1JRVRGOTZfTkVUQ09ORiZjaGFwdGVyPWNoYXB0ZXJfMQogICAgICAgICAgIEF1ZGlvOiBodHRw
czovL3d3dy5pZXRmLm9yZy9hdWRpby9pZXRmOTYvaWV0Zjk2LXNjaG9lbmViZXJnLTIwMTYwNzE4
LTE1NDAubXAzCgpTZXNzaW9uIDI6IFRVRVNEQVksIEp1bHkgMTksIDIwMTYKICAgICAgICAgICAx
NjIwLTE4MjAgIEFmdGVybm9vbiBTZXNzaW9uIElJCiAgICAgICAgICAgUm9vbTogVGllcmdhcnRl
bgogICAgICAgICAgIFZpZGVvOiBodHRwczovL3d3dy55b3V0dWJlLmNvbS93YXRjaD92PWxwX05y
WUFRVDEwCiAgICAgICAgICAgQXVkaW86IGh0dHBzOi8vd3d3LmlldGYub3JnL2F1ZGlvL2lldGY5
Ni9pZXRmOTYtdGllcmdhcnRlbi0yMDE2MDcxOS0xNjIwXzA0Lm1wMwoKCgpTZXNzaW9uIDE6IChN
b25kYXkgMi1ob3VycykKPT09PT09PT09PT09PT09PT09PT09PT09PT09CgoKICAgKiAxMCBNaW46
ICMwIEludHJvICYgV0cgU3RhdHVzICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChDaGFp
cnMpCiAgICAgc2xpZGVzOiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9zbGlk
ZXMvc2xpZGVzLTk2LW5ldG1vZC0wLnBwdHgKICAgICBzbGlkZXM6IGh0dHBzOi8vd3d3LmlldGYu
b3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbmV0bW9kLTAucGRmCgpCZW5vaXQg
Q2xhaXNlIHByZXNlbnRpbmc6CkJlZW4gd29ya2luZyBvbiB5YW5nIDEuMS4gIGlldGYtbGlicmFy
eS4gb3BzdGF0ZS4KV2UgaGF2ZSBiZWVuIHdvcmtpbmcgb24gdGhlIG9wc3RhdGUgZG9jdW1lbnQu
ICBEaWZmZXJlbmNlIGJldHdlZW4gaW50ZW5kZWQgYW5kIGFwcGxpZWQuCiJTb2x2ZWQiIGluIHlh
bmcgbW9kdWxlIGRlc2lnbi4gIERpc2N1c3NpbmcgcmV2aXNlZCBkYXRhc3RvcmUgY29uY2VwdHMu
Cklzc3VlIGluIHRoaXMgU0RPIGlzIHdlIGRvbid0IHB1Ymxpc2ggdGhlIHdvcmsgYXMgUkZDcyBm
YXN0IGVub3VnaC4KV2UndmUgYmVlbiB3YWl0aW5nIG9uIG9wc3RhdGUgKGRvY3VtZW50KQpObyBl
eHBsaWNpdCBzdXBwb3J0IHRvIHN1cHBvcnQgYXBwbGllZCBjb25maWd1cmF0aW9uLgpXaGF0IGRv
IHdlIGRvIHdpdGggY291bnRlcnM/IC1zdGF0ZSBvciBub3QuICBTaG91bGQgbm90IGxlYXZlIHJv
b20gdW50aWwgd2UgaGF2ZSBndWlkZWxpbmVzIGZvciBhbGwgb2YgSUVURi4gIFRoaXMgaXMgYSBw
cmltYXJ5IGFjaGlldmVtZW50IGZvciB0b2RheS4KV2hhdCBkbyB3ZSBkbyB3aXRoIGNvdW50ZXJz
IC0gaW50byBzdGF0ZSBvciBhbiBvcGVuIGJyYW5jaD8gIE9wZW4gaXNzdWUuICBTaG91bGRuJ3Qg
bGVhdmUgcm9vbSB1bnRpbCB3ZSBnZXQgZ3VpZGFuY2UgdG8gZ2l2ZSB0aGUgcmVzdCBvZiBJRVRG
LlRoaXMgaXMgYSBwcmltYXJ5IGFjaGlldmVtZW50IGZvciB0b2RheS4gCiMgb2YgeWFuZyBtb2R1
bGVzIGluIFJGQ3MuICBXZSdyZSBoaXR0aW5nIGFuIGluZmxlY3Rpb24gcG9pbnQuICBOZWVkIHRv
IGhhdmUgaW4gYSB5ZWFyIGZyb20gbm93IG1hbnkgbW9kdWxlcyBpbiBSRkMuICBJZiBub3QsIApT
aG91bGQganVzdCBzdG9wIGRvaW5nIHlhbmcgbW9kdWxlcyBpbiBpZXRmIC0gaWYgd2UgZG9uJ3Qg
cHVibGlzaCB0aGVtIGFzIFJGQ3MuIERlY2xhcmUgdmljdG9yeSBvbiBwcm90b2NvbHMgYW5kIGVu
Y29kaW5nczsgaXQnZCBoYXBwZW4gZWxzZXdoZXJlIGlmIHdlIGRpZG4ndC4KVGltZWxpbmVzICh3
aGVyZSB3ZSBzaG91bGQgc3BlbmQgb3VyIHJlc291cmNlcyk6CiAgLSBzY2hlbWEgbW91bnQgZG93
biBhcyBmYXN0IGFzIHBvc3NpYmxlLiAKICAtIE5lZWQgc29sdXRpb24gYnkgdGhlIG5leHQgSUVU
Ri4gICh0aGlzIGlzIDJuZCBoaWdoZXN0IHByaW9yaXR5KQogIC0gTXVzdCBhbHNvIHByb2dyZXNz
IGlldGYgcnRnIG1vZHVsZS4gIDQwIGRpZmZlcmVudCBtb2R1bGVzIGRlcGVuZGluZyBvbiB0aGF0
LgogIC0gUHJvZ3Jlc3MgYWxsIHlhbmcgbW9kZWxzIHRoYXQgZG8gbm90IGRlcGVuZCBvbiBtb3Vu
dC4gClEmQSBmb3IgQmVub2l0OgpSb2IgU2hha2lyOiBQdXNoIG91dCBhbGwgdGhvc2UgUkZDcy4g
IEZyb20gdXNlciBwZXJzcGVjdGl2ZSwgZG8gdGhleSB3b3JrIHRvZ2V0aGVyPyAgV2UgbmVlZCB0
byBiZSBhYmxlIHRvIGludGVyYWN0IGFuZCBjb25maWd1cmUgdGhpbmdzLiAgV291bGQgYmUgaGFw
cGllciB3aXRoIGEgZmV3IFJGQ3MgdGhhdCB3b3JrIHRvZ2V0aGVyLgpCZW5vaXQgQ2xhaXNlOiBD
aGFuZ2VkIHByb2NlZHVyZSB3aXRoIHlhbmcgZG9jdG9ycy4gIEFza2luZyBhbGwgY2hhaXJzIGlu
IGlldGYgdG8gcHJvYWN0aXZlbHkgcmV2aWV3IG1vZHVsZXM7IHNob3VsZCBiZSB3b3JraW5nIHRv
Z2V0aGVyLiAgUHJpbWFyeSBwbGFjZSB0aGlzIG5lZWRzIHRvIGJlIGZpeGVkIGlzIHJvdXRpbmcu
ICBUaGF0J3Mgd2hhdCB0aGUgUlQgZGVzaWduIHRlYW0gaXMgZm9yLiAgRmluZCBpdCB1bmxpa2Vs
eSB3ZSdsbCBoYXZlIHBlcmZlY3QgZGF0YSBtb2RlbHMgb24gZGF5IDEuICBNdXN0IHRoaW5rIGFi
b3V0IGhvdyB3ZSBpdGVyYXRlIHRoZSBtb2RlbHMuClJvYiBTaGFraXI6IG5lZWQgdG8gZm9jdXMg
b24gdmVyc2lvbmluZyBhbmQgaG93IHRoaW5ncyB3b3JrIHRvZ2V0aGVyIChlLmcuIG1vZGVsLWNh
dGFsb2cpLiAgRnJvbSBPQyBtb2R1bGVzLCB3ZSdyZSBhYm91dCB0byBoaXQgdjMuICBNYWtpbmcg
YmFja3dhcmQgKmluKmNvbXBhdGlibGUgaXNzdWVzIG9uIGEgcmVndWxhciBiYXNpcy4KQmVub2l0
IENsYWlzZTogV2UndmUgYmVlbiByZWNlaXZpbmcgeWFuZyBtb2R1bGVzIGZyb20gb3RoZXIgcGxh
Y2VzLgpNaWNoYWVsIEFicmFoYW1zc29uOiBUcnlpbmcgdG8gcmVjb25jaWxlIGFtb25nIDQgdmVu
ZG9ycyB3aGF0IHRoZSBjb21tb24gZWxlbWVudHMgYXJlIHRvIGdvIGludG8gYSBtb2RlbC4gIEFz
IGEgdmVuZG9yIHdhbnQgdG8gc3RhbmRhcmQgbW9kZWxzIHRoYXQgY2FuIG1hcCB0byBtYW55IHZl
bmRvcnMgZXF1aXBtZW50LgpMb3UgQmVyZ2VyOiBJbXBvcnRhbnQgYW5kIGhlbHBmdWwgZm9yIHVz
ZXJzIHRvIHN0YW5kIHVwIHRvIHNheSB3aGF0IGJlbG9uZ3MgaW4gdGhlIG1vZGVsLgpEZWFuIEJv
Z2Rhbm92aWM6IFdlIHNob3VsZCBiZSBjbGFzc2lmeWluZyBtb2R1bGVzIGFuZCBub3QgbW9kZWxz
LiAgQ2FuIGJlIGNsYXNzaWZpZWQgbWFueSBkaWZmZXJlbnQgd2F5cyBpbiBtb2RlbHMuICBJZiB3
ZSBmb2N1cyBvbiBtb2R1bGVzLCBpdCdsbCBiZSBjbGVhcmVyLgpBbmR5IEJpZXJtYW46IFdyb3Rl
IGEgeWFuZyBjb25mb3JtYW5jZSBkb2N1bWVudC4gIFVuaXQgb2YgY29uZm9ybWFuY2Ugb2YgYSBt
b2R1bGUgaXNuJ3QgdGhhdCB1c2VmdWwuICBXYW50IHRvIGlkZW50aWZ5IG1vZHVsZXMgdGhhdCB3
b3JrIHRvZ2V0aGVyLiBOZWVkIHRvIHJldGhpbmsgcmF0aGVyIC4uLiBjb25mb3JtYW5jZSBtb2Rl
bCBpbiB5YW5nPyAgRXNwZWNpYWxseSB3aGVuIHdlJ3JlIG5vdCBmb2xsb3dpbmcgdGhlIHJ1bGVz
LiAgSGlzIGNvbmNlcHQgb2YgeWFuZyBwYWtjYWdlcyBvZiB0aGluZ3Mga25vd24gdG8gd29yayB0
b2dldGhlci4gIFRodXMgeW91IGNhbiBtb3ZlIHRvIHRoaW5ncyB0aGF0IG5lZWQgdG8gY2hhbmdl
IGFsbCB0b2dldGhlci4KTGFkaXNsYXYgTGhvdGthOiBCZWVuIHB1c2hpbmcgcHJvZ3Jlc3MgaW4g
cnRnIG1vZHVsZXMgZm9yIGEgd2hpbGUuICBOb3cgdGhhdCB5YW5nIDEuMSBpcyBsb29taW5nLCBk
byB3ZSB3YW50IHRvIGNoYW5nZSBleGlzdGluZyBtb2R1bGVzIHRvIGNvbmZvcm0gdG8gMS4xLCBv
ciBkbyB3ZSBzdGljayB3aXRoIDEuMCBmb3IgdGhlc2UgbW9kdWxlcz8KQmVub2l0IENsYWlzZTog
V2hhdCBkbyBvcGVyYXRvcnMgaW4gcm9vbSB0aGluaz8KRGVhbiBCb2dkYW5vdmljOiBMYXN0IHRp
bWUgd2UgZGlzY3Vzc2VkIHRoaXMgYW5kIGFncmVlZCB0aGF0IGRyYWZ0cyBub3QgaW4gcHViIHF1
ZXVlIHNob3VsZCBtb3ZlIHRvIDEuMQpCZW5vaXQgQ2xhaXNlOiBUaGlzIGlzIHdoYXQgSSByZW1l
bWJlciBhcyB3ZWxsLgpMYWRpc2xhdiBMaG90a2E6IElmIHdlJ3JlIHRyeWluZyB0byBwdWJsaXNo
IHN0dWZmIGFzYXAsIHRoZW4gbW92aW5nIHRvIDEuMSBtYXkgZnVydGhlciBkZWxheSB0aGluZ3Mu
CkJlbm9pdCBDbGFpc2U6IGNvbmZ1c2VkLCBiZWNhdXNlIEkgdGhvdWdodCB3ZSBkaXNjdXNzZWQg
dGhpcyAKTG91IEJlcmdlcjogRXhwZWN0ZWQgeW91IChCQykgdG8gc2F5IHRoYXQgd2UgdG9vayB0
aGlzIGRlY2lzaW9uIGJlZm9yZSBhbmQgdGhhdCBZQU5HIGRvY3RvcnMgd2lsbCBlbmZvcmNlIGl0
IChhbGwgWUFORyBtb2R1bGVzIHRvIG5vdyBiZSAxLjEpCkJlbm9pdCBDbGFpc2U6IFRob3VnaHQg
dGhpcyB3YXMgYWxyZWFkeSBkZWNpZGVkLgpMYWRpc2xhdiBMaG90a2E6IEV4cGVjdCBtb3Zpbmcg
dG8gMS4xIHdpbGwgbGlrZWx5IGJyZWFrIHRoZSBjaGVja2luZyB0b29scyB3ZSBoYXZlIGRlcGxv
eWVkLgpCZW5vaXQgQ2xhaXNlOiBmaXJzdCwgd2UgYWxyZWFkeSBjaGVjayAxLjEuICBJZiB0aGVy
ZSdzIGEgdG9vbGluZyBpc3N1ZSwgdGhhdCdzIGEgZGlmZmVyZW50IGlzc3VlIHRoYW4gdGhlIG1v
ZHVsZXMKTGFkaXNsYXYgTGhvdGthOiBDb25jbHVzaW9uIGdvIGZvciAxLjEuCkFuZHkgQmllcm1h
bjogV2UgcHJldmlvdXNseSBzYWlkIHdlIHdvdWxkbid0IHVwZ3JhZGUgbW9kdWxlLCBqdXN0IHRo
ZSB2ZXJzaW9uLiAgTGFkYSBpcyBhc2tpbmcgYWJvdXQgMS4xIGxhbmd1YWdlIGZlYXR1cmVzLiAg
V2UncmUga2VlcGluZyB5YW5nIDEuMCBhcyBjdXJyZW50IFJGQy4gKDYwMjBiaXMgZG9lc24ndCBv
YnNvbGV0ZSA2MDIwKQpCZW5vaXQgQ2xhaXNlOiBsZXQncyBjaGVjayB0aGUgbWludXRlcyBmcm9t
IDk1CkFuZHkgQmllcm1hbjogc291bmRzIG5ldyB0byBtZS4uLgpSb2IgU2hha2lyOiBzb3VuZHMg
bGlrZSBhIHRvb2xpbmcgaXNzdWUsIGFncmVlcyB3aXRoIEFuZHkKQmVub2l0IENsYWlzZTogaG93
IGRvZXMgdGhpcyBpbXBhY3QgeW91ciB0b29saW5nPwpSb2IgU2hha2lyOiB0aGVyZSBpcyBhbiBp
bXBhY3QgdG8gZGV2ZWxvcGluZyBhIDEuMSBpbmdlc3QgdG9vbApMb3UgQmVyZ2VyOiBTaG91bGQg
aGF2ZSBzb21lIG9mZiBhbmQgb24tbGlzdCBkaXNjdXNzaW9uIGFib3V0IHRoaXMgYW5kIHNwZWNp
ZmljYWxseSBpbmNsdWRlIHRoZSB5YW5nIGRvY3RvcnMuCkJlbm9pdCBDbGFpc2U6IEkgd2FudCB0
aGUgZ3VpZGVsaW5lcyAqdG9kYXkqLgpMb3UgQmVyZ2VyOiBGcm9tIHRoZSBjaGVja2luZyB0b29s
IHN0YW5kcG9pbnQsIHNob3VsZCBiZSBlYXN5IHRvIHVwZ3JhZGUgdGhlIG1vZHVsZXMsIGlzc3Vl
IGlzIGJyZWFraW5nIHRoZSB0b29scy4KQmVub2l0IENsYWlzZTogSWYgSSdtIG5vdCB1c2luZyAx
LjEgZmVhdHVyZXMsIGRvIEkgbmVlZCB0byBidW1wIHRoZSB2ZXJzaW9uPwpMYWRpc2xhdiBMaG90
a2E6IE9uZSBvZiB0aGUgdGhpbmdzIHRoYXQgc2hvdWxkIGJlIGFkZGVkL2NoYW5nZWQgaXMgdGhl
IHVzZSBvZiB4cGF0aC4gUmlnaHQgbm93IHdlIHV0aWxpemUgdGhlIHRleHR1YWwgY29tcGFyaXNv
biBpbiB4cGF0aC4gIElmIHdlIHByb3ZpZGUgY2hhbmdlcywgd2UgbWF5IGJyZWFrIHRoaW5ncy4g
CkxvdSBCZXJnZXI6IEFzayB1c2VycyBvZiBtb2RlbHM6IChjdXN0b21lcnMpIFdobyBvYmplY3Rz
IHRvIHlhbmcgMS4xPyAuLi4gaG93IG1hbnkgcGVvcGxlIGRpZG4ndCB1bmRlcnN0YW5kIHF1ZXN0
aW9uPwpDaHJpcyBIb3BwczogVGhlIHByb2JsZW0gd2l0aCB0aGUgcXVlc3Rpb24gaXMsIHdoYXQg
ZG9lcyB0aGlzIGltcGx5PyAgV2hhdGV2ZXIgZ2V0cyBpdCBvdXQgdGhlcmUgdGhlIGZhc3Rlc3Qg
aXMgaW1wb3J0YW50LgpEZWFuIEJvZ2Rhbm92aWM6IElzIHRoZSByZXF1aXJlbWVudCB0byBtb3Zl
IGV2ZXJ5dGhpbmcgdG8gMS4xLCBvciBpcyB0aGVyZSBhIGNob2ljZT8KTG91IEJlcmdlcjogUmVx
dWlyZW1lbnQgdG8gMS4xIGV2ZW4gaWYgeW91IGRpZG4ndCBuZWVkIHRoaXMgYXMgYSBmZWF0dXJl
LgpBbmR5IEJpZXJtYW46IERvIHlvdSB0aGluayB5b3UncmUgZ29pbmcgdG8gZ2V0IG1vcmUgbWF0
dXJlIHRvb2xzIGZyb20gcmZjIHRoYXQncyBiZWVuIG91dCBmb3IgNCB5ZWFycyBvciBzb21ldGhp
bmcgaW4gSS1EIHN0YXRlPyAgVGhlcmUgYXJlIHBsZW50eSBvZiB0aGluZ3MgdGhhdCBhcmUgaW4g
MS4xIHlvdSBzaG91bGRuJ3QgYmFyZiBvbi4KTG91IEJlcmdlcjogVmVuZG9ycywgU2FtZSBxdWVz
dGlvbiAod2hvIG9iamVjdHMgdG8gdG8geWFuZyAxLjE/KQpEZWFuIEJvZ2Rhbm92aWM6IElmIHlv
dSBoYXZlIHNvbWV0aGluZyBhbHJlYWR5IGltcGxlbWVudCB0byAxLjAsIGxlYXZlIGl0IHRvIDEu
MC4gIEluIHlvY3RhIGRyYWZ0LCBIYWQgdG8gbW92ZSBvbmUgdGhpbmcgYmVjYXVzZSBpdCBuZWVk
ZWQgMS4xLiAgSW4gdGhhdCBjYXNlIGl0IG1hZGUgc2Vuc2UuClJvYiBTaGFraXI6IENhbiB5b3Ug
YXNrIGhvdyBtYW55IHBlb3BsZSBhcmUgaW1wbGVtZW50aW5nIChsb3Qgb2YgaGFuZHMgcmFpc2Vk
Li4uKQpMb3UgQmVyZ2VyOiBUaGlua3MgRGVhbiBoYXMgYSBnb29kIHdheSBmb3J3YXJkLCBpZiB5
b3UgaHZlIGEgbW9kZWwgdGhhdCBuZWVkcyAxLjEgZmVhdHVyZSwgZ28gYWhlYWQgYW4gdXNlIGl0
LiAgQWxzbyBvayB0byBzdGF5IGFuZCAxLjAuIApLZW50IFdhdHNlbjogQWxzbyBBbmR5J3MgcG9p
bnQgYXMgd2VsbC4KTG91IEJlcmdlcjogc2VlIGEgbm9kIG9mICJ5ZXMiIGZyb20gQUQKVmxhZGlt
aXIgVmFzc2lsZXY6IDEuMSB0byAxLjIsIHdpbGwgYmUgc2FtZSBxdWVzdGlvbj8KTG91IEJlcmdl
cjogV2UgaGF2ZSB0aGF0IGlzc3VlIHdoZW5ldmVyIHdlIHJldiB0ZWNocy4KS2VudCBXYXRzZW46
IElmIHRoZXJlJ3MgYSBmZWF0dXJlIGluIDEuMiB5b3Ugd2FudCB0byB1c2UsIGdvIGZvciBpdC4g
T3RoZXJ3aXNlIHlvdSdkIHN0YXkgYXQgd2hhdGV2ZXIgdGhlIGN1cnJlbnQgZHJhZnQgaGFzLgpK
dWVyZ2VuIFNjaG9lbndhZWxkZXI6IFdvdWxkIGxpa2UgdG8gYWRkIHRoYXQgeWFuZyBkb2N0b3Jz
IHNob3VsZCBwdXNoICBtb2R1bGVzIHRvIHRha2UgYWR2YW50YWdlIG9mIFlBTkcgMS4xIGZlYXR1
cmVzLCBpZiB0aGV5IHNlZSBhIHlhbmcgbW9kdWxlIHRoYXQgd291bGQgYmVuZWZpdCBmcm9tIDEu
MS4KUGhpbCBTaGFmZXI6IElmIHlvdSBoYXZlIGltcG9ydGFudCBtb2R1bGVzIHRoYXQgdXNlIDEu
MCwgYW5kIHlvdSBoYXZlIHRvIHN1cHBvcnQgaXQsIGNoYW5nZXMgd2lsbCBmb3JjZSB5b3UgdG8g
Y2FzY2FkZSB5b3VyIHVwZ3JhZGVzLgpLZW50IFdhdHNlbjogc28gdGhlIG5lZWQgdG8gdXBkYXRl
IHRvIDEuMSB3aWxsIHF1aWNrbHkgY2FzY2FkZSwgZ29vZCBwb2ludC4KCgoKICAgKiAgNSBNaW46
ICMxIE9wU3RhdGUgZGlyZWN0aW9uIHJlY2FwICAgICAgICAgICAgICAgICAgICAgICAgIChDaGFp
cnMpCiAgICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xp
ZGVzL3NsaWRlcy05Ni1uZXRtb2QtMS5wcHR4CiAgICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1uZXRtb2QtMS5wZGYKCkxvdSBC
ZXJnZXI6IGFzc3VtcHRpb24gdGhhdCBtb2R1bGVzIHdpbGwgYWRvcHQgdGhlIDcyMjMgYXBwcm9h
Y2ggKGUuZy4gaW50ZXJmYWNlcy1zdGF0ZSkuICBJZiB0aGF0J3Mgbm90IHRoZSBjYXNlLCBwbGVh
c2UgYnJpbmcgaXQgdXAgb24gdGhlIGxpc3QKQmVub2l0IENsYWlzZTogV2Ugc2hvdWxkIG5vdCBs
ZWF2ZSByb29tIHVudGlsIHdlIGhhdmUgYWdyZWVtZW50IHdoZXJlIHRvIHB1dCB0aGUgY291bnRl
cnMuCkxvdSBCZXJnZXI6IFdvdWxkIGxpa2UgdG8gbW92ZSA2OTg3YmlzIHRvIGxhc3QgY2FsbC4g
QmVsaWV2ZSBpdCByZWZsZWN0cyBjb25zZW5zdXMuICBEb2VzIGFueW9uZSBiZWxpZXZlIHRoYXQg
NjA4N2JpcyBkb2VzIG5vdCByZWZsZWN0IHRoZWlyIHBvc2l0aW9uPwpDaHJpcyBIb3BwczogVGhp
cyBzZWVtcyBzZXZlcmUsIHRoYXQgd2UgY2FuJ3QgbGVhdmUgdGhlIHJvb20gdW50aWwgdGhpcyBp
cyBzZXR0bGVkLiAgRG9uJ3QgdGhpbmsgdGhpcyBzaG91bGQgYmUgYSBibG9ja2VyLiAgTW9kdWxl
IGNvbnN1bWVycyBjYW4gZGV0ZXJtaW5lIGhvdyB0byBjb25zdW1lIGVhY2ggbW9kdWxlIGJhc2Vk
IG9uIGl0cyBkb2N1bWVudGF0aW9uLCBubyBzZXQgcnVsZSBpcyBuZWVkZWQuICBUaGluayB3ZSdy
ZSByZWFkeSB0byBtb3ZlIGZvcndhcmQgKHN0YW5kYXJkaXplIG1vZGVscyBpbiB0aGUgSUVURikv
IGNvbnRpbnVlIHRvIHdvcmsgb24gdGhpbmdzIGluIElFVEYuCkxvdSBCZXJnZXI6IERvbid0IHdh
bnQgdG8gZW5mb3JjZSB0aGlzOyBsZWF2ZSBpdCBhcyBhIGNvbnZlbnRpb24sIGFuZCBjb252ZW50
aW9ucyBjYW4gYmUgYnJva2VuCkNocmlzIEhvcHBzOiBZZXMuCkxvdSBCZXJnZXI6IG5vdGUgdGhl
IHRleHQgc2F5cyAiU0hPVUxEIiwgc28gaXQgaXMganVzdCBhIHJlY29tbWVuZGF0aW9uClJvYiBT
aGFraXI6IFdoZXJlIHN0YXRlIGlzIGxvY2F0ZWQgaXMgaW1wb3J0YW50LiAgSWYgbW9kZWxzIGFy
ZSBzcHJpbmtsZWQgdGhyb3VnaG91dCBtb2RlbCwgaXQncyBhbiBpc3N1ZSBmb3IgcGVvcGxlIGFj
Y2Vzc2luZyBpdC4gRm9yIHRoZSByZWNvcmQsIGRvbid0IHRoaW5rIHRoaXMgaXMgdGhlIHJpZ2h0
IGRlY2lzaW9uLiBXZSd2ZSBiZWVuIHdvcmtpbmcgb24gdGhpcyBmb3IgMTggbW9udGhzLiBXZSBo
YXZlIHJ1bm5pbmcgY29kZS4gIEJhY2sgaW4gRGFsbGFzLCB3ZSdsbCBsZXQgeW91IGtub3cgaG93
IGl0IGdvZXMuIEkgdGhpbmsgdGhpcyBpcyBhIHByZW1hdHVyZSBkZWNpc2lvbi4KTG91IEJlcmdl
cjogT2JqZWN0aW5nIHRvIGRpcmVjdGlvbiBmcm9tIGFwcGxpZWQgdnMuIGludGVuZGVkLgpSb2Ig
U2hha2lyOiBBIGJhZCBkZWNpc2lvbiB3b3VsZCBiZSB0byBnaXZlIG5vIGd1aWRhbmNlLgpSb2Ig
V2lsc29uOiAuLi4gSXMgaXQgd29ydGggYXNraW5nIHRoaXMgcXVlc3Rpb24gYWdhaW4gYWZ0ZXIg
d2Ugc2VlIHRoZSBzb2x1dGlvbiBwcmVzZW50YXRpb25zPwpMb3UgQmVyZ2VyOiBva2F5CgoKCiAg
ICogMTAgTWluOiAjMiBkcmFmdC1pZXRmLWkycnMtZXBoZW1lcmFsLXN0YXRlLTE0ICAgICAgICAg
ICAgICAoU3VzYW4gSGFyZXMpCiAgICAgc2xpZGVzOiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9j
ZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW5ldG1vZC0yLnBwdHgKICAgICBzbGlkZXM6IGh0
dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbmV0bW9k
LTIucGRmCgpTdXNhbiBIYXJlcyBwcmVzZW50aW5nICJZYW5nIEZlYXR1cmUiIHNsaWRlOiBtdXN0
IGJlIGEgd2F5IGZvciB5YW5nIHNjaGVtYSBub2RlcyB0byBiZSBmbGFnZ2VkIGFzIG9ubHkgZm9y
IGVwaGVtZXJhbCBzdGF0ZS4uLgpEZWFuIEJvZ2Rhbm92aWM6IFdyaXRlYWJsZSBvcGVyYXRpb25h
bCBzdGF0ZSBpcyBkYW5nZXJvdXMgdG8gZGFiYmxlIGluLiAgRS5nLiBpbiBPU1BGLiBZb3Ugc2hv
dWxkIG9ubHkgYmUgYWxsb3dlZCB0byB1cGRhdGUgdGhlIHN0YXRlIGZvciBSSUIgZW50cmllcyB0
aGF0IHlvdSBwdXQgaW4gKG5vdCBzdGF0ZSB5b3VyIHBlZXJzIHB1dCBpbiksIG90aGVyd2lzZSB5
b3UnbGwgYmUgaW4gYSBjb25zdGFudCBzdGF0ZSBvZiBjb252ZXJnZW5jZS4KS2VudCBXYXRzZW46
IGxldCdzIG5vdCBkZWJhdGUgSTJSUyByZXF1aXJlbWVudHMgaW4gdGhpcyBtZWV0aW5nLCB0YWtl
IGl0IHRvIHRoZSBJMlJTIGxpc3QuLi4KQW5keSBCaWVybWFuOiBQcm9ibGVtIHdpdGggdGhpcyB3
b3JkaW5nLiAgV2hhdCBkb2VzIHRoaXMgbmV3IHN0YXRlbWVudCBhY3R1YWxseSBkbz8gIFlBTkcg
b25seSBoYXMgY29uZmlnIHRydWUgYW5kIGNvbmZpZyBmYWxzZS4gIFNob3VsZG4ndCB0aGlzIGJl
IG9ubHkgd2l0aCB0aGUgcHJvdG9jb2w/ClN1c2FuIEhhcmVzOiBuZWVkIGEgd2F5IHRvIHNheSBh
IGNlcnRhaW4gbW9kZWwsIG9yIHBhcnRzIG9mIGEgbW9kZWwgYXJlIGVwaGVtZXJhbCBvbmx5LgpK
ZWZmIEhhc3M6IGl0IG5lZWRzIHRvIGJlIHBvc3NpYmxlIHRvIGluZGljYXRlIHRoYXQgc29tZSBj
b25maWc9dHJ1ZSBub2RlcyBhcmUgZXBoZW1lcmFsIHdoaWxlIG90aGVyIGNvbmZpZz10cnVlIG5v
ZGVzIHNob3VsZCBub3QgYmUgYWxsb3dlZCB0byBiZSBlcGhlbWVyYWwuCkxvdSBCZXJnZXI6IFBs
ZWFzZSBlbnN1cmUgdGhhdCB0aGUgcmVxdWlyZW1lbnRzIHRvIE5FVE1PRCBpbmNsdWRlIHRoaXMg
cGhyYXNpbmcgb2YgdGhlIHJlcXVpcmVtZW50IHRoYXQgSmVmZiBqdXN0IGFydGljdWxhdGVkLgpT
dXNhbiBIYXJlczogSGF2ZSBzb2xpY2l0ZWQgZmVlZGJhY2sgbXVsdGlwbGUgdGltZXMgZnJvbSB5
YW5nIGRvY3RvcnMgdG8gYXJyaXZlIGF0IHRoZSB0ZXh0IHdlIGhhdmUuICBGcnVzdHJhdGluZyB0
aGF0IHRoaXMgdGV4dCBpc24ndCBjbGVhciB0byB0aGlzIGdyb3VwLiAgUGxlYXNlIGVuc3VyZSB0
aGF0IGFueSB1cGRhdGUgdG8gdGhpcyB0ZXh0IGlzIHJldmlld2VkIGJ5IGFsbCBhbmQgb25seSBv
bmUgYW5zd2VyIGlzIHByb3ZpZGVkLgoKCgogICAqIDE1IE1pbjogIzMgZHJhZnQtc2Nob2Vudy1u
ZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLTAxICAgICAgKEp1ZXJnZW4gU2Nob2Vud2FlbGRlcikK
ICAgICBzbGlkZXM6IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9z
bGlkZXMtOTYtbmV0bW9kLTMucHB0eAogICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcv
cHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1uZXRtb2QtMy5wZGYKCkp1ZXJnZW4gU2No
b2Vud2FlbGRlciBwcmVzZW50aW5nOiBuZWVkIG1vcmUgYXJjaGl0ZWNldHVyYWwgZ3VpZGFuY2Uu
ICBEYXRhc3RvcmVzIGFyZSBzdWNoIGEgZnVuZGFtZW50YWwgY29uY2VwdC4gIE5lZWQgc2VwYXJh
dGlvbiBiZXR3ZWVuIGNvbmNlcHR1YWwgbW9kZWwgYW5kIHdoYXQgcHJvdG9jb2xzIGRvLgpEZWFu
IEJvZ2Rhbm92aWM6IGRvIHdlIGFsbCBhZ3JlZSBvbiB0aGUgZGVmaW5pdGlvbnMgYW5kIGRpZmZl
cmVuY2VzIGJldHdlZW4gaW50ZW5kZWQgYW5kIGFwcGxpZWQgIC0gTG91OiB5ZXMsIEp1ZXJnZW46
IG5vIDspCkNocmlzIEhvcHBzOiBpcyB0aGUgaXNzdWUgd2l0aCB0aGUgZGVmaW5pdGlvbiBvZiBp
bnRlbmRlZCB2cyBhcHBsaWVkPwpKdWVyZ2VuIFNjaG9lbndhZWxkZXI6IG5vIHRoZSBpc3N1ZSBj
b21lcyBtdWNoIGVhcmxpZXIgaW4gdGhlIGRlZmluaXRpb24gb2YgY29uZmlndXJhdGlvbgpMb3Ug
QmVyZ2VyOiB3b3VsZCBiZSB3b3J0aHdoaWxlIHRvIHVuZGVyc3RhbmQgYmV0dGVyIHlvdXIgcHJv
cG9zYWwKTWVobWV0IEVyc3VlOiBhcyBuZXRjb25mIGNvLWNoYWlyLCBhZ3JlZSB3aXRoIEp1ZXJn
ZW4gdGhhdCB0aGUgb3BzdGF0ZSBzb2x1dGlvbiBpcyBhIGZ1bmRhbWVudGFsIGFyY2ggY29uY2Vw
dC4gIFdvdWxkIGxpa2UgdGhlIGRhdGFzdG9yZSBkaXNjdXNzaW9uIHRvIG1vdmUgdG8gTkVUQ09O
RiBXRwpCZW5vaXQgQ2xhaXNlOiB5ZXMsIHRoZXJlIGlzIE5FVENPTkYgaW1wYWN0LCBidXQgZG9u
J3QgY2FyZSB3aGVyZSBpdCBoYXBwZW5zLCBhcyB0aGUgc2FtZSBwZW9wbGUgYXJlIGdvaW5nIHRv
IHdvcmsgb24gaXQuCkJhbGF6cyBMZW5neWVsOiBpbnRlcmZhY2VzL2ludGVyZmFjZXMtc3RhdGUg
cmVzb2x1dGlvbiBtdWNoIG1vcmUgaW1wb3J0YW50IHRoYW4gdGhlIGludGVuZGVkL2FwcGxpZWQg
cmVzb2x1dGlvbi4gIEVuYWJsaW5nIG9wZXJhdGlvbmFsIERTIHRvIGhhdmUgc2FtZSBzdHJ1Y3R1
cmUgYXMgcnVubmluZyBkYXRhc3RvcmUgZ3JlYXRseSBzaW1wbGlmaWVzIHRoaW5nczsgc3VwcG9y
dHMgZGF0YXN0b3JlIGJhc2VkIGFwcHJvYWNoZXMgb3ZlciBicmFuY2hlcy4KRXJpYyBWb2l0OiBp
cyBBQ0wgY29uZmlnIG9yIG9wc3RhdGUgd2hlbiA4MDIuMXgoPykgaXMgaW4gcGxheT8KSnVlcmdl
biBTY2hvZW53YWVsZGVyOiBJIGJlbGlldmUgdGhhdCBBQ0xzIGNhbiBjb21lIGZyb20gbXVsdGlw
bGUgc291cmNlcy4KRXJpYyBWb2l0OiBzbyB0aGV5IGNvdWxkIGJlIG9wZXJhdGlvbmFsIHN0YXRl
PyAgKEp1ZXJnZW4gbm9kcykKTm9ybSBTdHJhaGxlOiBXaGF0IGFib3V0IENMSSwgaXMgaXQgY292
ZXJlZCBieSBpbnRlbmRlZD8KSnVlcmdlbiBTY2hvZW53YWVsZGVyOiBJZGVhbGx5IGFsbCBhY2Nl
c3MgbWVjaGFuaXNtcyAoTkVUQ09ORiwgQ0xJLCBldGMuKSwgdHlwaWNhbGx5IENMSSBpcyBpbnRl
Z3JhdGVkIApTdXNhbiBIYXJlczogQkdQIHBhc3NlcyBjb250cm9sIHN0YXRlIGFzIHBhcnQgb2Yg
aXRzIHByb3RvY29sLCBpcyBpdCBjb250cm9sIHN0YXRlIG9yIG9wZXJhdGlvbmFsIHN0YXRlPwpK
dWVyZ2VuIFNjaG9lbndhZWxkZXI6IEkgYmVsaWV2ZSB0aGF0IGl0IHdvdWxkIHRhcmdldCB0aGUg
b3BlcmF0aW9uYWwgc3RhdGUgZGF0YXN0b3JlLgogICAgCgoKICAgKiAxMCBNaW46ICM0IGRyYWZ0
LXdpbHRvbi1uZXRtb2QtcmVmaW5lZC1kYXRhc3RvcmVzLTAxICAgICAgIChSb2JlcnQgV2lsdG9u
KQogICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVz
L3NsaWRlcy05Ni1uZXRtb2QtNC5wcHR4CiAgICAgc2xpZGVzOiBodHRwczovL3d3dy5pZXRmLm9y
Zy9wcm9jZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW5ldG1vZC00LnBkZgoKUm9iZXJ0IFdp
bHRvbiBwcmVzZW50aW5nOgpEZWFuIEJvZ2Rhbm92aWM6IHdoZW4gZG8gSSBnZXQgY29uZmlybWF0
aW9uIHRoYXQgbWlnaHQgY29tbWl0IHdhcyBhcHBsaWVkPwpSb2JlcnQgV2lsdG9uOiB3aXRoIGN1
cnJlbnQgbW9kZWwsIGl0J3Mgbm90IGRlZmluZWQKS2VudCBXYXRzZW46IG9wc3RhdGUtcmVxcyBk
ZWZpbmVkIGEvc3luY2ggY29uZmlnIG9wZXJhdGlvbnMKTGFkaXNsYXYgTGhvdGthOiBXaGVyZSB3
b3VsZCBhY3R1YWwgTVRVIGJlIHJlcHJlc2VudGVkIChzbGlkZSA3KQpSb2JlcnQgV2lsdG9uOiBJ
biBhIG1vZGVsIGRlZmluZWQgY29uZmlnIGZhbHNlIG5vZGUKTGFkaXNsYXYgTGhvdGthOiBhbiBl
eHRyYSBkYXRhIG5vZGUKUm9iZXJ0IFdpbHRvbjogeWVzLCBmb3IgdGhlIHNwZWNpZmljIGNhc2Ug
b24gTVRVCkFuZHkgQmllcm1hbjogU2VlbXMgY29tcGxpY2F0ZWQgaW50ZXJhY3Rpb24gbW9kZWwg
dG8ganVzdCBpbmRpY2F0ZSBzaW5nbGUgYml0IChpcyB0aGUgbGVhZiBhcHBsaWVkKS4gIEFyZSB0
aGVyZSBtb3JlIHVzZS1jYXNlcyBiZWNhdXNlLCBhbHRlcm5hdGVseSwgSSBjb3VsZCBqdXN0IGFz
ayB0aGUgYm94IGlmIGl0J3MgYXBwbGllZCB5ZXQuICBJcyB0aGVyZSBtb3JlIHVzZS1jYXNlcyB0
aGFuIGp1c3QgdGhpcz8KUm9iZXJ0IFdpbHRvbjogbm8gSSBkb24ndCB0aGluayBzbyBbRURJVE9S
OiBub3QgdHJ1ZSwgdGVsZW1ldHJ5IG5lZWRzIHRoaXMgdG9dCkRlYW4gQm9nZGFub3ZpYzogd291
bGQgbGlrZSB0byB1bmRlcnN0YW5kIGhvdyB0byBtYXAgdGhlIGNvbW1pdCBwcm9jZXNzIGluIHRo
ZSBwcm90b2NvbCBjb250ZXh0ClZsYWRpbWlyIFZhc3NpbGV2OiBjb25jdXIgd2l0aCBBbmR5LiAg
SXQncyBzb2x2aW5nIGEgdmVyeSBuYXJyb3cgcHJvYmxlbS4gIFRpbWUgdG8gY29tbWl0IGlzIG9u
ZSB0aGluZywgYnV0LCBmb3IgZXhhbXBsZSwgTlRQIG1heSB0YWtlIHRpbWUgdG8gcmVzb2x2ZS4g
IFRoaXMgc2VlbXMgbGlrZSBhIGxvdCBvZiBjb21wbGljYXRpb24sIE5FVENPTkYvWUFORyB1c2Vk
IHRvIGJlIHNpbXBsZSwgbm93IGdldHRpbmcgc2NhcnkKUm9iZXJ0IFdpbHRvbjogQXBwbGllZCBj
b25maWd1cmF0aW9uIGlzIGludGVuZGVkIHRvIHRlbGwgYW4gb3BlcmF0b3IgZXhhY3RseSB3aGVh
dCB0aGUgc3lzdGVtIGlzIGRvaW5nLCBhcyBvcHBvc2VkIHRvIHRvZGF5IHdoZXJlIGl0J3Mgbm90
IGNsZWFyClJvYiBTaGFraXI6IGEgc3Vic2NyaXB0aW9uIHN5c3RlbSBpcyBtb3JlIGxpa2VseSB0
byBqdXN0IHN1YnNjcmliZSB0byB0aGUgYXBwbGllZCBpbmZvcm1hdGlvbiwgc28gaXMgbW9yZSB0
aGFuIGp1c3Qgb25lIGJpdCBbRURJVE9SOiB5ZXMsIHNlZSBjb21tZW50IGFib3ZlXQpTdXNhbiBI
YXJlczogc2FtZSBxIEkgYXNrZWQgSnVlcmdlbiwgYXNzdW1lIHRoYXQgdGhlcmUgaXMgYW4gQUNM
IHRoYXQgaXMgY29uZmlndXJlZCwgYW5kIEJHUCBmbG93IHN0YXRlLCBob3cgZG8gdGhleSBpbnRl
cmFjdCBpbiB5b3VyIHNvbHV0aW9uPwpSb2JlcnQgV2lsdG9uOiBwcm9iYWJseSBzYW1lIGFuc3dl
ciBhcyBKdWVyZ2VuJ3MgKGkuZS4gQkdQIGlzIG9wZXJhdGlvbmFsIHN0YXRlKQpFcmljIFZvaXQ6
IHNhbWUgcXVlc3Rpb24gYWJvdXQgQUNMIGFuZCA4MDIuMXgKUm9iZXJ0IFdpbHRvbjogc2FtZSBh
bnN3ZXIgYXMgSnVlcmdlbidzClJpY2sgVGF5bG9yOiBzdXJwcmlzZWQgdGhhdCBvcHN0YXRlIGRh
dGFzdG9yZSBkaWRuJ3QgYWxyZWFkeSBleGlzdCwgc28gdGhpcyB3b3JrIGlzIGxvbmcgb3ZlcmR1
ZSAKQ2hyaXMgSG9wcHM6IGRpYWdyYW0gbG9va3MgY29tcGxleCBvbmx5IGJlY2F1c2UgaXQgaXMg
YSBjb21wbGV4IHRvcGljLCBidXQgd2hlbiB0aGlua2luZyBhYm91dCBpbXBsZW1lbnRhdGlvbiwg
aXQgZG9lc24ndCBzZWVtIHNvIGNvbXBsZXgKCgoKICAgKiAxMCBNaW46ICM1IGRyYWZ0LXdpbHRv
bi1uZXRjb25mLW9wc3RhdGUtbWV0YWRhdGEtMDAgICAgICAgIChSb2JlcnQgV2lsdG9uKQogICAg
IHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRl
cy05Ni1uZXRtb2QtNS5wcHR4CiAgICAgc2xpZGVzOiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9j
ZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW5ldG1vZC01LnBkZgoKRGVhbiBCb2dkYW5vdmlj
OiByZWdhcmRpbmcgdGhlcmUgYmVpbmcgYSB3YXkgdG8gZGVzY3JpYmUgdGhhdCBhIHZhbHVlIGhh
cyBiZWVuIG92ZXJ3cml0dGVuIGJ5IGVwaGVtZXJhbCwgeW91IHdpbGwgaGF2ZSBhIHByb2JsZW0g
dGhlcmUgd2l0aCBsYXdmdWwgaW50ZXJjZXB0ClJvYmVydCBXaWx0b246IGxldCdzIGRpc2N1c3Mg
b2ZmbGluZQpEZWFuIEJvZ2Rhbm92aWM6IC0tIDxubyB0aW1lIGZvciBxdWVzdGlvbnMgLS0gdG8g
bGlzdCBvciBXZWQgZGlzY3Vzc2lvbi4+CgoKCiAgICogMjAgTWluOiAjNiBPcGVuIGRpc2N1c3Np
b24gb24gcmV2aXNlZCBkYXRhc3RvcmVzICAgICAgICAgICAoT3BlbiBNaWMpCiAgICAgc2xpZGVz
OiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW5l
dG1vZC02LnBwdHgKICAgICBzbGlkZXM6IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdz
Lzk2L3NsaWRlcy9zbGlkZXMtOTYtbmV0bW9kLTYucGRmCgpDaGFpcnM6IFRoaXMgYmxvY2sgb2Yg
dGltZSBoYWQgdG8gYmUgY2xpcHBlZCAtIGZvbGtzIHNob3VsZCBjb21lIHRvIFdlZCdzIGJyZWFr
b3V0IG9wc3RhdGUgc2Vzc2lvbgoKCgogICAqIDIwIE1pbjogIzcgZHJhZnQtaWV0Zi1uZXRtb2Qt
c2NoZW1hLW1vdW50LTAyICAgICAgICAgICAgICAgKExhZGlzbGF2IExob3RrYSkKICAgICAgICAg
ICAgICAgICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xp
ZGVzL3NsaWRlcy05Ni1uZXRtb2QtNy5wcHR4CiAgICAgICAgICAgICAgICAgICBzbGlkZXM6IGh0
dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbmV0bW9k
LTcucGRmCgpBbmR5IEJpZXJtYW46IFVzZSBjYXNlIGlzIGEgc2VydmVyIHRoYXQgd2FudHMgdG8g
Y29tcG9zZSBzdHJ1Y3R1cmUgb3V0IG9mIG11bHRpcGxlLiAgRG9uJ3QgdW5kZXJzdGFuZCBob3cg
dGhpcyByZWxhdGVzIHRvIHN0YW5kYXJkcywgb3IgdG8gcm91dGlnLWNmZyBtb2R1bGUKTGFkaXNs
YXYgTGhvdGthOiBpdCdzIHJlbGF0ZWQgYmVjYXVzZSB3ZSBjaGFuZ2VkIHRoZSByb3V0aW5nLWlu
c3RhbmNlcyBhcHByb2FjaCB0byBkZXBlbmQgb24gYSBUQkQgc2NoZW1hLW1vdW50IHNvbHV0aW9u
CkFuZHkgQmllcm1hbjogc2VlbXMgbGlrZSBhIHByZXNlbnRhdGlvbiBpc3N1ZSwgWUFORyB0b29s
cyBkb24ndCBjYXJlLgpMb3UgQmVyZ2VyOiBUaGlzIGlzIHRvIHN1cHBvcnQgdGhlIHNoaWZ0IGlu
IHJvdXRpbmcgYXJlYSBhbmQgaXMgdXNlZCB0byBzdXBwb3J0IGxvZ2ljYWwgbmV0d29yayBlbGVt
ZW50IGFuZCBuZXR3b3JrIGluc3RhbmNlCktlbnQgV2F0c2VuOiB0aGlzIGlzIGludGVuZGVkIHRv
IGJlIHVzZWQgYnkgbW9kdWxlLWRlc2lnbmVycyAodGhpcyBpcyBub3QgdGhlIHNhbWUgYXMgcGVl
ci1tb3VudCkKQ2hyaXMgSG9wcHM6IDxleHBsYWlucyBtb3RpdmF0aW9uIGZyb20gdGhlIHJvdXRp
bmcgRFQgcGVyc3BlY3RpdmU+CkVyaWMgVm9pdDogY2FuIHBlZXItbW91bnQgYmUgYnVpbHQgb24g
dG9wIG9mIHRoaXM/CkxhZGlzbGF2IExob3RrYTogeWVzLCB0aGF0IGlzIHdoYXQgdGhlIHNsaWRl
IHNheXMgKHRoZSAiaXMgdGhpcyB3aGF0IHdlIHdhbnQ/IiBzbGlkZSkKQ2hyaXMgSG9wcHM6IHJl
Z2FyZGluZyAyIHNsaWRlcyBiYWNrLCB3aGF0IGRpZCB5b3UgbWVhbiwgb25seSB1c2VmdWwgYXQg
b24gbGV2ZWw/IApMYWRpc2xhdiBMaG90a2E6IG5vdCBzbyBlYXN5IGZvciByZWN1cnNpdmUgaXNz
dWUgKG5lc3RlZCBWTXMpCkNocmlzIEhvcHBzOiBkb24ndCB1bmRlcnN0YW5kIERTREwgdGhpbmcs
IGRvZXMgaXQgcHJlc3VtZSB5b3Uga25vdyB3aGF0IG1vZGVscyB3aWxsIGJlIHRoZXJlIGJlZm9y
ZWhhbmQKTGFkaXNsYXYgTGhvdGthOiB5ZXMKQ2hyaXMgSG9wcHM6IHRoYXQncyBhIGJpZyBwcm9i
bGVtCkJhbGF6cyBMZW5neWVsOiBuZWVkIGEgd2F5IHRvIGRvIHNjaGVtYS1tb3VudCBpbiBZQU5H
IG1vZHVsZSB1c2luZyBwcm9ncmFtbWF0aWMgc3RhdGVtZW50IChub3QgZGVzY3JpcHRpb24gc3Rh
dGVtZW50KQpBbmR5IEJpZXJtYW46IHJlZ2FyZGluZyB2YWxpZGF0aW9uLCBJIHNlZSBtYW55IGlu
Y29ycmVjdCBtdXN0IGFuZCB3aGVuIHN0YXRlbWVudHMuICBTb3VuZHMgbGlrZSB0aGlzIHdpbGwg
bWFrZSB0aGluZ3MgZXZlbiBoYXJkZXIsIGxlc3MgbGlrZWx5IG1vZGVsIGRlc2lnbmVycyB3aWxs
IGdldCBpdCByaWdodApMYWRpc2xhdiBMaG90a2E6IGkgZG9uJ3QgYmVsaWV2ZSB0aGlzIG1ha2Vz
IGFueXRoaW5nIGhhcmRlcgpDaHJpcyBIb3BwczogcmVnYXJkaW5nIGFueWRhdGEsIGRvZXMgdGhh
dCBtZWFuIGFueXRoaW5nIGdvZXMsIG9yIGlzIGl0IHJlc3RyaWN0ZWQgb3IgYSBmcmVlLWZvci1h
bGwKTG91IEJlcmdlcjogc29ycnksIHdlJ3JlIG92ZXJ0aW1lLCB3ZSBoYXZlIHRvIHRha2UgdGhp
cyBvZmZsaW5lCgoKCgoKClNlc3Npb24gMjooVHVlc2RheSwgMi1ob3VycykKPT09PT09PT09PT09
PT09PT09PT09PT09PT09PQoKCiAgICogIDUgTWluOiAjMCAgSW50cm8gICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgKENoYWlycykKCiAgICogMTAgTWluOiAjOSBSb3V0
aW5nIEFyZWEgRFQgVXBkYXRlICAgICAgICAgICAgICAgICAgICAgICAgICAoQ2hyaXN0aWFuIEhv
cHBzKQogICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xp
ZGVzL3NsaWRlcy05Ni1uZXRtb2QtOS5wZGYKICAgICA8bW92ZWQgZnJvbSBwcmV2aW91cyBzZXNz
aW9uPgoKQ29tbW9uIE5hbWluZyBhbiBpc3N1ZQpTY2hlbWEgbW91bnQgLyBvcHN0YXRlIGRyYWZ0
cyBmb2xsb3dlZC9uZWVkZWQKTmV3IGlkZWEgb2YgdGFnZ2luZyBtb2R1bGVzL2JyYW5jaGVzIGlu
c3RlYWQgb2YgY29udGFpbm1lbnQgaGllcmFyY2hpZXMKTG91IEJlcmdlcjogQ29tbWVudHMgb24g
aGFzaCB0YWcgaWRlYT8KRGVhbiBCb2dkYW5vdmljOiBoYXNodGFncyBtaWdodCBiZWNvbWUgYSBt
ZXNzLiBMaW1pdCB0aGUgbnVtYmVyIG9mIGh0YWdzLiBTbWFsbCBzZXQgb2Ygc3RhbmRhcmQgdGFn
cyArIHJ1bGVzIGZvciBwcml2YXRlIHRhZ3MKQ2hyaXN0aWFuIEhvcHBzOiBJZGVhIHRvIGtlZXAg
dGhlbSBsb29zZWx5IGNvdXBsZWQuIExldCBpdCBkZXZlbG9wIG9yZ2FuaWNhbGx5LiAKRGVhbiBC
b2dkYW5vdmljOiBBdCBsZWFzdCBwcm92aWRlIGNvbnZlbnRpb25zLCBDbGFzc2lmaWNhdGlvbiBk
cmFmdCBtaWdodCBpbmNsdWRlIGh0YWcgcnVsZXMKQ2hyaXN0aWFuIEhvcHBzOiBXZSBzaG91bGQg
ZGVjaWRlIGlmIGEgZ29vZCBpZGVhClJvYiBXaWx0b246IHBlcmhhcHMgdXNlIGEgc3RhbmRhcmQg
cHJlZml4CkxvdSBCZXJnZXI6IEFncmVlZC4gSSB0aGluayB0aGF0J3MgYWxyZWFkeSBiZWVuIG1l
bnRpb25lZCwgZS5nLiwgIklBTkEiIChieSBDaHJpcykKQW5keSBCaWVybWFuOiBMaWtlIHRoZSBp
ZGVhLiBTdWdnZXN0IGhhdmluZyBjb252ZW50aW9ucyB0byBhdm9pZCBhbGwgdGhlIHBvc3NpYmxl
IHBlcm11dGF0aW9ucy4gCkFuZHkgQmllcm1hbjogaHRhZyBuaWNlIGlkZWEsIGJ1dCBydWxlcyBu
ZWVkZWQgb3RoZXJ3aXNlIHJvdXQvcm91dGluZy9yb3V0ZXMKS2VudCBXYXRzZW46IHBlcmhhcHMg
dGhlIGNsYXNzaWZpY2F0aW9ucyBjb3VsZCBiZSBuYW1lc3BhY2VkPyAgZS5nLiwgI2lldGY6PGZv
bz4sICM8dmVuZG9yPjo8YmFyPgpEZWFuIEJvZ2Rhbm92aWM6IEFzIGF1dGhvciBvZiBjbGFzc2lm
aWNhdGlvbnMsIHBlcmhhcHMgdGFrZSB0aGlzIGludG8gYWNjb3VudApMb3UgQmVyZ2VyOiBEbyB5
b3Ugd2FudCB0aGlzIG9uIHRoZSBvZmZsaW5lIGNhdGFsb2cgb3Igb24gdGhlIGRldmljZSB0bwpD
aHJpc3RpYW4gSG9wcHM6IFRoaXMgd2FzIG9uIHRoZSBzbGlkZQoKCgogICAqIDEwIE1pbjogIzgg
ZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmcgICAgICAgICAgICAgICAgICAgKEFjZWUgTGlu
ZGVtKQogICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xp
ZGVzL3NsaWRlcy05Ni1uZXRtb2QtOC5wcHR4CiAgICAgc2xpZGVzOiBodHRwczovL3d3dy5pZXRm
Lm9yZy9wcm9jZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW5ldG1vZC04LnBkZgoKQWNlZSBM
aW5kZW06IFF1ZXN0aW9uIHNob3VsZCBuZXcgYXBwbGllZCBzdGF0ZSBpbXBhY3QgdGhpcyBkb2N1
bWVudApMb3UgQmVyZ2VyOiBXZSB3b3VsZCBsaWtlIHRvIG1vdmUgdG8gTEMsIGFueSByZXNlcnZh
dGlvbnMgb24gTEM/CkRlYW4gQm9nZGFub3ZpYzogU2hvdWxkIG1vdmUgdG8gTEMuCkxvdSBCZXJn
ZXI6IEhvdyBtYW55IGhhdmUgcmVhZCB0aGlzIHZlcnNpb24gPGEgZmV3PgogICAgSG93IG1hbnkg
aGF2ZSByZWFkIGFueSB2ZXJzaW9uIDxtYW55PgpBY2VlIExpbmRlbTogSGF2ZSB0d28gY2hhbmdl
cyB3b3VsZCBsaWtlIHRvIGRpc2N1c3M6CkFjZWUgTGluZGVtOiBNZXRyaWMgY291bGQgYWN0dWFs
bHkgdXNlIHByb3RvY29sIHNwZWNpZmljIGV4dGVuc2lvbiwKICAgIHJvdXRlIHRhZyBhbmQgdW5l
cXVhbCBjb3N0IG11bHRpIHBhdGggYXMgZmVhdHVyZXMsIGNhbiBiZSBhbgogICAgYXVnbWVudGF0
aW9uLiAgQWxzbyBuZWVkIHRvIG1ha2UgY2hhbmdlIGluIGludGVyZmFjZSBhbmQgbmV4dCBob3AK
ICAgIGlkZW50aWZpY2F0aW9uLiAKTGFkaXNsYXYgTGhvdGthOiBiZWxpZXZlcyB0aGF0IHdlIGhh
ZCByb3V0ZSBtZXRyaWMgYmVmb3JlLCBva2F5IHRvIG1vdmUgZm9yd2FyZApMb3UgQmVyZ2VyOiAK
ICAgIEFyZSB0aGVyZSBhbnkgcmVzZXJ2YXRpb25zIGZvciBtb3ZpbmcgZm9yd2FyZCB3aXRoIHRo
aXMgZG9jdW1lbnQgYWZ0ZXIgdGhlIGRpc2N1c3NlZCBjaGFuZ2VzIGFyZSBtYWRlIDxub25lPgpM
b3UgQmVyZ2VyOiBPbmNlIGNoYW5nZSBpcyBtYWRlLCB3aWxsIExDIG9uIHRoZSBtYWlsaW5nIGxp
c3QuCgoKCiAgICogMTAgTWluOiAjMTAgZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTA4ICAg
ICAgICAgICAgICAgICAgKERlYW4gQm9nZGFub3ZpYykKICAgICBzbGlkZXM6IGh0dHBzOi8vd3d3
LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbmV0bW9kLTEwLnBwdHgK
ICAgICBzbGlkZXM6IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9z
bGlkZXMtOTYtbmV0bW9kLTEwLnBkZgoKTWFoZXNoIEpldGhhbmFuZGFuaTogZGlkIHlvdSBhZGRy
ZXNzIHRoZSBZQU5HIERvY3RvcnMgY29tbWVudHMKRGVhbiBCb2dkYW5vdmljOiB5ZXMKU2FtIEFs
ZHJpbjogY2FuIGEgc2luZ2xlIHJ1bGUgY292ZXIgYm90aCBMMiBhbmQgTDM/CkRlYW4gQm9nZGFu
b3ZpYzogbmVlZCB0byBjaGFpbiBtdWx0aXBsZSBtYXRjaGVzLiAgT3RoZXIgb3B0aW9ucyB3ZXJl
CiAgIGRpc2N1c3NlZCBpbiB0aGUgV0cgYW5kIHJlamVjdGVkLgpFbGxpb3QgTGVhcjogaXQgd2Fz
IGEgZmFjdHVhbCBxdWVzdGlvbjogaWYgSSByZWFkIHRoZSBtb2RlbCwgaXQncyBhCmNob2ljZSwg
Y29ycmVjdD8KRGVhbiBCb2dkYW5vdmljOiB5ZXMKTG91IEJlcmdlcjogCiAgICAgSG93IG1hbnkg
aGF2ZSByZWFkIHRoZSBsYXRlc3QgdmVyc2lvbiA8ZmV3PgogICAgIEhvdyBtYW55IGhhdmUgcmVh
ZCBhbnkgbnVtYmVyIDxhIGdvb2QgIG51bWJlcj4KICAgICBBbnkgYWRkaXRpb25hbCBpc3N1ZXMg
dG8gZGlzY3VzcyA8bm9uZT4KICAgICBIb3cgbWFueSB0aGluayB0aGUgZHJhZnQgaXMgcmVhZHkg
Zm9yIChhbm90aGVyKSBsYXN0IGNhbGwgPGxlc3MsIGJ1dCBhIHJlYXNvbmFibGUgbnVtYmVyPgpM
b3UgQmVyZ2VyOiBXaWxsIGlzc3VlIGFub3RoZXIgTEMKCgoKICAgKiAxMCBNaW46ICMxMSBkcmFm
dC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzICAgICAgICAgICAgICAgICAgICAoQW5keSBCaWVybWFu
KQogICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVz
L3NsaWRlcy05Ni1uZXRtb2QtMTEucHB0eAogICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5v
cmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1uZXRtb2QtMTEucGRmCiAKQW5keSBw
cmVzZW50cwpVcGRhdGVzL2NoYW5nZXMKQ29kZSBleHRyYWN0aW9uIFRvb2xzIG5lZWQgdG8gYmUg
aW1wcm92ZSB0byBvbmx5IGV4dHJhY3QgPGNvZGUgYmVnaW4gZW5kcz4gcGFydHMKQmVub2l0IENs
YWlzZTogYWdyZWVzIHRoYXQgbmVlZCB0byBjb3ZlciBjYXNlIG9mIGV4YW1wbGVzIGluIGRvY3Vt
ZW50cyBhbmQgaGF2ZQp0b29scyBkbyB0aGUgcmlnaHQgdGhpbmcgKFNsaWRlIDQpCktlbnQgV2F0
c2VuOiAgd291bGQgaXQgbWFrZSBzZW5zZSB0byBkaWZmZXJlbnQgYmV0d2VlbiBZQU5HIGV4YW1w
bGVzIHZzCmluc3RhbmNlIGRvY3VtZW50IGV4YW1wbGVzLCBzbyBhcyB0byBmdXJ0aGVyIGZhY2ls
aXRhdGUgZHJhZnQgdmFsaWRhdGlvbj8gCkFuZHkgQmllcm1hbjogY291bGQgZG8gYW55dGhpbmcs
IGJ1dCBuZWVkIHRvIGRlY2lkZSB3aGF0IGlzCmNvdmVyZWQuIFBlcmhhcHMgZGlzY3VzcyBvbiBs
aXN0LgpBbmR5IEJpZXJtYW46IDxzbGlkZSA1IC0gbm8gY29tbWVudHMsIHdpbGwgdGFrZSB0byBs
aXN0PgpBbmR5IEJpZXJtYW46IFdoZW4gdG8gdXNlIFlBTkcgMS4xPyBVc2Ugd2hlbiAxLjEgZmVh
dHVyZXMgYXJlIG5lZWRlZCBub3csIGJ1dCB5b3UgTUFZIHVzZSAxLjAgaWYgeW91IGRvbid0IG5l
ZWQgdGhlbS4gVXBkYXRpbmcganVzdCB0byBiZSBjdXJyZW50IHdpbGwgYmUgZXhwZW5zaXZlLgpS
b2IgV2lsdG9uOiBJcyBZQU5HIDEuMS4gYSBNVVNUL1NIT1VMRCBNQVkKQW5keSBCaWVybWFuOiBN
QVkKUm9iIFdpbHRvbjogY2xhcmlmaWNhdGlvbi4gTWFyayB0aGUgbW9kZWwgYXMgWUFORyAxLjEg
ZXZlbiB0aG91Z2ggaXQgZG9lcyBub3QgdXNlIFlBTkcgMS4xIGZlYXR1cmU/CkFuZHkgQmllcm1h
bjogeWVzLCBlLmcuLCB0byBzdXBwb3J0IGltcG9ydCBvZiBhIDEuMSBtb2R1bGUncyBkZWZpbml0
aW9ucyAKTG91IEJlcmdlcjogRnJvbSB5ZXN0ZXJkYXksIE1BWSBpcyBhcyBzdHJvbmcgYXMgV0cg
c3VwcG9ydHMKTGlvbmVsIE1vcmFuZDogIE1hcmtpbmcgdGhlIG1vZGVsIGFzIFlBTkcgMS4xIHdv
dWxkIG1lYW4gdGhhdCBpdCBjb21wbGllcyB3aXRoIGNsYXJpZmljYXRpb25zIG1hZGUgaW4gWUFO
RyAxLjEKQW5keSBCaWVybWFuOiBQZXJoYXBzIHdvcnRoIGFkZGluZyBtb3JlIGd1aWRlbGluZXMg
b24gd2hlbiAxLjEgaXMKYXBwcm9wcmlhdGUgYmV5b25kIHN5bnRheCBjaGFuZ2VzLiBFLmcuIHN0
cmluZyBkZWZpbml0aW9uIGFuZCBpbXBvcnRzCkJhbGF6cyBMZW5neWVsOiAocmU6IHNsaWRlIDcp
IFRvb2wgdG9vIHdlYWsgdG8gY2xhc3NpZnkgZm9vIGFuZCBmb28tc3RhdGUuCkFuZHkgQmllcm1h
bjogSSdkIG11Y2ggcHJlZmVyIGhhdmluZyBkZXRlcm1pbmlzdGljIHRhZ3MgdnMgb3ZlcmxvYWRp
bmcgbmFtZXMKUm9iIFdpbHRvbjogcHJlZmVyIGl0IHJlY29tbWVuZHMgb25lIHdheSByYXRoZXIg
dGhhbiBhbGxvd2luZyBjaG9pY2UKQW5keSBCaWVybWFuOiBub3Qgc3VyZSB3ZSBoYXZlIGNvbnNl
bnN1cyBvbiB0aGlzLCBjdXJyZW50IHRleHQgZG9lcyBub3QKcHV0IGEgc3Rha2UgaW4gdGhlIGdy
b3VuZApLZW50IFdhdGtpbnM6IFNob3VsZCB3ZSBkcm9wIHRoZSBzZWN0aW9uICg1LjIzKSBmb3Ig
bm93CkxvdSBCZXJnZXI6IHdlIHNob3VsZCBiZSBwcmVjaXNlIGFib3V0IHRlcm1pbm9sb2d5LCBh
bmQgdGhlIHRpdGxlIG9mIHRoZQpzZWN0aW9uIGRvZXNuJ3QgbWF0Y2ggdGhlIHRpdGxlIG9mIHRo
ZSBzbGlkZS4gIElzIHRoZSBzbGlkZSBtYWtpbmcgYQpnZW5lcmFsIHN0YXRlbWVudCBvbiBjb250
YWluZXJzIG9yIHNvbWV0aGluZyBzcGVjaWZpYyBhYm91dCBvcGVyYXRpb25hbApkYXRhIChlLmcu
LCBjb3VudGVycykKQW5keSBCaWVybWFuOiB0aGUgbGF0dGVyLiAgSW5mb3JtYXRpb24gc2hvdWxk
IGJlIGNvbnRhaW5lZCBiYXNlZCBvbgppbmZvcm1hdGlvbiBsaWZldGltZS4gRS5nLiwgdGhlIG51
bWJlciBvZiB0aW1lcyBhbiBBQ0wgaXMgYWNjZXNzZWQgKG1hdGNoZWQpCnNob3VsZCBiZSBzdG9y
ZWQgd2l0aCB0aGUgQUNMLiBJZi9pZi1zdGF0ZSBpcyBhbHNvIGJhc2VkIG9uCnByZS1wcm92aXNp
b25pbmcgYW5kIGl0IG1heSBub3QgYmUgdGhlIGFuc3dlciBmb3IgZXZlcnl0aGluZy4gIExpa2Ug
dGhlCnN1Z2dlc3Rpb24gdGhhdCBvcHN0YXRlIGhhbmRsZSB0aGF0ICh0aGlzKQpKdWVyZ2VuIFNj
aG9lbndhZWxkZXI6IHdvdWxkIGxpa2UgdG8ga2VlcCB0aGUgdGV4dCBpbiwgZXZlbiBpZiBpdCBp
cyB3ZWVrLiBXZSBtYWtlIHRoZW0gYXdhcmUgb2YgdGhlCnByb2JsZW0uCktlbnQgV2F0c2VuOiB5
b3UgbWVhbiB0aGF0IGl0IGxheXMgb3V0IHRoZSBvcHRpb25zIGFuZCBiYWNrZ3JvdW5kIGFyb3Vu
ZCB3aHkgdGhleSBtaWdodCBtYXR0ZXIKTG91IEJlcmdlcjogYnV0IHRoYXQgaXNuJ3QgYSBndWlk
ZWxpbmUKUm9iIFNoYWtpcjogSXQgaXMsIGhhdmluZyBhIGNvbW1vbiBjb252ZW50aW9uIGlzIHVz
ZWZ1bApCZW5vaXQgQ2xhaXNlOiBkb24ndCB3YW50IHRvIGRlbGF5IGd1aWRlbGluZS4gQXMgY29u
dHJpYnV0b3IsIG5lZWQgdG8KZ2V0IHRoZSB0b29saW5nIHJpZ2h0LgpKdWVyZ2VuIFNjaG9lbndh
ZWxkZXI6IHdvdWxkIGxpa2UgYSBzbGlnaHQgbW9kaWZpY2F0aW9uLCBpLmUuLCBzaG93IHJlbGF0
aW9uc2hpcApiZXR3ZWVuIHRyZWVzLCBldmVuIGlmIHVzaW5nIHNhbWUgaGllcmFyY2h5LgpCYWxh
enMgTGVuZ3llbDogcmVxdWlyZSBpZGVudGljYWwgaGllcmFyY2h5IC8gdHJlZSBzdHJ1Y3R1cmUu
CkJlbm9pdCBDbGFpc2U6IHdoYXRldmVyIHdvcmtzIHdpdGggdG9vbGluZwpMb3UgQmVyZ2VyOiBj
dXJyZW50IHRleHQgdXNlcyBkZXNjcmlwdGlvbiBhdCB0aW1lcyB0byBwcm92aWRlCnJlbGF0aW9u
c2hpcHMsIGRvZXMgdGhpcyBtYXRjaCB0b29saW5nIHJlcXVpcmVtZW50CkFuZHkgQmllcm1hbjog
V2UgY2FuIG1ha2UgdGhlIHRleHQgc3RhdGUgdGhhdCBzYW1lIHRyZWUgc3RydWN0dXJlIGlzCnJl
Y29tbWVuZGVkClJvYiBTaGFraXI6IFBsZWFzZSBkby4KQmVub2l0IENsYWlzZTogd2UgaGF2ZSB0
aGUgZ3VpZGVsaW5lIHRoZSBub3QgbW9kZWwgdGhlIGFwcGxpZWQgaW4gdGhlCnRyZWUsIGRvIHdl
IG5lZWQgdG8gc2F5IHRoaXMgdG9vPwpBbmR5IEJpZXJtYW46IG9wc3RhdGUvYXBwbGllZCBzdGF0
ZSBpcyBhIGRpZmZlcmVudCB0b3BpYy4KTG91IEJlcmdlcjogU3VnZ2VzdCB0aGlzIGlzbid0IHRo
ZSByaWdodCBkb2N1bWVudCBmb3IgdGhlIHJlY29tbWVuZGF0aW9uCm9uIG1vZGVsaW5nIGFwcGxp
ZWQgc3RhdGUuCkJlbm9pdCBDbGFpc2U6IFdlIHdpbGwgaGF2ZSBhIHdpa2kgZm9yIFlBTkcgZG9j
dG9ycywgYnV0IHRoaXMgaXNuJ3QgdGhlCnJpZ2h0IHBsYWNlIGZvciB0aGlzCkxvdSBCZXJnZXI6
IGlmIHB1dHRpbmcgaW50byBXaWtpIGlzIG5vdCBzdWZmaWNpZW50LCBjYW4geW91IHByb3Bvc2Ug
dGV4dD8KQmVub2l0IENsYWlzZTogeWVzCkxvdSBCZXJnZXI6IENoYW5nZXMgaGF2ZSBiZWVuIGRp
c2N1c3NlZCBpbiBzbGlkZXMgYW5kIGRpc2N1c3Npb24uICBBcmUKdGhlcmUgYW55IG90aGVyIGNo
YW5nZXMgbGVmdCAocGVuZGluZyk/CkFuZHkgQmllcm1hbjogTm8uCkxvdSBCZXJnZXI6IEhvdyBt
YW55IGhhdmUgcmVhZCB0aGlzIHZlcnNpb24gPGEgZmV3PgogICAgSG93IG1hbnkgaGF2ZSByZWFk
eSBhbnkgdmVyc2lvbiA8YSBnb29kIG51bWJlcj4KICAgIEFyZSB0aGVyZSBhbnkgdGVjaG5pY2Fs
IG9iamVjdGlvbnMgdGhhdCBoYXZlIG5vdCB5ZXQgYmVlbiByYWlzZWQvZGlzY3Vzc2VkIDxub25l
PgpMb3UgQmVyZ2VyOiBXYWl0IHRpbGwgd2UgaGF2ZSB1cGRhdGVkIGRyYWZ0IGFuZCB0aGVuIHdl
IGNhbiBnbyB0byBMQy4KCgoKICAgKiAxMCBNaW46ICMxMiBkcmFmdC1pZXRmLW5ldG1vZC1pbnRm
LWV4dC15YW5nLTAxICAgICAgICAgICAgICAoUm9iZXJ0IFdpbHRvbikKICAgICBzbGlkZXM6IGh0
dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbmV0bW9k
LTEyLnBwdHgKICAgICBzbGlkZXM6IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2
L3NsaWRlcy9zbGlkZXMtOTYtbmV0bW9kLTEyLnBkZgoKRGFuIFJvbWFzY2FudTogaWVlZSBwcm9w
b3NlZCB0byBkbyB0aGlzIGRyYWZ0LiBpdCBjb25maWd1cmVzIGllZWUgZnVuY3Rpb25zLiBXb3Jr
IGlzIHJpZ2h0LCBidXQgY2xvc2UgY29vcGVyYXRpb24gbmVlZGVkIHdpdGggaWVlZSAod3J0IGVu
c3VyaW5nIHdlIGRvbid0IGJyZWFrIElFRUUgcnVsZXMpClRpbSBDYXJleTogSXMgdGhlcmUgZGl2
ZXJnZW5jZSBiZXR3ZWVuIHRoaXMgZHJhZnQgYW5kIElFRUUgYW5kIEJCRiwgYW5kCmN1cnJlbnQg
ClJvYmVydCBXaWx0b246IFllcywgSUVFRSBpcyBtb3JlIGxpbWl0ZWQgYW5kIEJCRiBpcyB3aWRl
ciBzY29wZSwgdHJ5aW5nCnRvIHVuZGVyc3RhbmQgYW5kIGNvdmVyIGJvdGggaW4gcGFyYWxsZWwK
QW50b24gPyAoQnJvY2FkZSk6IFdoeSB1c2luZyA4MDIuMVEgYW5kIG5vdCBBRCBhbmQgd2h5IGxp
bWl0aW5nIHRhZwpsZW5ndGggdG8gdHdvCkxvdSBCZXJnZXI6IChvdmVydGltZSkgcGxlYXNlIGRp
c2N1c3Mgb24gbGlzdAoKCgogICAqIDEwIE1pbjogIzEzIGRyYWZ0LWlldGYtbmV0bW9kLW1vZGVs
LWVudGl0eS0wMSAgICAgICAgICAgICAgIChBbmR5IEJpZXJtYW4pCiAgICAgc2xpZGVzOiBodHRw
czovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW5ldG1vZC0x
My5wZGYKCktlbnQgV2F0c2VuOiBCQkYgZGVwZW5kaW5nIG9uIHRoaXMgbW9kdWxlLCBhcnRpY3Vs
YXRlZCBhIHdpbGxpbmduZXNzIHRvCmJlY29tZSBtb3JlIGludm9sdmVkCkJhbGF6cyBMZW5neWVs
OiBpZiB3ZSBwdXQgbm90aWZpY2F0aW9ucyBhbGwgb3ZlciB0aGUgcGxhY2UsIHdlIGxvc3MKaW1w
b3J0YW50IGZlYXR1cmVzLiAoZS5nLiwgZGFtcGVuaW5nKSBTaG91bGQgcmV1c2Ugbm90IHJlZGVm
aW5lLgpBbmR5IEJpZXJtYW46IHRoYXQncyByaWdodCwgbm90aWZpY2F0aW9ucyBtYXkgZmFsbCBv
dXQgZm9yIGZyZWUuCkRhbiBSb21hc2NhbnU6IFRoZSBjb25mb3JtYW5jZSByZWxhdGVkIHNlY3Rp
b24gbmVlZHMgZWRpdHMKRGFuIFJvbWFzY2FudTogQWdhaW4sIHNlZXMgdGhpcyBhcyBwaWVjZXMg
YmVpbmcgcmVwbGljYXRlZCBpbiBhCnByb3ByaWV0YXJ5IHdheSBhcyB3ZWxsIGFzIGluIG90aGVy
IFNET3MuIFNvIHVzIHVzZWZ1bC4KS2VudCBXYXRzZW46IE5lZWQgYW5vdGhlciByZXYgYmVmb3Jl
IExDCkxvdSBCZXJnZXI6IERvIHlvdSBoYXZlIGFuIEVUQT8KQW5keSBCaWVybWFuOiBVcGRhdGUg
aW4gfiAzIHdlZWtzCgoKCiAgICogMTAgTWluOiAjMTUgZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy1t
b2RlbC1jbGFzc2lmaWNhdGlvbiAgICAgKENhcmwgTW9iZXJnKQogICAgIHNsaWRlczogaHR0cHM6
Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1uZXRtb2QtMTUu
cHB0eAogICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xp
ZGVzL3NsaWRlcy05Ni1uZXRtb2QtMTUucGRmCgpMb3UgQmVyZ2VyOiBXUlQgU0RPcywgdGhlIElF
VEYgaGFzIGZvcm1hbCByZWxhdGlvbnNoaXBzIHdpdGggb3RoZXIgU0RPcwphbmQgb3JnYW5pemF0
aW9ucyBhbmQgd2UgY2FuIGxldmVyYWdlIGluIHRoZSBkb2N1bWVudCBkZWZpbml0aW9ucwpEZWFu
IEJvZ2Rhbm92aWM6IENvdWxkIHVzZSB0aGlzIGRyYWZ0IGFzIGZvdW5kYXRpb24gZm9yIENocmlz
Jy9SdGcgRFQgKCN0YWdzKSBkaXNjdXNzZWQgZWFybGllcgpSb2IgV2lsdG9uOiBBcmUgT3BlbmNv
bmZpZyBzdGFuZGFyZCBtb2RlbHM/CkNhcmwgTW9iZXJnOiBPcGVuIHNvdXJjZSBvcmdhbml6YXRp
b24KTG91IEJlcmdlcjogRG8geW91IGhhdmUgY2hhbmdlcyBwbGFubmVkCkNhcmwgTW9iZXJnOiBv
bmx5IHNtYWxsIGNoYW5nZXMKRGVhbiBCb2dkYW5vdmljOiBXZSBjb3VsZCBhZGQgaGFzaHRhZ3Mg
dG8gdGhpcwpDYXJsIE1vYmVyZzogb3IgaGFuZGxlIGluIHNlcGFyYXRlIGRyYWZ0CkxvdSBCZXJn
ZXI6IFdoYXQgY2hhbmdlcyBhcmUgbmVlZCBmb3IgY2xhc3NpZmljYXRpb25zL2hhc2h0YWdzCkRl
YW4gQm9nZGFub3ZpYzogRG9u4oCZdCB5ZXQga25vdwpMb3UgQmVyZ2VyOiBjb21lIGJhY2sgd2l0
aCBhIHByb3Bvc2FsIGZvciBjbGFzc2lmaWNhdGlvbnMvaGFzaHRhZ3MKTG91IEJlcmdlcjogQXJl
IHRoZXJlIGFueSAgb2JqZWN0aW9ucyB0aGF0IGhhdmVuJ3QgYmVlbiBkaXNjdXNzZWQgPG5vbmU+
CiAgICBIb3cgcmVhZCB2ZXJzaW9uPyA8cmVhc29uYWJsZSwgbm90IGxhcmdlPgogICAgSG93IHJl
YWQgc29tZSB2ZXJzaW9uPyA8YWJvdXQgdGhlIHNhbWU+CgoKCiAgICogMTAgTWluOiAjMTQgZHJh
ZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsLTA5ICAgICAgICAgICAgICAgKENseWRlIFdpbGRl
cy8gTWFoZXNoIEpldGhhbmFuZGFuaSBwcmVzZW50aW5nKQogICAgIHNsaWRlczogaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1uZXRtb2QtMTQucHB0
eAogICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGluZ3MvOTYvc2xpZGVz
L3NsaWRlcy05Ni1uZXRtb2QtMTQucGRmCgpNYWhlc2ggSmV0aGFuYW5kYW5pIHByZXNlbnRzCktl
bnQgV2F0c2VuOiBpcyB0aGlzIGJsb2NrZWQgYnkgVExTIGNsaWVudApNYWhlc2ggSmV0aGFuYW5k
YW5pOiBZZXMgKENseWRlIGNvbmZpcm1zIHZpYSBKYWJiZXIpCkxvdSBCZXJnZXI6IFF1ZXN0aW9u
IHRvIENseWRlLCBhcmUgdGhlcmUgY2hhbmdlcyB0byB0aGlzIGRvY3VtZW50IHRoYXQKYXJlIGxp
a2VseSBiYXNlZCBvbiBjaGFuZ2VzIHRvIFRMUyBkb2N1bWVudD8KQ2x5ZGUgV2lsZGVzOiB2aWEg
SmFiYmVyLCBwcm9iYWJseSBub3QKTG91IEJlcmdlcjogU2hvdWxkIHRoZSBkb2N1bWVudCBwcm9n
cmVzcyBhbmQgYmUgYmxvY2tlZCBieSByZWZlcmVuY2UKTWFoZXNoIEpldGhhbmFuZGFuaTogWWVz
IApLZW50IFdhdHNlbjogVExTIGNsaWVudCBpcyB0b28gaW1tYXR1cmUgeWV0Ckp1ZXJnZW4gU2No
b2Vud2FlbGRlOiBJZiB0aGUgZG9jdW1lbnQgaXMgYmxvY2tlZCwgd2hhdCBkb2VzIGl0IG1hdHRl
cgp3aGVyZSBpdHMgYmxvY2tlZApMb3UgQmVyZ2VyOiBpbiBnZW5lcmFsLCBpdHMgYmV0dGVyIHRv
IHByb2dyZXNzIHRoZSBkcmFmdCBvbmNlIHRoZSBXRyAncwp3b3JrIG9uIGl0IGlzIGRvbmUgdG8g
YWxsb3cgcHVibGljYXRpb24gcHJvY2VzcyB0byBvY2N1cgpKdWVyZ2VuIFNjaG9lbndhZWxkZXI6
IGFzIGFzc2lnbmVkIFlBTkcgRG9jdG9yLCB3aWxsIHJldmlldyBpbiB0aGUgbmV4dCBjb3VwbGUg
d2Vla3MKTG91IEJlcmdlcjogQ2hhaXJzIHdpbGwgZGlzY3VzcyB3aGV0aGVyIHRvIHdhaXQgZm9y
IHJlZmVyZW5jZSBvciBydW4gTEMKcHJvY2VzcyBhbmQgaGF2ZSBkb2N1bWVudCBzaXQgaW4gUkVG
IFdBSVQgc3RhdGUuIEluIGdlbmVyYWwgaXRzIGJldHRlcgp0byBwcm9ncmVzcyB0aGUgZHJhZnQg
CgoKICAKICAgKiAxMCBNaW46ICMxNiBkcmFmdC1vcGVuY29uZmlnLW5ldG1vZC1tb2RlbC1jYXRh
bG9nICAgICAgICAgICAoUm9iIFNoYWtpcikKICAgICBzbGlkZXM6IGh0dHBzOi8vd3d3LmlldGYu
b3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbmV0bW9kLTE2LnBkZgoKQW5keSBC
aWVybWFuOiB0aGlzIGlzIHZlcnkgc2ltaWxhciB0byBteSB5YW5nLXBhY2thZ2VzIGZyb20gbG9u
ZyBhZ28KQW5keSBCaWVybWFuOiBpcyB0aGlzIG1lYW50IHRvIGJlIHJlYWQgZnJvbSBkZXZpY2Ug
b3Igb2ZmbGluZT8KUm9iIFNoYWtpcjogb2ZmbGluZQpBbmR5IEJpZXJtYW46IGxpa2UgUlBNcywg
bmVlZGVkIGZvciB0aGUgbmV4dCBnZW5lcmF0aW9uIGNvbXBsaWFuY2UuIFdoYXQgd291bGQgd29y
ayB0b2dldGhlciBjYW4gbm90IGJlIGNvbnRhaW5lZCBpbiBhIG1vZHVsZQpLZW50IFdhdHNlbjog
aWYgb2ZmbGluZSwgZG9lcyBpdCBtYWtlIHNlbnNlIGZvciB0aGUgSUVURiB0byBzdGFuZGFyZGl6
ZSBpdD8KUm9iIFNoYWtpcjogY291bGQgYmUgc29tZXRoaW5nIGVsc2UKQmVub2l0IENsYWlzZTog
aW4gZmF2b3Igb2YgaXQgYmVpbmcgaW4gdGhlIElFVEYKQmFsYXpzIExlbmd5ZWw6IGFsc28gaW4g
ZmF2b3Igb2YgZGVzY3JpYmluZyBob3cgbW9kdWxlcyB3b3JrIHRvZ2V0aGVyCkxvdSBCZXJnZXI6
IHdobyB0aGlua3MgdGhpcyBmdW5jdGlvbmFsaXR5IGlzIGltcG9ydGFudCAoYSBnb29kIG51bWJl
cikKTG91IEJlcmdlcjogd2hvIHRoaW5rcyB0aGlzIFdHIHNob3VsZCB3b3JrIG9uIGl0PyAgKGJh
c2ljYWxseSB0aGUgc2FtZSkKTG91IEJlcmdlcjogQ2hhaXJzIHdpbGwgdGFsayByZSBXRyBhZG9w
dGlvbi9uZXh0IHN0ZXBzCgoKCiAgICogMTAgTWluOiAjMTcgZHJhZnQtYXNlY2hvdWQtbmV0bW9k
LXFvcyAgICAgICAgICAgICAgICAgICAgICAgKE5vcm0gU3RyYWhsZSkKICAgICBzbGlkZXM6IGh0
dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2L3NsaWRlcy9zbGlkZXMtOTYtbmV0bW9k
LTE3LnBwdHgKICAgICBzbGlkZXM6IGh0dHBzOi8vd3d3LmlldGYub3JnL3Byb2NlZWRpbmdzLzk2
L3NsaWRlcy9zbGlkZXMtOTYtbmV0bW9kLTE3LnBkZgoKT3ZlcmxhcCB3aXRoIGRyYWZ0IGluIHJv
dXRpbmcgYXJlYSwgY29vcGVyYXRpbmcKV29yayBpcyBsaWtlbHkgdG8gYmUgbW92ZSB0byBSVEcg
b3IgVFNWCktlbnQgV2F0c2VuOiBGb2xsb3d1cCBwcmVzZW50YXRpb24gaW4gUlRHIFdHLiAoZm9y
IHRob3NlIHdobyBhcmUgaW50ZXJlc3RlZC4pCgoKCiAgICogMTAgTWluOiAjMTggZHJhZnQtYWd2
LW5ldG1vZC15YW5nLWNvbXBpbGVyLW1ldGFkYXRhICAgICAgICAgKFZpbm9kIEt1bWFyIFMgYW5k
IEdhdXJhdiBBZ3Jhd2FsKQogICAgIGRyYWZ0LWFndi1uZXRtb2QteWFuZy1hbm5vdGF0aW9uLWRz
LWFuZC1kZXJpdmVkIAogICAgIHNsaWRlczogaHR0cHM6Ly93d3cuaWV0Zi5vcmcvcHJvY2VlZGlu
Z3MvOTYvc2xpZGVzL3NsaWRlcy05Ni1uZXRtb2QtMTgucGRmCgo8bm8gY29tbWVudHM+CgoKCiAg
ICogMTAgTWluOiAjMTkgZHJhZnQtc2hhcm1hLW5ldG1vZC1mYXVsdC1tb2RlbC0wMCAgICAgICAg
ICAgICAgKEFudXJhZyBTaGFybWEpCiAgICAgc2xpZGVzOiBodHRwczovL3d3dy5pZXRmLm9yZy9w
cm9jZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW5ldG1vZC0xOS5wcHR4CiAgICAgc2xpZGVz
OiBodHRwczovL3d3dy5pZXRmLm9yZy9wcm9jZWVkaW5ncy85Ni9zbGlkZXMvc2xpZGVzLTk2LW5l
dG1vZC0xOS5wZGYKCkRhbiBSb21hc2NhbnU6IGNvYXV0aG9yIG9mIFJGQzM4Nzcgd2hlcmUgd2Ug
cmV1c2VkIElUVSBkZWZpbml0aW9ucwpDYXJsIE1vYmVyZzogaXMgdGhlIElFVEYgdGhlIHJpZ2h0
IHBsYWNlIGZvciB0aGlzPyAgY29uY2VybiByZWdhcmRpbmcgdGFraW5nIHNvdXJjZSBkYXRhIGZy
b20gb3RoZXIgU0RPcyAoZS5nLiwgWEwzMykKQW51cmFnIFNoYXJtYTogdGhpcyBpcyBwdWxsaW5n
IGZyb20gYW5kIGJ1aWxkaW5nIG9uIFJGQzM4NzcKRGFuIFJvbWFzY2FudTogYXMgYXV0aG9yIG9m
IHRoYXQgUkZDLCB0aGlzIGlzIGdvb2QgYW5kIGV4dGVybmFsCnJlZmVyZW5jZXMgYXJlIG9rYXkK
QWxleCBDbGVtbTogaG93IGRpZmZlcmVudCBmcm9tIGFsYXJtcwpDYXJsIE1vYmVyZzogdGhlcmUg
d2FzIHNvbWUgcHJpb3Igd29yayB0aGF0IHlvdSBzaG91bGQgbG9vayBhdAppZiBpbnRlcmVzdGVk
IGluIGVhcmxpZXIgd29yawpBbnVyYWcgU2hhcm1hOiB5ZXMsIGxldCdzIHRhbGsKQmFsYXpzIExl
bmd5ZWw6IGlmIHdlIGRvIHdvcmssIHNob3VsZCBiZSBiYXNlZCBvbiB4NzMzCkxvdSBCZXJnZXI6
IGlmIHdlIGRvIHRoaXMgd29yaywgc2hvdWxkIGJlIGNvbnNpc3RlbnQgYWNyb3NzIGRhdGEgcGxh
bmVzCkFudXJhZyBTaGFybWE6IHllcwoKCgo=

--_004_C3FA72FFE0EB46C492764C1AA9791E6Ajunipernet_--


From nobody Fri Aug 26 01:22: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 EAABB12D0FA for ; Fri, 26 Aug 2016 01:22:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 AjdU5EcZCcOi for ; Fri, 26 Aug 2016 01:22:18 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A0BC612D09C for ; Fri, 26 Aug 2016 01:22:18 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id B781F1AE018C; Fri, 26 Aug 2016 10:22:17 +0200 (CEST)
Date: Fri, 26 Aug 2016 10:21:22 +0200 (CEST)
Message-Id: <20160826.102122.372934259558220723.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
From: Martin Bjorklund 
In-Reply-To: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com>
References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Design-Time 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: Fri, 26 Aug 2016 08:22:20 -0000

Hi,

[replying to the first post in this (old) thread; the thread got a bit
off-topic]

Balazs Lengyel  wrote:
> Hello,
> 
> As I understand it, Schema-mount today does not support an important
> use-case which we definitely need, but others also indicated they
> want.
> 
> I want to specify off-line in design time which models will be mounted
> where. Many of my nodes know in design-time what their model structure
> will be, so I want a way to be able to document this in YANG.

I'd like to understand this use case in more detail.  You say that
that a "node knows in design-time" that YANG models it will use.  Thus
it seems natural to be able to specify which other modules to mount in
the YANG module itself.

The problem I see with this is that it is very limited to the use case
where each implementation defines its own YANG modules.  Suppose you
have such a model, for example:

   module A {
     ...
     mount ... {
       mount-module B;
       mount-module C;
     }
  }
      
[pseudo-code for module A that specifies that it mounts B and C]

Now, suppose you take this module A to another implementation, and it
needs to augment something into module C; essentially this means that
it would like to mount B, C and new module D.   This will not be
possible unless it modifies module A.

> In
> today's proposal the only way to find the Yang-Mounts is to read it
> from the live node.
> 
> * OAM integrators or operators want to be able to write CLI scripts
>   and Netconf messages without accessing (expensive) real nodes. For
>   this they need to know the mounts
> * We want to generate some fancy documentation from YANG automatically
>   in design-time.

In a way this is no different from the situation today - in order to
learn what YANG modules a device supports you need to connect and
parse the  message (or ietf-yang-library data in the near
future).  This info could also be made available off-line in a file.

It should certainly be possible to define a file format that a device
somehow could "publish" off-line that contained all the info that is
available at run-time.  This file format could be exactly the same as
you would get if you did a NETCONF  operation with some filter
to only retreive the ietf-yang-library data at the mount points.



/martin


> 
> * Many use cases need the possibility to mount schemas, but do not
>   need the added complexity of schema changes in run-time.
>   Notwithstanding the case of "YANG Features", for me the model schema
>   is a mostly static description of a nodes capabilities. Most of the
>   time I do not want to worry about the node changing its schema on
>   the fly.
> 
> 
> For this I propose 2 YANG extensions
> 
> extension schema-mount {
> description "Indicates that a YANG Module is to be mounted into
> another module.
> The argument specifies the name of the module to be mounted.";
> argument mounted-module;
> }
> 
> extension schema-mount-target {
> description "Specifies the target node under which a YANG module is to
> be mounted.
> The statement can only be used inside a schema-mount statement.
> The argument follows the same rules as an augment statement's target.
> argument target-node;
> }
> 
> The two extension statements can be placed in a separate module or the
> mounted module.
> 
> I don't insist on the solution, but I need the off-line/design-time
> specification of yang-mount to be possible. IMHO the design-time mount
> use-case is more important than the dynamic-mount.
> 
> regards Balazs
> --
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Fri Aug 26 01:50:57 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 C893412D53B for ; Fri, 26 Aug 2016 01:50:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 wLbDYnDMzPCI for ; Fri, 26 Aug 2016 01:50:55 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A794612D52F for ; Fri, 26 Aug 2016 01:50:55 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 573D31AE018C; Fri, 26 Aug 2016 10:50:50 +0200 (CEST)
Date: Fri, 26 Aug 2016 10:49:54 +0200 (CEST)
Message-Id: <20160826.104954.1973625521466218062.mbj@tail-f.com>
To: bart.bogaert@nokia.com
From: Martin Bjorklund 
In-Reply-To: 
References: 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] BBF extensions to ietf-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: Fri, 26 Aug 2016 08:50:57 -0000

Hi,

"Bogaert, Bart (Nokia - BE)"  wrote:
> I would like to bring this to the ietf-entity group.  Currently BBF is
> proposing to add new RW leafs to the entity object.  This is done in the
> context of plugable entities and hence it means that when an operator (via a
> NC client) configures a plugable item it is required to define the entity
> type.  For this reason additional RW attributes are needed.  Two of the new
> leafs are class and contained-in (same as the RO class leaf). 
> 
> -          class: we think that the class leaf needs to be mandatory but
> adding this via an augment is not possible as we can't add a mandatory leaf
> via an augment.  Making class implicit for the client based on "some
> information" exchanged between device vendors and management applications is
> maybe not such a sound approach.

Can you explain in more detail how this would be used?  The idea is
that 'class' is a property of the physical hw, and that the underlying
system provides this info.  I can see that it could be useful for the
client to set this if the system can't do the classification (i.e.,
the system-set value is 'unknown').  But that's probably not the use
case you had in mind?

> -          contained-in: for plugable items contained-in requires to be
> mandatory too as a plugable item can't be "floating" in the device.

Can you explain in more detail what this means, and provide some use
cases?


/martin

> But we
> then hit a problem for the 'top-level' entity which not contained in
> anything (and 'fooling' the model by having it pointing to itself is not
> allowed).  Contained-in can't be derived by the NC server: what to do if 2
> entities of the same class are preprovisioned (together with ports and
> interfaces related to subscribers)?  We need to be sure that the subscribers
> are on the intended ports.
> 
>  
> 
> This would mean that the ietf-entity model would require a revision to add
> leafs for these plugable items.  What is the best way to address this?
> 
>  
> 
> Best regards - Vriendelijke groeten,
> 
> Bart Bogaert
> 
> Broadband-Access System Architect Data
> 
> Contact number +32 3 2408310 (+32 477 673952)
> 
>  
> 
> NOKIA
> 
> Copernicuslaan 50, 2018 Antwerp, Belgium
> Fortis 220-0002334-42
> VAT BE 0404 621 642 Register of Legal Entities Antwerp
> 
> 
> 
> <<
> This message (including any attachments) contains confidential information
> intended for a specific individual and purpose, and is protected by law. If
> you are not the intended recipient, you should delete this message. Any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited without the prior consent of its
> author.
> >> 
> 
>  
> 


From nobody Fri Aug 26 01:54:37 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 1446F12D552 for ; Fri, 26 Aug 2016 01:54:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 rKV0l0vO0wam for ; Fri, 26 Aug 2016 01:54:35 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id D4DC612D54D for ; Fri, 26 Aug 2016 01:54:34 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 16E311AE018C for ; Fri, 26 Aug 2016 10:54:34 +0200 (CEST)
Date: Fri, 26 Aug 2016 10:53:38 +0200 (CEST)
Message-Id: <20160826.105338.1510958649777755391.mbj@tail-f.com>
To: netmod@ietf.org
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] entity naming question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 08:54:36 -0000

Hi,

It seems that some people prefer the term 'hardware' instead of
'entity' for things that are ... hardware.

Should we make this change in the document?  Specifically, the
top-level node 'entity' would then be renamed to 'hardware'.  Probably
other changes as well, but we can start with this one.


/martin


From nobody Fri Aug 26 02:23: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 E928812D11D for ; Fri, 26 Aug 2016 02:23:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 jfOjNn1MJBMd for ; Fri, 26 Aug 2016 02:23:24 -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 D9FF412D097 for ; Fri, 26 Aug 2016 02:23:23 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2DD148DF; Fri, 26 Aug 2016 11:23:22 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id kmGBnxaGk9jE; Fri, 26 Aug 2016 11:23:00 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 26 Aug 2016 11:23:21 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 21BBB200AC; Fri, 26 Aug 2016 11:23:21 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id BKxDMvmYrrkz; Fri, 26 Aug 2016 11:23:20 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E3454200AB; Fri, 26 Aug 2016 11:23:19 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id A97073C4E81B; Fri, 26 Aug 2016 11:23:18 +0200 (CEST)
Date: Fri, 26 Aug 2016 11:23:17 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160826092315.GA32387@elstar.local>
Mail-Followup-To: Martin Bjorklund , netmod@ietf.org
References: <20160826.105338.1510958649777755391.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160826.105338.1510958649777755391.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] entity naming question
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, 26 Aug 2016 09:23:26 -0000

On Fri, Aug 26, 2016 at 10:53:38AM +0200, Martin Bjorklund wrote:
> Hi,
> 
> It seems that some people prefer the term 'hardware' instead of
> 'entity' for things that are ... hardware.
> 
> Should we make this change in the document?  Specifically, the
> top-level node 'entity' would then be renamed to 'hardware'.  Probably
> other changes as well, but we can start with this one.

Well, 'hardware' would equate 'physical entity' but not 'entity'. ;-)

I agree that the ENTITY-MIB terminology is generally confusing (except
for those who got used to it). Changing the nomenclature will be a
bigger thing that just renaming the top-level, the 'physical-entity'
would likely become a 'component', e.g.

module: ietf-hardware
   +--ro hardware-state
   |  +--ro last-change?       yang:date-and-time
   |  +--ro component* [name]
   |     +--ro name                  string
   |     +--ro class?                identityref
   :
   :
   +--rw hardware
      +--rw component* [name]
         +--rw name                  string
         :

and there are more 'entity' words to replace (feature names plus many
edits in the texts). I believe it is worth to move to a terminology
that is far easier to understand and use; as long as the relationship
to the old MIB modules is clearly documented we are fine I think.

/js

PS: We had a discussion in a separate thread whether base identities
    of identities defined in IANA module should not be defined in the
    IANA modules themself; this allows reuse by just importing the
    IANA module. Perhaps this applies here as well.
    

-- 
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 Aug 26 03:45: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 6C20712D60E for ; Fri, 26 Aug 2016 03:44:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 bFtfjQyaiYOv for ; Fri, 26 Aug 2016 03:44:58 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6AE3912D623 for ; Fri, 26 Aug 2016 03:44:07 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 786D31AE018C; Fri, 26 Aug 2016 12:44:05 +0200 (CEST)
Date: Fri, 26 Aug 2016 12:43:04 +0200 (CEST)
Message-Id: <20160826.124304.1561054177442678773.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20160729133257.GA3317@elstar.local>
References:  <20160729133257.GA3317@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 10:44:59 -0000

Juergen Schoenwaelder  wrote:
> On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - BE) wrote:
> 
> [...]
>  
> > In order to correctly compile (using confdc) we also need to import
> > iana-entity for the identities defined in there.  However this is leading a
> > circular dependency:
> > 
> > 1.       Iana-entity imports ietf-entity (to 'resolve'
> > entity-physical-class)
> > 
> > 2.       Ietf-entity imports iana-entity (to obtain the indentities defined
> > in there)
> > 
> > One way to solve this is to move the definition of entity-physical-class
> > from ietf-entity to iana-entity which would resolve the fact that
> > iana-entity requires an import of ietf-entity (ietf-entity needs to import
> > iana-entity anyhow, so it can also pick the typedef from the same module
> > too).
> 
> I think moving the definition of entity-physical-class into
> iana-entity makes sense.

Ok.  It feels a bit backwards to me though, but I can see the value of
having the iana module self-contained.


/martin


> Perhaps this is generally a good pattern to
> follow for base identities for which IANA maintains derived
> identities.  The required import should not be a problem; the
> ENTITY-MIB also imports from IANA-ENTITY-MIB.


From nobody Fri Aug 26 05:23: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 39C1312D72A for ; Fri, 26 Aug 2016 05:23:29 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 s5EkaD3HEun9 for ; Fri, 26 Aug 2016 05:23: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 3E8B512D742 for ; Fri, 26 Aug 2016 05:23:12 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CC6EBF76; Fri, 26 Aug 2016 14:23:10 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id H2jHYWvF1eWk; Fri, 26 Aug 2016 14:22:34 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 26 Aug 2016 14:22:44 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id BFB3F200CA; Fri, 26 Aug 2016 14:22:32 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id MFQNBbEns4dC; Fri, 26 Aug 2016 14:22:31 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5A027200F6; Fri, 26 Aug 2016 14:22:31 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 5936D3C4ED96; Fri, 26 Aug 2016 14:22:29 +0200 (CEST)
Date: Fri, 26 Aug 2016 14:22:29 +0200
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Message-ID: <20160826122229.GA32769@elstar.local>
Mail-Followup-To: Martin Bjorklund , bart.bogaert@nokia.com, netmod@ietf.org
References:  <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160826.124304.1561054177442678773.mbj@tail-f.com>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import
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, 26 Aug 2016 12:23:29 -0000

On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> Juergen Schoenwaelder  wrote:
> > On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - BE) wrote:
> > 
> > [...]
> >  
> > > In order to correctly compile (using confdc) we also need to import
> > > iana-entity for the identities defined in there.  However this is leading a
> > > circular dependency:
> > > 
> > > 1.       Iana-entity imports ietf-entity (to 'resolve'
> > > entity-physical-class)
> > > 
> > > 2.       Ietf-entity imports iana-entity (to obtain the indentities defined
> > > in there)
> > > 
> > > One way to solve this is to move the definition of entity-physical-class
> > > from ietf-entity to iana-entity which would resolve the fact that
> > > iana-entity requires an import of ietf-entity (ietf-entity needs to import
> > > iana-entity anyhow, so it can also pick the typedef from the same module
> > > too).
> > 
> > I think moving the definition of entity-physical-class into
> > iana-entity makes sense.
> 
> Ok.  It feels a bit backwards to me though, but I can see the value of
> having the iana module self-contained.
>

Well, it may look backwards if people want to reuse the base identity
but none of the IANA assigned identities - but then it might be good
if people at least look at IANA assigned identities. Or are there other
reasons why you think this may be looking 'backwards'?

/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 Aug 26 05:28: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 BE81312D5E7 for ; Fri, 26 Aug 2016 05:28:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KxspzTtxHTCC for ; Fri, 26 Aug 2016 05:28:23 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 9A23B12D694 for ; Fri, 26 Aug 2016 05:28:22 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id DEF9D1CC00D3; Fri, 26 Aug 2016 14:28:21 +0200 (CEST)
From: Ladislav Lhotka 
To: Martin Bjorklund , balazs.lengyel@ericsson.com
In-Reply-To: <20160826.102122.372934259558220723.mbj@tail-f.com>
References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com> <20160826.102122.372934259558220723.mbj@tail-f.com>
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Fri, 26 Aug 2016 14:28:22 +0200
Message-ID: 
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Design-Time 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: Fri, 26 Aug 2016 12:28:29 -0000

Martin Bjorklund  writes:

> Hi,
>
> [replying to the first post in this (old) thread; the thread got a bit
> off-topic]
>
> Balazs Lengyel  wrote:
>> Hello,
>> 
>> As I understand it, Schema-mount today does not support an important
>> use-case which we definitely need, but others also indicated they
>> want.
>> 
>> I want to specify off-line in design time which models will be mounted
>> where. Many of my nodes know in design-time what their model structure
>> will be, so I want a way to be able to document this in YANG.
>
> I'd like to understand this use case in more detail.  You say that
> that a "node knows in design-time" that YANG models it will use.  Thus
> it seems natural to be able to specify which other modules to mount in
> the YANG module itself.

Did you have a chance to look into my slides from Berlin? I sketched some
solutions there.

>
> The problem I see with this is that it is very limited to the use case
> where each implementation defines its own YANG modules.  Suppose you
> have such a model, for example:
>
>    module A {
>      ...
>      mount ... {
>        mount-module B;
>        mount-module C;
>      }
>   }
>       
> [pseudo-code for module A that specifies that it mounts B and C]
>
> Now, suppose you take this module A to another implementation, and it
> needs to augment something into module C; essentially this means that
> it would like to mount B, C and new module D.   This will not be
> possible unless it modifies module A.

Not necessarily, D could contain an augment with a target specified by a
schema node identifier that uses nodes from both A and C.

Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it would
be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the
augment in ietf-ipv6-router-advertisements

  augment "/if:interfaces-state/if:interface/ip:ipv6" { ... }

needn't be changed.

The major problem with this IMO is that it needs a new YANG statement. 

>
>> In
>> today's proposal the only way to find the Yang-Mounts is to read it
>> from the live node.
>> 
>> * OAM integrators or operators want to be able to write CLI scripts
>>   and Netconf messages without accessing (expensive) real nodes. For
>>   this they need to know the mounts
>> * We want to generate some fancy documentation from YANG automatically
>>   in design-time.
>
> In a way this is no different from the situation today - in order to
> learn what YANG modules a device supports you need to connect and
> parse the  message (or ietf-yang-library data in the near
> future).  This info could also be made available off-line in a file.

Yup. So we just need some machine-readable description of the structure
of mounted schemas.

>
> It should certainly be possible to define a file format that a device
> somehow could "publish" off-line that contained all the info that is
> available at run-time.  This file format could be exactly the same as
> you would get if you did a NETCONF  operation with some filter
> to only retreive the ietf-yang-library data at the mount points.

Well, if you have multiple levels of mounts, it will get messy: you
wouldn't know which yang-library data belongs to which mount point.

I believe some variation on YSDL could work, and as I wrote in another
thread, we could also incorporate datastores: after defining the
(multilevel) schemas, each datastore will get one assigned - and they
can also share them where needed.

Lada

>
>
>
> /martin
>
>
>> 
>> * Many use cases need the possibility to mount schemas, but do not
>>   need the added complexity of schema changes in run-time.
>>   Notwithstanding the case of "YANG Features", for me the model schema
>>   is a mostly static description of a nodes capabilities. Most of the
>>   time I do not want to worry about the node changing its schema on
>>   the fly.
>> 
>> 
>> For this I propose 2 YANG extensions
>> 
>> extension schema-mount {
>> description "Indicates that a YANG Module is to be mounted into
>> another module.
>> The argument specifies the name of the module to be mounted.";
>> argument mounted-module;
>> }
>> 
>> extension schema-mount-target {
>> description "Specifies the target node under which a YANG module is to
>> be mounted.
>> The statement can only be used inside a schema-mount statement.
>> The argument follows the same rules as an augment statement's target.
>> argument target-node;
>> }
>> 
>> The two extension statements can be placed in a separate module or the
>> mounted module.
>> 
>> I don't insist on the solution, but I need the off-line/design-time
>> specification of yang-mount to be possible. IMHO the design-time mount
>> use-case is more important than the dynamic-mount.
>> 
>> regards Balazs
>> --
>> Balazs Lengyel                       Ericsson Hungary Ltd.
>> Senior Specialist
>> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
>
> _______________________________________________
> 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 Aug 26 05:33: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 2274912D67A for ; Fri, 26 Aug 2016 05:33:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 d89SEiulOYLE for ; Fri, 26 Aug 2016 05:33: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 687C112D733 for ; Fri, 26 Aug 2016 05:33:28 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 3AE871AE018C; Fri, 26 Aug 2016 14:33:27 +0200 (CEST)
Date: Fri, 26 Aug 2016 14:32:30 +0200 (CEST)
Message-Id: <20160826.143230.1673334253843878893.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20160826122229.GA32769@elstar.local>
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 12:33:30 -0000

Juergen Schoenwaelder  wrote:
> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - BE) wrote:
> > > 
> > > [...]
> > >  
> > > > In order to correctly compile (using confdc) we also need to import
> > > > iana-entity for the identities defined in there.  However this is leading a
> > > > circular dependency:
> > > > 
> > > > 1.       Iana-entity imports ietf-entity (to 'resolve'
> > > > entity-physical-class)
> > > > 
> > > > 2.       Ietf-entity imports iana-entity (to obtain the indentities defined
> > > > in there)
> > > > 
> > > > One way to solve this is to move the definition of entity-physical-class
> > > > from ietf-entity to iana-entity which would resolve the fact that
> > > > iana-entity requires an import of ietf-entity (ietf-entity needs to import
> > > > iana-entity anyhow, so it can also pick the typedef from the same module
> > > > too).
> > > 
> > > I think moving the definition of entity-physical-class into
> > > iana-entity makes sense.
> > 
> > Ok.  It feels a bit backwards to me though, but I can see the value of
> > having the iana module self-contained.
> >
> 
> Well, it may look backwards if people want to reuse the base identity
> but none of the IANA assigned identities - but then it might be good
> if people at least look at IANA assigned identities. Or are there other
> reasons why you think this may be looking 'backwards'?

I makes ietf-entity dependent on iana-entity, since the base identity
is defined in iana-entity.

But OTOH, even if we solved that, ietf-entity is dependent on
iana-entity b/c of the value 'sensor'.

So in this case it is probably fine, but I'm not sure about the
general idea.


/martin


From nobody Fri Aug 26 05:41: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 C10DF12D8A0 for ; Fri, 26 Aug 2016 05:41:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 UvgPiS2vt6wE for ; Fri, 26 Aug 2016 05:41:22 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 40E9E12D76D for ; Fri, 26 Aug 2016 05:39:27 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 2B02D1AE018C; Fri, 26 Aug 2016 14:39:26 +0200 (CEST)
Date: Fri, 26 Aug 2016 14:38:30 +0200 (CEST)
Message-Id: <20160826.143830.937655299426629223.mbj@tail-f.com>
To: lhotka@nic.cz
From: Martin Bjorklund 
In-Reply-To: 
References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com> <20160826.102122.372934259558220723.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Design-Time 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: Fri, 26 Aug 2016 12:41:24 -0000

Ladislav Lhotka  wrote:
> Martin Bjorklund  writes:
> 
> > Hi,
> >
> > [replying to the first post in this (old) thread; the thread got a bit
> > off-topic]
> >
> > Balazs Lengyel  wrote:
> >> Hello,
> >> 
> >> As I understand it, Schema-mount today does not support an important
> >> use-case which we definitely need, but others also indicated they
> >> want.
> >> 
> >> I want to specify off-line in design time which models will be mounted
> >> where. Many of my nodes know in design-time what their model structure
> >> will be, so I want a way to be able to document this in YANG.
> >
> > I'd like to understand this use case in more detail.  You say that
> > that a "node knows in design-time" that YANG models it will use.  Thus
> > it seems natural to be able to specify which other modules to mount in
> > the YANG module itself.
> 
> Did you have a chance to look into my slides from Berlin? I sketched some
> solutions there.

Well, that's a *solution*.  I'd like to understand the *problem* first ;)

> > The problem I see with this is that it is very limited to the use case
> > where each implementation defines its own YANG modules.  Suppose you
> > have such a model, for example:
> >
> >    module A {
> >      ...
> >      mount ... {
> >        mount-module B;
> >        mount-module C;
> >      }
> >   }
> >       
> > [pseudo-code for module A that specifies that it mounts B and C]
> >
> > Now, suppose you take this module A to another implementation, and it
> > needs to augment something into module C; essentially this means that
> > it would like to mount B, C and new module D.   This will not be
> > possible unless it modifies module A.
> 
> Not necessarily, D could contain an augment with a target specified by a
> schema node identifier that uses nodes from both A and C.

Not if B and D are defined as standalone modules, e.g. if B is
ietf-interfaces and D is ietf-ip.

> Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it would
> be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the
> augment in ietf-ipv6-router-advertisements
> 
>   augment "/if:interfaces-state/if:interface/ip:ipv6" { ... }
> 
> needn't be changed.

This would be an entirely different kind of mount!  The current mount
doesn't work like that; it doesn't give you visibility into the
combined models - by design.


> The major problem with this IMO is that it needs a new YANG statement. 
> 
> >
> >> In
> >> today's proposal the only way to find the Yang-Mounts is to read it
> >> from the live node.
> >> 
> >> * OAM integrators or operators want to be able to write CLI scripts
> >>   and Netconf messages without accessing (expensive) real nodes. For
> >>   this they need to know the mounts
> >> * We want to generate some fancy documentation from YANG automatically
> >>   in design-time.
> >
> > In a way this is no different from the situation today - in order to
> > learn what YANG modules a device supports you need to connect and
> > parse the  message (or ietf-yang-library data in the near
> > future).  This info could also be made available off-line in a file.
> 
> Yup. So we just need some machine-readable description of the structure
> of mounted schemas.
> 
> >
> > It should certainly be possible to define a file format that a device
> > somehow could "publish" off-line that contained all the info that is
> > available at run-time.  This file format could be exactly the same as
> > you would get if you did a NETCONF  operation with some filter
> > to only retreive the ietf-yang-library data at the mount points.
> 
> Well, if you have multiple levels of mounts, it will get messy: you
> wouldn't know which yang-library data belongs to which mount point.

Why not - imagine that you do a full  on such a device, it will
return the nested yang library data just fine.


/martin


> I believe some variation on YSDL could work, and as I wrote in another
> thread, we could also incorporate datastores: after defining the
> (multilevel) schemas, each datastore will get one assigned - and they
> can also share them where needed.
> 
> Lada
> 
> >
> >
> >
> > /martin
> >
> >
> >> 
> >> * Many use cases need the possibility to mount schemas, but do not
> >>   need the added complexity of schema changes in run-time.
> >>   Notwithstanding the case of "YANG Features", for me the model schema
> >>   is a mostly static description of a nodes capabilities. Most of the
> >>   time I do not want to worry about the node changing its schema on
> >>   the fly.
> >> 
> >> 
> >> For this I propose 2 YANG extensions
> >> 
> >> extension schema-mount {
> >> description "Indicates that a YANG Module is to be mounted into
> >> another module.
> >> The argument specifies the name of the module to be mounted.";
> >> argument mounted-module;
> >> }
> >> 
> >> extension schema-mount-target {
> >> description "Specifies the target node under which a YANG module is to
> >> be mounted.
> >> The statement can only be used inside a schema-mount statement.
> >> The argument follows the same rules as an augment statement's target.
> >> argument target-node;
> >> }
> >> 
> >> The two extension statements can be placed in a separate module or the
> >> mounted module.
> >> 
> >> I don't insist on the solution, but I need the off-line/design-time
> >> specification of yang-mount to be possible. IMHO the design-time mount
> >> use-case is more important than the dynamic-mount.
> >> 
> >> regards Balazs
> >> --
> >> Balazs Lengyel                       Ericsson Hungary Ltd.
> >> Senior Specialist
> >> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
> >
> > _______________________________________________
> > 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 Aug 26 05:52: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 A70C512D0AE for ; Fri, 26 Aug 2016 05:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 cbbAiq5zCHlm for ; Fri, 26 Aug 2016 05:51:59 -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 61D6E12D76E for ; Fri, 26 Aug 2016 05:50:20 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 2FC7B35E; Fri, 26 Aug 2016 14:50:19 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id UOxWx21fs2DY; Fri, 26 Aug 2016 14:49:56 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Fri, 26 Aug 2016 14:50:18 +0200 (CEST)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 65B53200A8; Fri, 26 Aug 2016 14:50:18 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id odGU1C0bznNp; Fri, 26 Aug 2016 14:50:17 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 57B80200A3; Fri, 26 Aug 2016 14:50:17 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 7A5BF3C4EF39; Fri, 26 Aug 2016 14:50:16 +0200 (CEST)
Date: Fri, 26 Aug 2016 14:50:16 +0200
From: Juergen Schoenwaelder 
To: Jernej Tuljak 
Message-ID: <20160826125016.GA32908@elstar.local>
Mail-Followup-To: Jernej Tuljak , netmod@ietf.org
References: <062e01d1fd48$82309670$8691c350$@mg-soft.si>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <062e01d1fd48$82309670$8691c350$@mg-soft.si>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Is this leafref path example valid in YANG 1?
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, 26 Aug 2016 12:52:01 -0000

On Tue, Aug 23, 2016 at 04:13:23PM +0200, Jernej Tuljak wrote:
> Hi,
> 
> this is a YANG 1, not 1.1 question. 

[...]
 
> Note the "path" expression that is referencing names that do not
> seem to be in b's scope. Is this a valid "path" expression (names
> resolved upon usage) or should all names inside the "grouping" be
> resolved where the "grouping" is defined?

RFC 6020 says in section 7.12:

   The effect of a "uses" reference to a grouping is that the nodes
   defined by the grouping are copied into the current schema tree, and
   then updated according to the "refine" and "augment" statements.

   The identifiers defined in the grouping are not bound to a namespace
   until the contents of the grouping are added to the schema tree via a
   "uses" statement that does not appear inside a "grouping" statement,
   at which point they are bound to the namespace of the current module.

This makes me believe that the uses statement should resolve things
to this:

submodule a {

    belongs-to main {
        prefix "a";
    }
    include b;

    container top {
        leaf top-leaf {
            type string;
        }
        leaf some-leaf {
            type leafref {
                path "/top/top-leaf";
            }
        }
    }
}

Other opinions? The text quoted from RFC 6020 only talks specifically
about identifiers but I would assume that the same late binding applies
to path statement arguments.

/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 Aug 26 06:19: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 6D4C112D8A0 for ; Fri, 26 Aug 2016 06:19:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 I-VVm5mOB-Eq for ; Fri, 26 Aug 2016 06:19:12 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5988D12D8E8 for ; Fri, 26 Aug 2016 06:12:04 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:d83f:ce1e:8e18:81a0] (unknown [IPv6:2001:718:1a02:1:d83f:ce1e:8e18:81a0]) by mail.nic.cz (Postfix) with ESMTPSA id 9FB6061DA2; Fri, 26 Aug 2016 15:12:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1472217122; bh=x9W2OcFRIyTurl7/dKLZpRMuymfnAPLDXrZkGo2+4xA=; h=From:Date:To; b=utln51pH6btOjfak2uf0IQ2QZo6I1rPlu4r0sQfWGGVL3BVwdaZYueSPow2ZiGLi4 RjTmJJ1noGVICFCwppeGmsObNS9ev9ehIO7O7q7GL9pjExzhmIP6meOVsIyRDx7B0r gqugnxSXR+azoUU/vV0Wyo7hLK187orBxXxFT3oY=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <20160826.143830.937655299426629223.mbj@tail-f.com>
Date: Fri, 26 Aug 2016 15:12:06 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com> <20160826.102122.372934259558220723.mbj@tail-f.com>  <20160826.143830.937655299426629223.mbj@tail-f.com>
To: =?utf-8?Q?Martin_Bj=C3=B6rklund?= 
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] Design-Time 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: Fri, 26 Aug 2016 13:19:16 -0000

> On 26 Aug 2016, at 14:38, Martin Bjorklund  wrote:
>=20
> Ladislav Lhotka  wrote:
>> Martin Bjorklund  writes:
>>=20
>>> Hi,
>>>=20
>>> [replying to the first post in this (old) thread; the thread got a =
bit
>>> off-topic]
>>>=20
>>> Balazs Lengyel  wrote:
>>>> Hello,
>>>>=20
>>>> As I understand it, Schema-mount today does not support an =
important
>>>> use-case which we definitely need, but others also indicated they
>>>> want.
>>>>=20
>>>> I want to specify off-line in design time which models will be =
mounted
>>>> where. Many of my nodes know in design-time what their model =
structure
>>>> will be, so I want a way to be able to document this in YANG.
>>>=20
>>> I'd like to understand this use case in more detail.  You say that
>>> that a "node knows in design-time" that YANG models it will use.  =
Thus
>>> it seems natural to be able to specify which other modules to mount =
in
>>> the YANG module itself.
>>=20
>> Did you have a chance to look into my slides from Berlin? I sketched =
some
>> solutions there.
>=20
> Well, that's a *solution*.  I'd like to understand the *problem* first =
;)
>=20
>>> The problem I see with this is that it is very limited to the use =
case
>>> where each implementation defines its own YANG modules.  Suppose you
>>> have such a model, for example:
>>>=20
>>>   module A {
>>>     ...
>>>     mount ... {
>>>       mount-module B;
>>>       mount-module C;
>>>     }
>>>  }
>>>=20
>>> [pseudo-code for module A that specifies that it mounts B and C]
>>>=20
>>> Now, suppose you take this module A to another implementation, and =
it
>>> needs to augment something into module C; essentially this means =
that
>>> it would like to mount B, C and new module D.   This will not be
>>> possible unless it modifies module A.
>>=20
>> Not necessarily, D could contain an augment with a target specified =
by a
>> schema node identifier that uses nodes from both A and C.
>=20
> Not if B and D are defined as standalone modules, e.g. if B is
> ietf-interfaces and D is ietf-ip.

Right, we cannot have everything.

>=20
>> Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it =
would
>> be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the
>> augment in ietf-ipv6-router-advertisements
>>=20
>>  augment "/if:interfaces-state/if:interface/ip:ipv6" { ... }
>>=20
>> needn't be changed.
>=20
> This would be an entirely different kind of mount!  The current mount
> doesn't work like that; it doesn't give you visibility into the
> combined models - by design.

Of course this is a different kind of mount.

>=20
>=20
>> The major problem with this IMO is that it needs a new YANG =
statement.=20
>>=20
>>>=20
>>>> In
>>>> today's proposal the only way to find the Yang-Mounts is to read it
>>>> from the live node.
>>>>=20
>>>> * OAM integrators or operators want to be able to write CLI scripts
>>>>  and Netconf messages without accessing (expensive) real nodes. For
>>>>  this they need to know the mounts
>>>> * We want to generate some fancy documentation from YANG =
automatically
>>>>  in design-time.
>>>=20
>>> In a way this is no different from the situation today - in order to
>>> learn what YANG modules a device supports you need to connect and
>>> parse the  message (or ietf-yang-library data in the near
>>> future).  This info could also be made available off-line in a file.
>>=20
>> Yup. So we just need some machine-readable description of the =
structure
>> of mounted schemas.
>>=20
>>>=20
>>> It should certainly be possible to define a file format that a =
device
>>> somehow could "publish" off-line that contained all the info that is
>>> available at run-time.  This file format could be exactly the same =
as
>>> you would get if you did a NETCONF  operation with some filter
>>> to only retreive the ietf-yang-library data at the mount points.
>>=20
>> Well, if you have multiple levels of mounts, it will get messy: you
>> wouldn't know which yang-library data belongs to which mount point.
>=20
> Why not - imagine that you do a full  on such a device, it will
> return the nested yang library data just fine.

Well, yes, if you are prepared to parse and process arbitrary data for =
which you don't know the schema. I think the schema and instance data (=3D=
  reply) are different things and we should treat them so: the =
complete schema description should IMO have a well-known (meta-)schema, =
even if we express it with YANG. =20

Lada

>=20
>=20
> /martin
>=20
>=20
>> I believe some variation on YSDL could work, and as I wrote in =
another
>> thread, we could also incorporate datastores: after defining the
>> (multilevel) schemas, each datastore will get one assigned - and they
>> can also share them where needed.
>>=20
>> Lada
>>=20
>>>=20
>>>=20
>>>=20
>>> /martin
>>>=20
>>>=20
>>>>=20
>>>> * Many use cases need the possibility to mount schemas, but do not
>>>>  need the added complexity of schema changes in run-time.
>>>>  Notwithstanding the case of "YANG Features", for me the model =
schema
>>>>  is a mostly static description of a nodes capabilities. Most of =
the
>>>>  time I do not want to worry about the node changing its schema on
>>>>  the fly.
>>>>=20
>>>>=20
>>>> For this I propose 2 YANG extensions
>>>>=20
>>>> extension schema-mount {
>>>> description "Indicates that a YANG Module is to be mounted into
>>>> another module.
>>>> The argument specifies the name of the module to be mounted.";
>>>> argument mounted-module;
>>>> }
>>>>=20
>>>> extension schema-mount-target {
>>>> description "Specifies the target node under which a YANG module is =
to
>>>> be mounted.
>>>> The statement can only be used inside a schema-mount statement.
>>>> The argument follows the same rules as an augment statement's =
target.
>>>> argument target-node;
>>>> }
>>>>=20
>>>> The two extension statements can be placed in a separate module or =
the
>>>> mounted module.
>>>>=20
>>>> I don't insist on the solution, but I need the off-line/design-time
>>>> specification of yang-mount to be possible. IMHO the design-time =
mount
>>>> use-case is more important than the dynamic-mount.
>>>>=20
>>>> regards Balazs
>>>> --
>>>> Balazs Lengyel                       Ericsson Hungary Ltd.
>>>> Senior Specialist
>>>> Mobile: +36-70-330-7909              email: =
Balazs.Lengyel@ericsson.com
>>>=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

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





From nobody Fri Aug 26 06:43: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 0F47412D8CA; Fri, 26 Aug 2016 06:43:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.946
X-Spam-Level: 
X-Spam-Status: No, score=0.946 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bi8LEk5_8odd; Fri, 26 Aug 2016 06:43:19 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F205112D92A; Fri, 26 Aug 2016 06:31:20 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; 
From: "Susan Hares" 
To: "'Netconf'" , , "'TEAS WG'" , 
Date: Fri, 26 Aug 2016 09:30:11 -0400
Message-ID: <088101d1ff9d$f8fddc70$eaf99550$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0882_01D1FF7C.71EDC310"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdH/nc6dK6XhOH24RUiLR0Uhb4KVrg==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: [netmod] Feedback on WG Last call on the draft-ietf-i2rs-yang-network-topo-05.txt (8/26 to 9/9)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 13:43:24 -0000

This is a multipart message in MIME format.

------=_NextPart_000_0882_01D1FF7C.71EDC310
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The I2RS WG has begun a WG LC on the Yang data model for network topologies,
and looks for feedback from your working  on this draft.  You may just
respond to this email to provide feedback. 

 

Sue Hares 

 

From: Susan Hares [mailto:shares@ndzh.com] 
Sent: Friday, August 26, 2016 9:28 AM
To: 'i2rs@ietf.org'
Cc: 'draft-ietf-i2rs-yang-network-topo@ietf.org'; 'russ@riw.us'
Subject: WG Last call on the draft-ietf-i2rs-yang-network-topo

 

This begins a 2 week WG LC on draft-ietf-i2rs-yang-network-topo-05.txt (8/26
to 9/9).  

 

The authors should indicate if they know of IPR on this draft by 8/31/2016.
In considering this draft, the WG should consider: 

 

1)      Does the implementations of this draft in ODL open source code base
sufficient experience on the Yang drafts? 

2)      Does anyone know of other implementations of this model? 

3)      Do you believe this Yang model is stable enough to publish and
distribute to yang libraries? 

 

Sue Hares and Russ White 

Co-chairs 

 

 


------=_NextPart_000_0882_01D1FF7C.71EDC310
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The I2RS WG has begun a WG LC on the Yang data =
model for network topologies, and looks for feedback from your working =
 on this draft.  You may just respond to this email to provide =
feedback. 
 
Sue Hares =

 
From:=
 =
Susan Hares [mailto:shares@ndzh.com] 
Sent: Friday, August 26, =
2016 9:28 AM
To: 'i2rs@ietf.org'
Cc: =
'draft-ietf-i2rs-yang-network-topo@ietf.org'; =
'russ@riw.us'
Subject: WG Last call on the =
draft-ietf-i2rs-yang-network-topo
 
This begins =
a 2 week WG LC on draft-ietf-i2rs-yang-network-topo-05.txt (8/26 to =
9/9).  
 
The authors should indicate if they know of IPR on =
this draft by 8/31/2016.  In considering this draft, the WG should =
consider: 
 
1)      =
Does the implementations of this draft in ODL =
open source code base sufficient experience on the Yang drafts? =

2)      =
Does anyone know of other implementations of =
this model? 
3)      =
Do you believe this Yang model is stable enough =
to publish and distribute to yang libraries? 
 
Sue Hares =
and Russ White 
Co-chairs =

 
 

------=_NextPart_000_0882_01D1FF7C.71EDC310--


From nobody Fri Aug 26 06:55: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 E533912D7B0; Fri, 26 Aug 2016 06:55:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.957
X-Spam-Level: 
X-Spam-Status: No, score=0.957 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_BL=0.01, RCVD_IN_MSPIKE_L5=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7J9mAPQ0t6NY; Fri, 26 Aug 2016 06:55:20 -0700 (PDT)
Received: from hickoryhill-consulting.com (50-245-122-97-static.hfc.comcastbusiness.net [50.245.122.97]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D91AC12D815; Fri, 26 Aug 2016 06:43:07 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=74.43.47.166; 
From: "Susan Hares" 
To: "'Netconf'" , , , "'TEAS WG'" 
References: 
In-Reply-To: 
Date: Fri, 26 Aug 2016 09:41:58 -0400
Message-ID: <088e01d1ff9f$9e34fa10$da9eee30$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_088F_01D1FF7E.1723F650"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQHxkphU7njWmJH4A5s+GBIshhds06AcFslg
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com 
Archived-At: 
Subject: [netmod] FW: WG LC on draft-ietf-i2rs-yang-l3-topology-03.txt (8/26 to 9/9)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 13:55:22 -0000

This is a multipart message in MIME format.

------=_NextPart_000_088F_01D1FF7E.1723F650
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

The I2RS WG is starting a WG LC on the L3 network topology model and wishes
input.  

 

Sue Hares and Russ White 

 

From: Susan Hares [mailto:shares@ndzh.com] 
Sent: Friday, August 26, 2016 9:28 AM
To: 'i2rs@ietf.org'
Cc: 'draft-ietf-i2rs-yang-l3-topology@ietf.org'; 'Alia Atlas'; 'russ@riw.us'
Subject: WG LC on draft-ietf-i2rs-yang-l3-topology-03.txt (8/26 to 9/9) 

 

 

This begins a 2 week WG LC on draft-ietf-i2rs-yang-l3-network-topo-05.txt
(8/26 to 9/9).  

 

The authors should indicate if they know of IPR on this draft by 8/31/2016.
In considering this draft, the WG should consider: 

 

1)      Does the implementations of this draft in ODL open source code base
sufficient experience on the Yang drafts? 

2)      Does anyone know of other implementations of this model? 

3)      Do you believe this Yang model is stable enough to publish and
distribute to yang libraries? 

 

Sue Hares and Russ White 

Co-chairs 

 

 


------=_NextPart_000_088F_01D1FF7E.1723F650
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable


The I2RS WG is starting a WG LC on the L3 =
network topology model and wishes input.  
 
Sue Hares and Russ White =

 
From:=
 =
Susan Hares [mailto:shares@ndzh.com] 
Sent: Friday, August 26, =
2016 9:28 AM
To: 'i2rs@ietf.org'
Cc: =
'draft-ietf-i2rs-yang-l3-topology@ietf.org'; 'Alia Atlas'; =
'russ@riw.us'
Subject: WG LC on =
draft-ietf-i2rs-yang-l3-topology-03.txt (8/26 to 9/9) =

 
 
This begins =
a 2 week WG LC on draft-ietf-i2rs-yang-l3-network-topo-05.txt (8/26 to =
9/9).  
 
The authors should indicate if they know of IPR on =
this draft by 8/31/2016.  In considering this draft, the WG should =
consider: 
 
1)      =
Does the implementations of this draft in ODL =
open source code base sufficient experience on the Yang drafts? =

2)      =
Does anyone know of other implementations of =
this model? 
3)      =
Do you believe this Yang model is stable enough =
to publish and distribute to yang libraries? 
 
Sue Hares =
and Russ White 
Co-chairs =

 
 

------=_NextPart_000_088F_01D1FF7E.1723F650--


From nobody Fri Aug 26 07:18: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 8B3D112B03B for ; Fri, 26 Aug 2016 07:18:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 UlEJVJSUn4qG for ; Fri, 26 Aug 2016 07:18:38 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 70B7112B05F for ; Fri, 26 Aug 2016 07:09:27 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id D57761AE018C; Fri, 26 Aug 2016 16:09:24 +0200 (CEST)
Date: Fri, 26 Aug 2016 16:08:29 +0200 (CEST)
Message-Id: <20160826.160829.966689922555224217.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
From: Martin Bjorklund 
In-Reply-To: <20160826125016.GA32908@elstar.local>
References: <062e01d1fd48$82309670$8691c350$@mg-soft.si> <20160826125016.GA32908@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Is this leafref path example valid in YANG 1?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 26 Aug 2016 14:18:43 -0000

Juergen Schoenwaelder  wrote:
> On Tue, Aug 23, 2016 at 04:13:23PM +0200, Jernej Tuljak wrote:
> > Hi,
> > 
> > this is a YANG 1, not 1.1 question. 
> 
> [...]
>  
> > Note the "path" expression that is referencing names that do not
> > seem to be in b's scope. Is this a valid "path" expression (names
> > resolved upon usage) or should all names inside the "grouping" be
> > resolved where the "grouping" is defined?
> 
> RFC 6020 says in section 7.12:
> 
>    The effect of a "uses" reference to a grouping is that the nodes
>    defined by the grouping are copied into the current schema tree, and
>    then updated according to the "refine" and "augment" statements.
> 
>    The identifiers defined in the grouping are not bound to a namespace
>    until the contents of the grouping are added to the schema tree via a
>    "uses" statement that does not appear inside a "grouping" statement,
>    at which point they are bound to the namespace of the current module.
> 
> This makes me believe that the uses statement should resolve things
> to this:
> 
> submodule a {
> 
>     belongs-to main {
>         prefix "a";
>     }
>     include b;
> 
>     container top {
>         leaf top-leaf {
>             type string;
>         }
>         leaf some-leaf {
>             type leafref {
>                 path "/top/top-leaf";
>             }
>         }
>     }
> }
> 
> Other opinions? The text quoted from RFC 6020 only talks specifically
> about identifiers but I would assume that the same late binding applies
> to path statement arguments.

This is issue #Y05.  The problem is that is not clear from RFC 6020
what the right answer is.

SO, the question was "is this legal YANG 1?", and the answer is
"unclear".  With the follow-up answer "if you need this, use YANG
1.1".



/martin


From nobody Fri Aug 26 10: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 6494012D1DD for ; Fri, 26 Aug 2016 10:25:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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 YySKq4l7zu8R for ; Fri, 26 Aug 2016 10:25:08 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 EE11612D1DA for ; Fri, 26 Aug 2016 10:25:07 -0700 (PDT)
X-AuditID: c1b4fb3a-0618b980000009bd-cd-57c07b710715
Received: from ESESSHC002.ericsson.se (Unknown_Domain [153.88.183.24]) by  (Symantec Mail Security) with SMTP id 4A.8B.02493.17B70C75; Fri, 26 Aug 2016 19:25:06 +0200 (CEST)
Received: from [159.107.197.196] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.26) with Microsoft SMTP Server id 14.3.301.0; Fri, 26 Aug 2016 19:25:04 +0200
To: Martin Bjorklund 
References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com> <20160826.102122.372934259558220723.mbj@tail-f.com>
From: Balazs Lengyel 
Message-ID: 
Date: Fri, 26 Aug 2016 19:25:04 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160826.102122.372934259558220723.mbj@tail-f.com>
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrCLMWRmVeSWpSXmKPExsUyM2K7hG5R9YFwgyttXBbd3c/YLeZfbGR1 YPJYsuQnk8fGX4tZApiiuGxSUnMyy1KL9O0SuDJeNF5jLXhlWjHly1qmBsa9ml2MnBwSAiYS bxZMZ+5i5OIQEljPKPF15wtWCGcto8TGRWdZQaqEBfQk7n3ZxwRiiwioSjzZuZYFxBYSKJWY t+o5O4jNLCAqsf7iJbAaNgEjian958FqeAXsJdrfP2QGsVmAere3tALFOThEBWIk1vclQJQI Spyc+QSsnFPAQaJ71ksWiJH6Etfv3GeFsOUlmrfOZoZYqyHx8MJf1gmMArOQtM9C0jILScsC RuZVjKLFqcXFuelGRnqpRZnJxcX5eXp5qSWbGIFheXDLb6sdjAefOx5iFOBgVOLhVTDaHy7E mlhWXJl7iFGCg1lJhLer4kC4EG9KYmVValF+fFFpTmrxIUZpDhYlcV7/l4rhQgLpiSWp2amp BalFMFkmDk6pBkZxHbM34q7Pr6dWHbYoEF16z0fbQObSlc+f+/nXev7j8Ne14K73sBR+XMvL M2/HHy4dtrbQExol/xhN4kWt6p0qtvi2Gga8fppcoJlas12uKztXwaeWe77cl1fVk35Hd26q ZVxjLHvof4nG9lyFTQavbx5wjljXZ3om66Xbv9XJiv5eT5ctVmIpzkg01GIuKk4EAOdHyMxH AgAA
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Design-Time 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: Fri, 26 Aug 2016 17:25:10 -0000


  
    
  
  
    
Hello Martin,

      As I see in your answer, you do not question that the design time
      mount is an important and possibly frequent use-case, and I
      certainly think it is. 

      I also found this on the Juniper website: What
        are the benefits of a Juniper devices publishing Junos YANG
        module off box?

      See other comments below.

      regards Balazs

      

      On 2016-08-26 10:21, Martin Bjorklund wrote:

    

    

      
Hi,

[replying to the first post in this (old) thread; the thread got a bit
off-topic]

Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:


      

        
Hello,

As I understand it, Schema-mount today does not support an important
use-case which we definitely need, but others also indicated they
want.

I want to specify off-line in design time which models will be mounted
where. Many of my nodes know in design-time what their model structure
will be, so I want a way to be able to document this in YANG.


      

      
I'd like to understand this use case in more detail.  You say that
that a "node knows in design-time" that YANG models it will use.  Thus
it seems natural to be able to specify which other modules to mount in
the YANG module itself.

The problem I see with this is that it is very limited to the use case
where each implementation defines its own YANG modules.  Suppose you
have such a model, for example:

   module A {
     ...
     mount ... {
       mount-module B;
       mount-module C;
     }
  }
      
[pseudo-code for module A that specifies that it mounts B and C]

Now, suppose you take this module A to another implementation, and it
needs to augment something into module C; essentially this means that
it would like to mount B, C and new module D.   This will not be
possible unless it modifies module A.

    

    BALAZS: No you don't need to modify module A. You can use a
    separate file 

      to define mounting modD into modA. Even my proposed
    solution allows this.

    
module mount-list {
 import moduleA { prefix moda; }
   import moduleD {}

   // indicate that moduleD is mounted somewhere
   schema-mount moduleD {  
      // indicate where it is mounted
      schema-mount-target /moda:baseContainer ;
   }
}

    

      



      

        
In
today's proposal the only way to find the Yang-Mounts is to read it
from the live node.

* OAM integrators or operators want to be able to write CLI scripts
  and Netconf messages without accessing (expensive) real nodes. For
  this they need to know the mounts
* We want to generate some fancy documentation from YANG automatically
  in design-time.


      

      
In a way this is no different from the situation today - in order to
learn what YANG modules a device supports you need to connect and
parse the <hello> message (or ietf-yang-library data in the near
future).  This info could also be made available off-line in a file.

    

    BALAZS: actually it is made available in our case, also describing
    support for features

    

      

It should certainly be possible to define a file format that a device
somehow could "publish" off-line that contained all the info that is
available at run-time.  This file format could be exactly the same as
you would get if you did a NETCONF <get/> operation with some filter
to only retreive the ietf-yang-library data at the mount points.

    

    BALAZS: That would be an INTERESTING idea for multiple reasons (and
    I know some implementations who already do this). 

    Some potential use-cases:

    - Mount descriptors

    - defining default security rules for Netconf-acm

    - listing available notification streams

    - listing supported modules & features from yang-library

    

      



/martin




      

        
* Many use cases need the possibility to mount schemas, but do not
  need the added complexity of schema changes in run-time.
  Notwithstanding the case of "YANG Features", for me the model schema
  is a mostly static description of a nodes capabilities. Most of the
  time I do not want to worry about the node changing its schema on
  the fly.


For this I propose 2 YANG extensions

extension schema-mount {
description "Indicates that a YANG Module is to be mounted into
another module.
The argument specifies the name of the module to be mounted.";
argument mounted-module;
}

extension schema-mount-target {
description "Specifies the target node under which a YANG module is to
be mounted.
The statement can only be used inside a schema-mount statement.
The argument follows the same rules as an augment statement's target.
argument target-node;
}

The two extension statements can be placed in a separate module or the
mounted module.

I don't insist on the solution, but I need the off-line/design-time
specification of yang-mount to be possible. IMHO the design-time mount
use-case is more important than the dynamic-mount.

regards Balazs
--
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


      

      

    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Fri Aug 26 10:53: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 EEF1512D505 for ; Fri, 26 Aug 2016 10:53:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YJHCA4ZpE373 for ; Fri, 26 Aug 2016 10:53:23 -0700 (PDT)
Received: from mail-ua0-x22d.google.com (mail-ua0-x22d.google.com [IPv6:2607:f8b0:400c:c08::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38C6312D14F for ; Fri, 26 Aug 2016 10:53:23 -0700 (PDT)
Received: by mail-ua0-x22d.google.com with SMTP id l94so87328419ual.0 for ; Fri, 26 Aug 2016 10:53:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=ERF2ho7SY/6hCcTuUgb/HKWvXsg0jSQ287zm0RoZnYY=; b=N+9iKN+PneR2TkvTN7/7tIyYanYp4uwvOzcXPbgVbDGQ/+GggQon4Q5EUPQdgRKmPm QuwLLWvSrIDUloVWtiLZ/fT4OEv9c9RB30ue9Ga9Mo86/a6s0N26FdpmgTqfcDVWetlj nPfFH5CpzW9KNsJtmfxw8gjm42MfkkTrODF625lVPRte90cQSh6P/yZMfj86RNi1tVJi FRpgdgHvtXB3it/Ji+Q7PXiGafZjMZY9XYxGJyNAbhOa+auy6pQj/L05ivyEanKRss7G JNYOTWWeoKqDCUa+2JenuK8ioUXPOttz32HXC4pkiJ2d86TNSp+uskDC06xrKk66Zqyb WmvA==
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:from:date :message-id:subject:to:cc; bh=ERF2ho7SY/6hCcTuUgb/HKWvXsg0jSQ287zm0RoZnYY=; b=iQGQTo4jqzfm91pwHP/nmUfBHnyZSY6TA97SO7A45oEeZxJXN3BFv3LMwmVUbfv/XA OWlfMxvAo2ODmrVTBmyNvif22pEdujMDd8jT8qSMlqOdLaEOViWS/Q27EwUbTQhR+u7T qahLz4iHhezhXC/bIyOVN6F1S23YUW2HwMpaZsm95ZtSyxxJuf+fnWHp5rbWlivW3CQo /pNS/tJCLMPruek5ZobzYbJ1/H5OItC+9L5k5zYeChSGe/WKK8xQzPb3WzWNG9zRg5Ef iWq0gSSokgkVHtet2F/pChKyD+ZSqNBccLoSPaoOLgx1yc4IxHgxXzyGuK8SF0HmqfVe K+zg==
X-Gm-Message-State: AE9vXwOjzYlrZkN53cLKznm5sqOuXaAHzmt2tiO//2BaPuUgEegUxFT1a2z62utcvBwcByxNzdY8IIchd1NJNA==
X-Received: by 10.31.192.2 with SMTP id q2mr2531907vkf.44.1472234002234; Fri, 26 Aug 2016 10:53:22 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.134 with HTTP; Fri, 26 Aug 2016 10:53:21 -0700 (PDT)
In-Reply-To: <20160826.143830.937655299426629223.mbj@tail-f.com>
References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com> <20160826.102122.372934259558220723.mbj@tail-f.com>  <20160826.143830.937655299426629223.mbj@tail-f.com>
From: Andy Bierman 
Date: Fri, 26 Aug 2016 10:53:21 -0700
Message-ID: 
To: Martin Bjorklund 
Content-Type: multipart/alternative; boundary=001a113bf06cbae4cc053afd30f9
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Design-Time 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: Fri, 26 Aug 2016 17:53:26 -0000

--001a113bf06cbae4cc053afd30f9
Content-Type: text/plain; charset=UTF-8

Hi,

I agree with Martin about not specifying which YANG modules
can be mounted under some mount point, in the YANG module.

The mount point needs some basic properties (like "config root", "opstate
root", whatever).
Then data nodes are classified somehow (e.g. config=true/false) and that
determines
what content can be mounted under that mount-point.

The combination of modules on the server needs to be a deployment decision
to
prevent issues like Martin describes below.


Andy


On Fri, Aug 26, 2016 at 5:38 AM, Martin Bjorklund  wrote:

> Ladislav Lhotka  wrote:
> > Martin Bjorklund  writes:
> >
> > > Hi,
> > >
> > > [replying to the first post in this (old) thread; the thread got a bit
> > > off-topic]
> > >
> > > Balazs Lengyel  wrote:
> > >> Hello,
> > >>
> > >> As I understand it, Schema-mount today does not support an important
> > >> use-case which we definitely need, but others also indicated they
> > >> want.
> > >>
> > >> I want to specify off-line in design time which models will be mounted
> > >> where. Many of my nodes know in design-time what their model structure
> > >> will be, so I want a way to be able to document this in YANG.
> > >
> > > I'd like to understand this use case in more detail.  You say that
> > > that a "node knows in design-time" that YANG models it will use.  Thus
> > > it seems natural to be able to specify which other modules to mount in
> > > the YANG module itself.
> >
> > Did you have a chance to look into my slides from Berlin? I sketched some
> > solutions there.
>
> Well, that's a *solution*.  I'd like to understand the *problem* first ;)
>
> > > The problem I see with this is that it is very limited to the use case
> > > where each implementation defines its own YANG modules.  Suppose you
> > > have such a model, for example:
> > >
> > >    module A {
> > >      ...
> > >      mount ... {
> > >        mount-module B;
> > >        mount-module C;
> > >      }
> > >   }
> > >
> > > [pseudo-code for module A that specifies that it mounts B and C]
> > >
> > > Now, suppose you take this module A to another implementation, and it
> > > needs to augment something into module C; essentially this means that
> > > it would like to mount B, C and new module D.   This will not be
> > > possible unless it modifies module A.
> >
> > Not necessarily, D could contain an augment with a target specified by a
> > schema node identifier that uses nodes from both A and C.
>
> Not if B and D are defined as standalone modules, e.g. if B is
> ietf-interfaces and D is ietf-ip.
>
> > Imagine that instead of "ietf-ip" augmenting "ietf-interfaces" it would
> > be the other way around: "ietf-interfaces" mounts "ietf-ip". Then the
> > augment in ietf-ipv6-router-advertisements
> >
> >   augment "/if:interfaces-state/if:interface/ip:ipv6" { ... }
> >
> > needn't be changed.
>
> This would be an entirely different kind of mount!  The current mount
> doesn't work like that; it doesn't give you visibility into the
> combined models - by design.
>
>
> > The major problem with this IMO is that it needs a new YANG statement.
> >
> > >
> > >> In
> > >> today's proposal the only way to find the Yang-Mounts is to read it
> > >> from the live node.
> > >>
> > >> * OAM integrators or operators want to be able to write CLI scripts
> > >>   and Netconf messages without accessing (expensive) real nodes. For
> > >>   this they need to know the mounts
> > >> * We want to generate some fancy documentation from YANG automatically
> > >>   in design-time.
> > >
> > > In a way this is no different from the situation today - in order to
> > > learn what YANG modules a device supports you need to connect and
> > > parse the  message (or ietf-yang-library data in the near
> > > future).  This info could also be made available off-line in a file.
> >
> > Yup. So we just need some machine-readable description of the structure
> > of mounted schemas.
> >
> > >
> > > It should certainly be possible to define a file format that a device
> > > somehow could "publish" off-line that contained all the info that is
> > > available at run-time.  This file format could be exactly the same as
> > > you would get if you did a NETCONF  operation with some filter
> > > to only retreive the ietf-yang-library data at the mount points.
> >
> > Well, if you have multiple levels of mounts, it will get messy: you
> > wouldn't know which yang-library data belongs to which mount point.
>
> Why not - imagine that you do a full  on such a device, it will
> return the nested yang library data just fine.
>
>
> /martin
>
>
> > I believe some variation on YSDL could work, and as I wrote in another
> > thread, we could also incorporate datastores: after defining the
> > (multilevel) schemas, each datastore will get one assigned - and they
> > can also share them where needed.
> >
> > Lada
> >
> > >
> > >
> > >
> > > /martin
> > >
> > >
> > >>
> > >> * Many use cases need the possibility to mount schemas, but do not
> > >>   need the added complexity of schema changes in run-time.
> > >>   Notwithstanding the case of "YANG Features", for me the model schema
> > >>   is a mostly static description of a nodes capabilities. Most of the
> > >>   time I do not want to worry about the node changing its schema on
> > >>   the fly.
> > >>
> > >>
> > >> For this I propose 2 YANG extensions
> > >>
> > >> extension schema-mount {
> > >> description "Indicates that a YANG Module is to be mounted into
> > >> another module.
> > >> The argument specifies the name of the module to be mounted.";
> > >> argument mounted-module;
> > >> }
> > >>
> > >> extension schema-mount-target {
> > >> description "Specifies the target node under which a YANG module is to
> > >> be mounted.
> > >> The statement can only be used inside a schema-mount statement.
> > >> The argument follows the same rules as an augment statement's target.
> > >> argument target-node;
> > >> }
> > >>
> > >> The two extension statements can be placed in a separate module or the
> > >> mounted module.
> > >>
> > >> I don't insist on the solution, but I need the off-line/design-time
> > >> specification of yang-mount to be possible. IMHO the design-time mount
> > >> use-case is more important than the dynamic-mount.
> > >>
> > >> regards Balazs
> > >> --
> > >> Balazs Lengyel                       Ericsson Hungary Ltd.
> > >> Senior Specialist
> > >> Mobile: +36-70-330-7909              email:
> Balazs.Lengyel@ericsson.com
> > >
> > > _______________________________________________
> > > 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
>

--001a113bf06cbae4cc053afd30f9
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I agree with Martin about not speci=
fying which YANG modules
can be mounted under some mount point, i=
n the YANG module.

The mount point needs some basi=
c properties (like "config root", "opstate root", whate=
ver).
Then data nodes are classified somehow (e.g. config=3Dtrue/=
false) and that determines
what content can be mounted under that=
 mount-point.

The combination of modules on the se=
rver needs to be a deployment decision to
prevent issues like Mar=
tin describes below.


Andy


=
On Fri, Aug 26, 2016 at 5:38 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
Ladislav Lhotka <lhotka@nic.cz> wrote:

> Martin Bjorklund <mbj@tail-f.com<=
/a>> writes:

>

> > Hi,

> >

> > [replying to the first post in this (old) thread; the thread got =
a bit

> > off-topic]

> >

> > Balazs Lengyel <balazs.lengyel@ericsson.com> wrote:

> >> Hello,

> >>

> >> As I understand it, Schema-mount today does not support an im=
portant

> >> use-case which we definitely need, but others also indicated =
they

> >> want.

> >>

> >> I want to specify off-line in design time which models will b=
e mounted

> >> where. Many of my nodes know in design-time what their model =
structure

> >> will be, so I want a way to be able to document this in YANG.=


> >

> > I'd like to understand this use case in more detail.=C2=A0 Yo=
u say that

> > that a "node knows in design-time" that YANG models it =
will use.=C2=A0 Thus

> > it seems natural to be able to specify which other modules to mou=
nt in

> > the YANG module itself.

>

> Did you have a chance to look into my slides from Berlin? I sketched s=
ome

> solutions there.



Well, that's a *solution*.=C2=A0 I'd like to understand the *proble=
m* first ;)



> > The problem I see with this is that it is very limited to the use=
 case

> > where each implementation defines its own YANG modules.=C2=A0 Sup=
pose you

> > have such a model, for example:

> >

> >=C2=A0 =C2=A0 module A {

> >=C2=A0 =C2=A0 =C2=A0 ...

> >=C2=A0 =C2=A0 =C2=A0 mount ... {

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 mount-module B;

> >=C2=A0 =C2=A0 =C2=A0 =C2=A0 mount-module C;

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

> >=C2=A0 =C2=A0}

> >

> > [pseudo-code for module A that specifies that it mounts B and C]<=
br>
> >

> > Now, suppose you take this module A to another implementation, an=
d it

> > needs to augment something into module C; essentially this means =
that

> > it would like to mount B, C and new module D.=C2=A0 =C2=A0This wi=
ll not be

> > possible unless it modifies module A.

>

> Not necessarily, D could contain an augment with a target specified by=
 a

> schema node identifier that uses nodes from both A and C.



Not if B and D are defined as standalone modules, e.g. if B is

ietf-interfaces and D is ietf-ip.



> Imagine that instead of "ietf-ip" augmenting "ietf-inte=
rfaces" it would

> be the other way around: "ietf-interfaces" mounts "ietf=
-ip". Then the

> augment in ietf-ipv6-router-advertisements

>

>=C2=A0 =C2=A0augment "/if:interfaces-state/if:interface/ip:ip=
v6" { ... }

>

> needn't be changed.



This would be an entirely different kind of mount!=C2=A0 The current mount<=
br>
doesn't work like that; it doesn't give you visibility into the

combined models - by design.





> The major problem with this IMO is that it needs a new YANG statement.=


>

> >

> >> In

> >> today's proposal the only way to find the Yang-Mounts is =
to read it

> >> from the live node.

> >>

> >> * OAM integrators or operators want to be able to write CLI s=
cripts

> >>=C2=A0 =C2=A0and Netconf messages without accessing (expensive=
) real nodes. For

> >>=C2=A0 =C2=A0this they need to know the mounts

> >> * We want to generate some fancy documentation from YANG auto=
matically

> >>=C2=A0 =C2=A0in design-time.

> >

> > In a way this is no different from the situation today - in order=
 to

> > learn what YANG modules a device supports you need to connect and=


> > parse the <hello> message (or ietf-yang-library data in the=
 near

> > future).=C2=A0 This info could also be made available off-line in=
 a file.

>

> Yup. So we just need some machine-readable description of the structur=
e

> of mounted schemas.

>

> >

> > It should certainly be possible to define a file format that a de=
vice

> > somehow could "publish" off-line that contained all the=
 info that is

> > available at run-time.=C2=A0 This file format could be exactly th=
e same as

> > you would get if you did a NETCONF <get/> operation with so=
me filter

> > to only retreive the ietf-yang-library data at the mount points.<=
br>
>

> Well, if you have multiple levels of mounts, it will get messy: you
> wouldn't know which yang-library data belongs to which mount point=
.



Why not - imagine that you do a full <get/> on such a device, it will=


return the nested yang library data just fine.





/martin





> I believe some variation on YSDL could work, and as I wrote in another=


> thread, we could also incorporate datastores: after defining the

> (multilevel) schemas, each datastore will get one assigned - and they<=
br>
> can also share them where needed.

>

> Lada

>

> >

> >

> >

> > /martin

> >

> >

> >>

> >> * Many use cases need the possibility to mount schemas, but d=
o not

> >>=C2=A0 =C2=A0need the added complexity of schema changes in ru=
n-time.

> >>=C2=A0 =C2=A0Notwithstanding the case of "YANG Features&q=
uot;, for me the model schema

> >>=C2=A0 =C2=A0is a mostly static description of a nodes capabil=
ities. Most of the

> >>=C2=A0 =C2=A0time I do not want to worry about the node changi=
ng its schema on

> >>=C2=A0 =C2=A0the fly.

> >>

> >>

> >> For this I propose 2 YANG extensions

> >>

> >> extension schema-mount {

> >> description "Indicates that a YANG Module is to be mount=
ed into

> >> another module.

> >> The argument specifies the name of the module to be mounted.&=
quot;;

> >> argument mounted-module;

> >> }

> >>

> >> extension schema-mount-target {

> >> description "Specifies the target node under which a YAN=
G module is to

> >> be mounted.

> >> The statement can only be used inside a schema-mount statemen=
t.

> >> The argument follows the same rules as an augment statement&#=
39;s target.

> >> argument target-node;

> >> }

> >>

> >> The two extension statements can be placed in a separate modu=
le or the

> >> mounted module.

> >>

> >> I don't insist on the solution, but I need the off-line/d=
esign-time

> >> specification of yang-mount to be possible. IMHO the design-t=
ime mount

> >> use-case is more important than the dynamic-mount.

> >>

> >> regards Balazs

> >> --

> >> Balazs Lengyel=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Ericsson Hungary Ltd.

> >> Senior Specialist

> >> Mobile: +36-70-330-7909=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0 =C2=A0 email: Balazs.Len=
gyel@ericsson.com

> >

> > _______________________________________________

> > netmod mailing list

> > netmod@ietf.org

> > https://www.ietf.org/mailman/listinfo/net=
mod

>

> --

> Ladislav Lhotka, CZ.NIC Labs

> PGP Key ID: E74E8C0C

>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a113bf06cbae4cc053afd30f9--


From nobody Fri Aug 26 10:54: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 835F012D14F for ; Fri, 26 Aug 2016 10:54:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.911
X-Spam-Level: 
X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 1bxDBSUzhXnl for ; Fri, 26 Aug 2016 10:54:28 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0116.outbound.protection.outlook.com [104.47.32.116]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5992712D505 for ; Fri, 26 Aug 2016 10:54:28 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=4uMRzdS9uCaH5MXl7R93mSDMVyMCdJdHBd7D9V3dYJw=; b=HCiPNSeEHnwX+epGAGgNk36sQ7m8zxa4EFJzk2IMr51NqoLfDGzfIRCXAU64YQxhvX8kevpN18Sb3sC2Ld0kmi0eMsAYuh37Twp2Nlgzucr2bwpN4cyTGG2MHJrO1Kf1qkVUAWpp7GxdYzIaiMMDa5JhPN4ADwE5+/k1U0T55P8=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.2; Fri, 26 Aug 2016 17:54:25 +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.0599.001; Fri, 26 Aug 2016 17:54:25 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9,  2016)
Thread-Index: AQHR/8LivjdTqPfoxUWmbjRsB+ww7Q==
Date: Fri, 26 Aug 2016 17:54:25 +0000
Message-ID: <08A2A580-BEA2-4AF0-9FFB-0F995B9DC778@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: 16c313aa-6173-49a7-41bc-08d3cdda04d2
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1455; 6:Rls3M0qfl0vJZmHzX1LF8L7PB/57r9NYoJeIbOEWk4tFVG09d/FHuGl5OB55Kq+asP5E0gLCqiUAFwxZ33acskt8YP1MQiV8xDEw//ENXj7HAExJshk8cI84AJ6Pdmdlgj10MZzgfrTlGD4mKbEYU6Nj8NmmWz0Z/r7QybvFoEk6mCyWsKIrjr/+l68vAJ8yMvEPfrXJMwsVbdEvAdcXFkS+lIdI7oGiCjy5rNmn1xaZlX7IQeTFoilJdAopwAd6zjhyAoWziUD42+706RkvAiVG/WLc5MC37lnkWRycvA7fv3+hVfU8nnKknkNPhVI1zyEjCUrtGqQcrMp33xDhBQ==; 5:NoRhBOPp2kpICMyUrd45BNSIFpW3Z4NARE+42ggtP+j80+NiCR848O6MG+kOpOCVnfB3U8yirzwCn196EZnx0a39KTktJ9KKNRk1ENPyy2HeyNucuF3J5vX9qbl4W3WyEMRxprLxtDrH6EF/QDDFJ2EO9UQF6AsZgKnDxJ3U7hg=; 24:2Bblb05g3vb08JPJs/VeXTTHHU7zHpmRIn77yRiB9S/S2Xwsz7yNKrcVNZ4LCF0vGofC7ZJdVswyYJRmzwyth0E6cv/Dmsq54mJT0ATQBs4=; 7:C4DqL8VM8cMUa/4bWHFOqt/1BgrgWS2DHX+Q3jZMRCuvNm3+Cp7LMqYagWEJ0QaHOWDmnz9ii/oVT2hLuOITojWy4bfdA2S5wAmMuCzYrvMCOBp+jN4HSFY0Q83ktpRrCLNJE+xdZJBWSsQp6gdPAQXTGQjZoZD7ISQ8UYWIB3WN0yB+cqhmTwmwSuDpa0LfiTnllU8+r3uJuUJG3tcRyN+aIpMeHJ/7j4y14LQX4HS+Cc9r9jWaPmyfuU7MZ7N1
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1455;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(20558992708506)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM2PR0501MB1455; BCL:0; PCL:0; RULEID:(304825118); SRVR:DM2PR0501MB1455; 
x-forefront-prvs: 00462943DE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(83506001)(106116001)(101416001)(189998001)(86362001)(92566002)(54356999)(10400500002)(107886002)(77096005)(50986999)(97736004)(4001350100001)(110136002)(5002640100001)(15975445007)(66066001)(106356001)(99286002)(2501003)(105586002)(2900100001)(5660300001)(19625215002)(16236675004)(81166006)(83716003)(11100500001)(68736007)(122556002)(586003)(36756003)(19580395003)(33656002)(7846002)(230783001)(87936001)(8936002)(229853001)(1730700003)(5640700001)(2351001)(19300405004)(2906002)(7736002)(3660700001)(8676002)(81156014)(102836003)(6116002)(82746002)(450100001)(3280700002)(3846002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1455; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_08A2A580BEA24AF09FFB0F995B9DC778junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2016 17:54:25.4473 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1455
Archived-At: 
Subject: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 17:54:30 -0000

--_000_08A2A580BEA24AF09FFB0F995B9DC778junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

DQpUaGlzIGlzIGEgbm90aWNlIHRvIHN0YXJ0IGEgdHdvLXdlZWsgTkVUTU9EIFdHIGxhc3QgY2Fs
bCBmb3IgdGhlIGRvY3VtZW50Og0KDQogICAgICAgICAgICAgICAgQSBZQU5HIERhdGEgTW9kZWwg
Zm9yIFJvdXRpbmcgTWFuYWdlbWVudA0KICAgICAgICAgICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0
Zi5vcmcvaHRtbC9kcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0yMw0KDQpQbGVhc2UgaW5k
aWNhdGUgeW91ciBzdXBwb3J0IG9yIGNvbmNlcm5zIGJ5IFRodXJzZGF5IFNlcHRlbWJlciA5LCAy
MDE2Lg0KDQpXZSBhcmUgbm90IG9ubHkgaW50ZXJlc3RlZCBpbiByZWNlaXZpbmcgZGVmZWN0IHJl
cG9ydHMsIHdlIGFyZSBlcXVhbGx5IGludGVyZXN0ZWQgaW4gc3RhdGVtZW50cyBvZiB0aGUgZm9y
bToNCg0KICAqIEkgaGF2ZSByZXZpZXdlZCBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0y
MyBhbmQgSSBmb3VuZCBubyBpc3N1ZXMNCiAgKiBJIGhhdmUgaW1wbGVtZW50ZWQgdGhlIGRhdGEg
bW9kZWwgaW4gZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMjMNCiAgKiBJIGFtIGltcGxl
bWVudGluZyB0aGUgZGF0YSBtb2RlbCBpbiBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0y
Mw0KICAqIEkgYW0gY29uc2lkZXJpbmcgdG8gaW1wbGVtZW50IHRoZSBkYXRhIG1vZGVsIGluIGRy
YWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTIzDQoNCk9mIGNvdXJzZSwgdGhlc2UgYXJlIG1l
cmVseSBzdWdnZXN0aW9ucywgZm9sa3MgY2FuIHByb3ZpZGUgY29tbWVudHMgaW4gYW55IGZvcm0g
dGhhdCBzdWl0cyB0aGVtLg0KDQoNClRoYW5rIHlvdSwNCg0KTkVUTU9EIFdHIENoYWlycw0KDQoN
Cg==

--_000_08A2A580BEA24AF09FFB0F995B9DC778junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtY29tcG9zZTsNCglmb250LWZhbWlseTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3Rl
eHQ7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENo
YXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4
dCI7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlw
ZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5k
ZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6
ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpAcGFnZSBXb3JkU2VjdGlvbjEN
Cgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30N
CmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjwv
aGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iIzA1NjNDMSIg
dmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+VGhpcyBpcyBhIG5vdGljZSB0byBzdGFydCBhIHR3by13ZWVrIE5FVE1PRCBXRyBs
YXN0IGNhbGwgZm9yIHRoZSBkb2N1bWVudDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBIFlBTkcgRGF0
YSBNb2RlbCBmb3IgUm91dGluZyBNYW5hZ2VtZW50PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJh
ZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMjM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZToxMS4wcHQiPlBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3IgY29uY2VybnMg
YnkgVGh1cnNkYXkgU2VwdGVtYmVyIDksIDIwMTYuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxvOnA+Jm5i
c3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6MTEuMHB0Ij5XZSBhcmUgbm90IG9ubHkgaW50ZXJlc3RlZCBpbiByZWNlaXZpbmcg
ZGVmZWN0IHJlcG9ydHMsIHdlIGFyZSBlcXVhbGx5IGludGVyZXN0ZWQgaW4gc3RhdGVtZW50cyBv
ZiB0aGUgZm9ybTo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyAqIEkgaGF2ZSByZXZpZXdlZCBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0yMyBh
bmQgSSBmb3VuZCBubyBpc3N1ZXM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7ICogSSBoYXZlIGlt
cGxlbWVudGVkIHRoZSBkYXRhIG1vZGVsIGluIGRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2Zn
LTIzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAqIEkgYW0gaW1wbGVtZW50aW5nIHRoZSBkYXRh
IG1vZGVsIGluIGRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTIzPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4w
cHQiPiZuYnNwOyAqIEkgYW0gY29uc2lkZXJpbmcgdG8gaW1wbGVtZW50IHRoZSBkYXRhIG1vZGVs
IGluIGRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTIzPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6MTEuMHB0Ij5PZiBjb3Vyc2UsIHRoZXNlIGFyZSBtZXJlbHkgc3VnZ2Vz
dGlvbnMsIGZvbGtzIGNhbiBwcm92aWRlIGNvbW1lbnRzIGluIGFueSBmb3JtIHRoYXQgc3VpdHMg
dGhlbS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb1BsYWluVGV4dCI+VGhhbmsgeW91LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+TkVUTU9EIFdHIENoYWlyczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_08A2A580BEA24AF09FFB0F995B9DC778junipernet_--


From nobody Fri Aug 26 10:58: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 845E812D504; Fri, 26 Aug 2016 10:58: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, 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 zypu8hlFUGK9; Fri, 26 Aug 2016 10:58:21 -0700 (PDT)
Received: from NAM01-SN1-obe.outbound.protection.outlook.com (mail-sn1nam01on0134.outbound.protection.outlook.com [104.47.32.134]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEC1512D1D0; Fri, 26 Aug 2016 10:58:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=B8xa+o7Wcu3L3TVf1+xVlFlybTFvSiWBKlvuCbBJAGk=; b=RZNac/svO0ZYTjRnGFOmJdAEIZ8FFMYsDja554Zv4UVg+/eoxz6wc4vVkY3oVHjMDgKml92mSi8dwcUDr2vBxvkBKtkldSA+AVMya6/fCy7klWelxX+BP+QJhU1NvKTpGX+eO1q1UVncyYbCc1a83tUBSWsRDFiTPR7FeTDrk4M=
Received: from DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) by DM2PR0501MB1455.namprd05.prod.outlook.com (10.161.224.152) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.2; Fri, 26 Aug 2016 17:58: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.0599.001; Fri, 26 Aug 2016 17:58:19 +0000
From: Kent Watsen 
To: Ladislav Lhotka , "Acee Lindem (acee)" 
Thread-Topic: Regarding IPR on draft-ietf-netmod-routing-cfg-23
Thread-Index: AQHR/8NtBYbihfSd2UO+EQ0BQo+j6A==
Date: Fri, 26 Aug 2016 17:58:19 +0000
Message-ID: <5E95D548-556B-481F-BC97-4C7E2FB876CF@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.11]
x-ms-office365-filtering-correlation-id: c884a3f8-df83-410f-921f-08d3cdda9006
x-microsoft-exchange-diagnostics: 1; DM2PR0501MB1455; 6:rNDu671m1GJV9LY3a6RRbPwpcjgu9JGMXniQbMnF1kdCc+PzcOumGG0k6y59eYWOhKVV6GA2/PTEbu/q2Ofef7OCrAPQb/SRtJPfeBkQeTETy7MfjjQyd22hqb6chnl7HXeoEOjPou83Du5rGNHtNGyKixcxOmdhwNG+QQbvW+ywU2JNXDq+gYzGT7KRhaRvbLyaUyo3lWs7Cp9C6BhT2ZlMwEWGvOk0V37ljsIJmMH173/4AaLwdrytCDUtZJTDYO7nVZFU0laACe7prfizmlnvBbgv7/vVL9DtV8swCPtQ5D0/K5yoLOGcz/YSA6UWRBK1A3rBDkwnSQiCpaR2TQ==; 5:Lg0XbXogs/Ug23WmgbwTgnncgM9GBpUKJcbm7fpjnEJ5oaieEjsxJCousaat9LuVso2EyMzz2v8r+9GhA7Hv8vgvWRCmsKDmaeaVfQmU56o6Wj9RHTwjz7CkUoyNJg7fRxfHDva34LAybLyG4CYItg==; 24:ZHcHkxfEprQ6bnUhpfbC1vpG1wMcd+jid2YphNkBCQUxfqgn6xRfvMtSVxw8JnpCwJ9Q92Ic9a/fB7Gxbb7xohrvDlm2bq219GLvhjKhec4=; 7:KMcDMUJLeo/sUjUZr9EGBFQcE11qJDiYZQT+U/Ldi+cQtGa38ZvMHfQBLVWskVKyCfPO4ByRAZNJ77uyvWFwvHSZlz5p+Q2MaFQ6h5YGiFzZGuSYs6+8+RujuiZ8Rslvwf2dOmRaMJBfm9Uc0w4wQNDl8uIYoIFMAVmFKU9C0JophVrEdsEtXTidSZsDh69vFL9DnWX1hfR4Fnbth1By9jik96bZ+JCCpUmyjmzv/J6E8iXb57Pt9Tc+GSOyiSaf
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:DM2PR0501MB1455;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:DM2PR0501MB1455; BCL:0; PCL:0; RULEID:; SRVR:DM2PR0501MB1455; 
x-forefront-prvs: 00462943DE
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(189002)(199003)(83506001)(106116001)(101416001)(189998001)(86362001)(92566002)(5001770100001)(54356999)(10400500002)(77096005)(50986999)(97736004)(4001350100001)(5002640100001)(15975445007)(66066001)(106356001)(99286002)(105586002)(2900100001)(5660300001)(19625215002)(16236675004)(81166006)(83716003)(11100500001)(68736007)(122556002)(586003)(36756003)(19580395003)(33656002)(7846002)(230783001)(87936001)(8936002)(229853001)(19300405004)(4326007)(2906002)(7736002)(3660700001)(8676002)(81156014)(102836003)(6116002)(82746002)(3280700002)(3846002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM2PR0501MB1455; H:DM2PR0501MB1455.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_5E95D548556B481FBC974C7E2FB876CFjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 26 Aug 2016 17:58:19.0254 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1455
Archived-At: 
Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" 
Subject: [netmod] Regarding IPR on draft-ietf-netmod-routing-cfg-23
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 17:58:24 -0000

--_000_5E95D548556B481FBC974C7E2FB876CFjunipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0KDQoNCkFzIHBhcnQgb2YgdGhlIFdHIExhc3Qg
Q2FsbCwgYXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byBkcmFmdCBpZGVu
dGlmaWVkIGFib3ZlPyAgUGxlYXNlIHN0YXRlIGVpdGhlcjoNCg0KICAqICJObywgSSdtIG5vdCBh
d2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0Ig0KDQogICogIlllcywg
SSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCINCg0KDQoNCklmIOKA
nHllc+KAnSwgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0aCBJ
RVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3IgbW9y
ZSBkZXRhaWxzKT8gICBQbGVhc2Ugc3RhdGUgZWl0aGVyOg0KDQogICogIlllcywgdGhlIElQUiBo
YXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIg0KDQog
ICogIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9zZWQiDQoNCg0KDQpJZiB5b3UgYW5z
d2VyIOKAnG5v4oCdLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRkaXRpb25hbCBkZXRhaWxzIHlvdSB0
aGluayBhcHByb3ByaWF0ZS4NCg0KDQoNCklmIHlvdSBhcmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQg
YXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCBwbGVhc2UgYW5zd2VyIHRoZSBhYm92ZSBieSByZXNwb25k
aW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3
YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0
byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20g
ZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRP
IEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTIFRPIExJTkVTLg0KDQoNCg0KSWYg
eW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRlbmQgV0cgbWVldGluZ3MgYnV0IGFy
ZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmlidXRvciwgd2UgcmVtaW5kIHlvdSBv
ZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQUiBydWxlcyB3aGljaCBlbmNvdXJh
Z2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFyZSBhd2FyZSBvZiBJUFIgb2Ygb3Ro
ZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBh
dGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVu
ZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3Mg
bGlzdGVkIGFib3ZlIGFuZCBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3Ry
YWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0KDQoNClBTOiBQbGVhc2UgaW5jbHVkZSBh
bGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5b3VyIHJlc3BvbnNl
Lg0KDQoNCg0KVGhhbmsgeW91LA0KDQpORVRNT0QgV0cgQ2hhaXJzDQoNCg0KDQoNCg0KDQo=

--_000_5E95D548556B481FBC974C7E2FB876CFjunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <0DC30B358C270447B2C5FA7082A5A4A0@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTcNCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWw7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCnNw
YW4uUGxhaW5UZXh0Q2hhcg0KCXttc28tc3R5bGUtbmFtZToiUGxhaW4gVGV4dCBDaGFyIjsNCglt
c28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IlBsYWluIFRleHQiOw0KCWZv
bnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0
LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsN
Cgljb2xvcjp0ZWFsO30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1v
bmx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6
OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29y
ZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8
Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0iRU4tVVMiIGxpbms9IiMwNTYzQzEiIHZsaW5rPSIj
OTU0RjcyIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij5BdXRob3JzLCBDb250cmlidXRvcnMsIFdHLDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5U
ZXh0Ij5BcyBwYXJ0IG9mIHRoZSBXRyBMYXN0IENhbGwsIGFyZSB5b3UgYXdhcmUgb2YgYW55IElQ
UiB0aGF0IGFwcGxpZXMgdG8gZHJhZnQgaWRlbnRpZmllZCBhYm92ZT8mbmJzcDsgUGxlYXNlIHN0
YXRlIGVpdGhlcjo8L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgKiAmcXVvdDtO
bywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlzIGRyYWZ0JnF1
b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgKiAmcXVv
dDtZZXMsIEknbSBhd2FyZSBvZiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQmcXVvdDs8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SWYg4oCceWVz4oCdLCBoYXMgdGhpcyBJUFIg
YmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzIChzZWUgUkZD
cyAzOTc5LCA0ODc5LCAzNjY5IGFuZCA1Mzc4IGZvciBtb3JlIGRldGFpbHMpPyAmbmJzcDsmbmJz
cDtQbGVhc2Ugc3RhdGUgZWl0aGVyOjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+Jm5ic3A7ICogJnF1b3Q7WWVzLCB0aGUgSVBSIGhhcyBiZWVuIGRpc2Nsb3NlZCBpbiBj
b21wbGlhbmNlIHdpdGggSUVURiBJUFIgcnVsZXMmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNs
YXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyAqICZxdW90O05vLCB0aGUgSVBSIGhhcyBub3QgYmVl
biBkaXNjbG9zZWQmcXVvdDs8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQi
PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+SWYgeW91IGFu
c3dlciDigJxub+KAnSwgcGxlYXNlIHByb3ZpZGUgYW55IGFkZGl0aW9uYWwgZGV0YWlscyB5b3Ug
dGhpbmsgYXBwcm9wcmlhdGUuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHlvdSBh
cmUgbGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCBwbGVhc2UgYW5z
d2VyIHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3
aGV0aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9j
dW1lbnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNl
DQogaGFzIGJlZW4gcmVjZWl2ZWQgZnJvbSBlYWNoIGF1dGhvciBhbmQgbGlzdGVkIGNvbnRyaWJ1
dG9yLiBOT1RFOiBUSElTIEFQUExJRVMgVE8gQUxMIE9GIFlPVSBMSVNURUQgSU4gVEhJUyBNRVNT
QUdFJ1MgVE8gTElORVMuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48
bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklmIHlvdSBhcmUg
b24gdGhlIFdHIGVtYWlsIGxpc3Qgb3IgYXR0ZW5kIFdHIG1lZXRpbmdzIGJ1dCBhcmUgbm90IGxp
c3RlZCBhcyBhbiBhdXRob3Igb3IgY29udHJpYnV0b3IsIHdlIHJlbWluZCB5b3Ugb2YgeW91ciBv
YmxpZ2F0aW9ucyB1bmRlciB0aGUgSUVURiBJUFIgcnVsZXMgd2hpY2ggZW5jb3VyYWdlcyB5b3Ug
dG8gbm90aWZ5IHRoZSBJRVRGIGlmIHlvdSBhcmUgYXdhcmUgb2YgSVBSIG9mIG90aGVycw0KIG9u
IGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byByZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBp
biBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Npb24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xv
c2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24sIHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVk
IGFib3ZlIGFuZCBodHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lr
aS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFp
blRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+UFM6
IFBsZWFzZSBpbmNsdWRlIGFsbCBsaXN0ZWQgaW4gdGhlIGhlYWRlcnMgb2YgdGhpcyBtZXNzYWdl
IGluIHlvdXIgcmVzcG9uc2UuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlRoYW5rIHlv
dSw8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPk5FVE1PRCBXRyBDaGFp
cnM8bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9v
OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_5E95D548556B481FBC974C7E2FB876CFjunipernet_--


From nobody Fri Aug 26 12:36: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 4D6CD12D7B4; Fri, 26 Aug 2016 12:35:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.068
X-Spam-Level: 
X-Spam-Status: No, score=-15.068 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.548, 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 KBvRc8Hmbj_U; Fri, 26 Aug 2016 12:35:54 -0700 (PDT)
Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E44012D7CD; Fri, 26 Aug 2016 12:35:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11973; q=dns/txt; s=iport; t=1472240154; x=1473449754; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=5i3TmuzEy0mn8TQa5SR37kFsYA3GgEyXdxRvwMRomJw=; b=LnzxeDJk/Ldq0pawfk5hq3tisf0P5fIhKd4htDNvDv5N+rORs13lwXuc 1CLHDxTzbJ2yhfy5EBPOiKFMkRSzbi+oxKbJfaLfbhNimL1yZwjJXLFR1 HXGdc1Pu/clJKQc3LgFcs+MzB8vE8t7IlFlG6mZh1qlzBT4DpNL48QOYm c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AlAgC2mcBX/5hdJa1dGgEBAQGCcDMBA?= =?us-ascii?q?QEBAR5WfAeNKKVvhQmCASSFeQIcgTQ4FAEBAQEBAQEBAQFeJ4RhAQEBBCNRBRA?= =?us-ascii?q?CAQgOAwMBAigDAgICMBQJCAIEAQ0FiDgOsA6PNQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARyKe4QSEQEzCYJigloFmUwBhh+JCYFtToQPiQiMQ4N4AQ8PNoQccAGELIE?= =?us-ascii?q?gfwEBAQ?=
X-IronPort-AV: E=Sophos;i="5.28,582,1464652800";  d="scan'208,217";a="315718325"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Aug 2016 19:35:53 +0000
Received: from XCH-RTP-013.cisco.com (xch-rtp-013.cisco.com [64.101.220.153]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u7QJZqpg015104 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Fri, 26 Aug 2016 19:35:53 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.1210.3; Fri, 26 Aug 2016 15:35:52 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Fri, 26 Aug 2016 15:35:52 -0400
From: "Acee Lindem (acee)" 
To: Kent Watsen , Ladislav Lhotka 
Thread-Topic: Regarding IPR on draft-ietf-netmod-routing-cfg-23
Thread-Index: AQHR/8NtBYbihfSd2UO+EQ0BQo+j6KBbopAA
Date: Fri, 26 Aug 2016 19:35:51 +0000
Message-ID: 
References: <5E95D548-556B-481F-BC97-4C7E2FB876CF@juniper.net>
In-Reply-To: <5E95D548-556B-481F-BC97-4C7E2FB876CF@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.116.152.198]
Content-Type: multipart/alternative; boundary="_000_D3E612227B6E6aceeciscocom_"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" , Routing WG 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-routing-cfg-23
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 19:35:57 -0000

--_000_D3E612227B6E6aceeciscocom_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

U3BlYWtlciBhcyBhbiBhdXRob3IsDQoNCk5vLCBJIGFtIG5vdCBhd2FyZSBvZiBhbiBJUFIgdGhh
dCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQuDQoNClRoYW5rcywNCkFjZWUNCg0KRnJvbTogS2VudCBX
YXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+Pg0K
RGF0ZTogRnJpZGF5LCBBdWd1c3QgMjYsIDIwMTYgYXQgMTo1OCBQTQ0KVG86IExhZGlzbGF2IExo
b3RrYSA8bGhvdGthQG5pYy5jejxtYWlsdG86bGhvdGthQG5pYy5jej4+LCBBY2VlIExpbmRlbSA8
YWNlZUBjaXNjby5jb208bWFpbHRvOmFjZWVAY2lzY28uY29tPj4NCkNjOiAibmV0bW9kQGlldGYu
b3JnPG1haWx0bzpuZXRtb2RAaWV0Zi5vcmc+IiA8bmV0bW9kQGlldGYub3JnPG1haWx0bzpuZXRt
b2RAaWV0Zi5vcmc+PiwgIm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1jaGFp
cnNAaWV0Zi5vcmc+IiA8bmV0bW9kLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWNoYWly
c0BpZXRmLm9yZz4+DQpTdWJqZWN0OiBSZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtbmV0bW9k
LXJvdXRpbmctY2ZnLTIzDQoNCg0KQXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRywNCg0KDQoNCkFz
IHBhcnQgb2YgdGhlIFdHIExhc3QgQ2FsbCwgYXJlIHlvdSBhd2FyZSBvZiBhbnkgSVBSIHRoYXQg
YXBwbGllcyB0byBkcmFmdCBpZGVudGlmaWVkIGFib3ZlPyAgUGxlYXNlIHN0YXRlIGVpdGhlcjoN
Cg0KICAqICJObywgSSdtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHRoYXQgYXBwbGllcyB0byB0aGlz
IGRyYWZ0Ig0KDQogICogIlllcywgSSdtIGF3YXJlIG9mIElQUiB0aGF0IGFwcGxpZXMgdG8gdGhp
cyBkcmFmdCINCg0KDQoNCklmIOKAnHllc+KAnSwgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2Vk
IGluIGNvbXBsaWFuY2Ugd2l0aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwg
MzY2OSBhbmQgNTM3OCBmb3IgbW9yZSBkZXRhaWxzKT8gICBQbGVhc2Ugc3RhdGUgZWl0aGVyOg0K
DQogICogIlllcywgdGhlIElQUiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRo
IElFVEYgSVBSIHJ1bGVzIg0KDQogICogIk5vLCB0aGUgSVBSIGhhcyBub3QgYmVlbiBkaXNjbG9z
ZWQiDQoNCg0KDQpJZiB5b3UgYW5zd2VyIOKAnG5v4oCdLCBwbGVhc2UgcHJvdmlkZSBhbnkgYWRk
aXRpb25hbCBkZXRhaWxzIHlvdSB0aGluayBhcHByb3ByaWF0ZS4NCg0KDQoNCklmIHlvdSBhcmUg
bGlzdGVkIGFzIGEgZG9jdW1lbnQgYXV0aG9yIG9yIGNvbnRyaWJ1dG9yLCBwbGVhc2UgYW5zd2Vy
IHRoZSBhYm92ZSBieSByZXNwb25kaW5nIHRvIHRoaXMgZW1haWwgcmVnYXJkbGVzcyBvZiB3aGV0
aGVyIG9yIG5vdCB5b3UgYXJlIGF3YXJlIG9mIGFueSByZWxldmFudCBJUFIuIFRoaXMgZG9jdW1l
bnQgd2lsbCBub3QgYWR2YW5jZSB0byB0aGUgbmV4dCBzdGFnZSB1bnRpbCBhIHJlc3BvbnNlIGhh
cyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBhdXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci4g
Tk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBPRiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdT
IFRPIExJTkVTLg0KDQoNCg0KSWYgeW91IGFyZSBvbiB0aGUgV0cgZW1haWwgbGlzdCBvciBhdHRl
bmQgV0cgbWVldGluZ3MgYnV0IGFyZSBub3QgbGlzdGVkIGFzIGFuIGF1dGhvciBvciBjb250cmli
dXRvciwgd2UgcmVtaW5kIHlvdSBvZiB5b3VyIG9ibGlnYXRpb25zIHVuZGVyIHRoZSBJRVRGIElQ
UiBydWxlcyB3aGljaCBlbmNvdXJhZ2VzIHlvdSB0byBub3RpZnkgdGhlIElFVEYgaWYgeW91IGFy
ZSBhd2FyZSBvZiBJUFIgb2Ygb3RoZXJzIG9uIGFuIElFVEYgY29udHJpYnV0aW9uLCBvciB0byBy
ZWZyYWluIGZyb20gcGFydGljaXBhdGluZyBpbiBhbnkgY29udHJpYnV0aW9uIG9yIGRpc2N1c3Np
b24gcmVsYXRlZCB0byB5b3VyIHVuZGlzY2xvc2VkIElQUi4gRm9yIG1vcmUgaW5mb3JtYXRpb24s
IHBsZWFzZSBzZWUgdGhlIFJGQ3MgbGlzdGVkIGFib3ZlIGFuZCBodHRwOi8vdHJhYy50b29scy5p
ZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxlY3R1YWxQcm9wZXJ0eS4NCg0KDQoN
ClBTOiBQbGVhc2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVz
c2FnZSBpbiB5b3VyIHJlc3BvbnNlLg0KDQoNCg0KVGhhbmsgeW91LA0KDQpORVRNT0QgV0cgQ2hh
aXJzDQoNCg0KDQoNCg0KDQo=

--_000_D3E612227B6E6aceeciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy
ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx
NHB4OyBmb250LWZhbWlseTogQ2FsaWJyaSwgc2Fucy1zZXJpZjsiPg0KPGRpdj5TcGVha2VyIGFz
IGFuIGF1dGhvciw8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2Pk5vLCBJIGFtIG5vdCBh
d2FyZSBvZiBhbiBJUFIgdGhhdCBhcHBsaWVzIHRvIHRoaXMgZHJhZnQuJm5ic3A7PC9kaXY+DQo8
ZGl2Pjxicj4NCjwvZGl2Pg0KPGRpdj5UaGFua3MsPC9kaXY+DQo8ZGl2PkFjZWU8L2Rpdj4NCjxk
aXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBz
dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9udC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVm
dDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDog
bWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAwaW47IFBBRERJTkctTEVGVDogMGluOyBQQURE
SU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNiNWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklH
SFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDogM3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdl
aWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+S2VudCBXYXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzpr
d2F0c2VuQGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDs8YnI+DQo8c3Bh
biBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+RGF0ZTogPC9zcGFuPkZyaWRheSwgQXVndXN0IDI2
LCAyMDE2IGF0IDE6NTggUE08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+VG86
IDwvc3Bhbj5MYWRpc2xhdiBMaG90a2EgJmx0OzxhIGhyZWY9Im1haWx0bzpsaG90a2FAbmljLmN6
Ij5saG90a2FAbmljLmN6PC9hPiZndDssIEFjZWUgTGluZGVtICZsdDs8YSBocmVmPSJtYWlsdG86
YWNlZUBjaXNjby5jb20iPmFjZWVAY2lzY28uY29tPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0i
Zm9udC13ZWlnaHQ6Ym9sZCI+Q2M6IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86bmV0bW9k
QGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86
bmV0bW9kQGlldGYub3JnIj5uZXRtb2RAaWV0Zi5vcmc8L2E+Jmd0OywgJnF1b3Q7PGEgaHJlZj0i
bWFpbHRvOm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmciPm5ldG1vZC1jaGFpcnNAaWV0Zi5vcmc8L2E+
JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0bW9kLWNoYWlyc0BpZXRmLm9yZyI+bmV0bW9k
LWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJv
bGQiPlN1YmplY3Q6IDwvc3Bhbj5SZWdhcmRpbmcgSVBSIG9uIGRyYWZ0LWlldGYtbmV0bW9kLXJv
dXRpbmctY2ZnLTIzPGJyPg0KPC9kaXY+DQo8ZGl2Pjxicj4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUg
aWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVG
VDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8
ZGl2IHhtbG5zOm89InVybjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1s
bnM6dz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0
cDovL3NjaGVtYXMubWljcm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0
cDovL3d3dy53My5vcmcvVFIvUkVDLWh0bWw0MCI+DQo8bWV0YSBuYW1lPSJUaXRsZSIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IktleXdvcmRzIiBjb250ZW50PSIiPg0KPG1ldGEgbmFtZT0iR2Vu
ZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQgbWVkaXVtKSI+DQo8
c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFjZQ0KCXtmb250LWZh
bWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2IDMgMiA0O30NCkBm
b250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToyIDE1IDUgMiAyIDIg
NCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3JtYWwsIGxpLk1zb05v
cm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFw
dDsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7fQ0KYTpsaW5rLCBz
cGFuLk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6IzA1NjND
MTsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBl
cmxpbmtGb2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Izk1NEY3MjsN
Cgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCnAuTXNvUGxhaW5UZXh0LCBsaS5Nc29QbGFp
blRleHQsIGRpdi5Nc29QbGFpblRleHQNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRv
bTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpz
cGFuLkVtYWlsU3R5bGUxNw0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWls
eTpDYWxpYnJpOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21z
by1zdHlsZS1uYW1lOiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsN
Cgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpz
cGFuLm1zb0lucw0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFt
ZToiIjsNCgl0ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0No
cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1mYW1pbHk6Q2Fs
aWJyaTt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2lu
OjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3Jk
U2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT4NCjxkaXYgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVT
IiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlv
bjEiPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QXV0aG9ycywgQ29udHJpYnV0b3JzLCBXRyw8
bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+QXMgcGFydCBvZiB0aGUgV0cgTGFzdCBDYWxs
LCBhcmUgeW91IGF3YXJlIG9mIGFueSBJUFIgdGhhdCBhcHBsaWVzIHRvIGRyYWZ0IGlkZW50aWZp
ZWQgYWJvdmU/Jm5ic3A7IFBsZWFzZSBzdGF0ZSBlaXRoZXI6PC9wPg0KPHAgY2xhc3M9Ik1zb1Bs
YWluVGV4dCI+Jm5ic3A7ICogJnF1b3Q7Tm8sIEknbSBub3QgYXdhcmUgb2YgYW55IElQUiB0aGF0
IGFwcGxpZXMgdG8gdGhpcyBkcmFmdCZxdW90OzxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b1BsYWluVGV4dCI+Jm5ic3A7ICogJnF1b3Q7WWVzLCBJJ20gYXdhcmUgb2YgSVBSIHRoYXQgYXBw
bGllcyB0byB0aGlzIGRyYWZ0JnF1b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxh
aW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPklm
IOKAnHllc+KAnSwgaGFzIHRoaXMgSVBSIGJlZW4gZGlzY2xvc2VkIGluIGNvbXBsaWFuY2Ugd2l0
aCBJRVRGIElQUiBydWxlcyAoc2VlIFJGQ3MgMzk3OSwgNDg3OSwgMzY2OSBhbmQgNTM3OCBmb3Ig
bW9yZSBkZXRhaWxzKT8gJm5ic3A7Jm5ic3A7UGxlYXNlIHN0YXRlIGVpdGhlcjo8bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPiZuYnNwOyAqICZxdW90O1llcywgdGhlIElQ
UiBoYXMgYmVlbiBkaXNjbG9zZWQgaW4gY29tcGxpYW5jZSB3aXRoIElFVEYgSVBSIHJ1bGVzJnF1
b3Q7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij4mbmJzcDsgKiAmcXVv
dDtObywgdGhlIElQUiBoYXMgbm90IGJlZW4gZGlzY2xvc2VkJnF1b3Q7PG86cD48L286cD48L3A+
DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNz
PSJNc29QbGFpblRleHQiPklmIHlvdSBhbnN3ZXIg4oCcbm/igJ0sIHBsZWFzZSBwcm92aWRlIGFu
eSBhZGRpdGlvbmFsIGRldGFpbHMgeW91IHRoaW5rIGFwcHJvcHJpYXRlLjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvUGxhaW5UZXh0Ij5JZiB5b3UgYXJlIGxpc3RlZCBhcyBhIGRvY3VtZW50IGF1dGhvciBv
ciBjb250cmlidXRvciwgcGxlYXNlIGFuc3dlciB0aGUgYWJvdmUgYnkgcmVzcG9uZGluZyB0byB0
aGlzIGVtYWlsIHJlZ2FyZGxlc3Mgb2Ygd2hldGhlciBvciBub3QgeW91IGFyZSBhd2FyZSBvZiBh
bnkgcmVsZXZhbnQgSVBSLiBUaGlzIGRvY3VtZW50IHdpbGwgbm90IGFkdmFuY2UgdG8gdGhlIG5l
eHQgc3RhZ2UgdW50aWwgYSByZXNwb25zZQ0KIGhhcyBiZWVuIHJlY2VpdmVkIGZyb20gZWFjaCBh
dXRob3IgYW5kIGxpc3RlZCBjb250cmlidXRvci4gTk9URTogVEhJUyBBUFBMSUVTIFRPIEFMTCBP
RiBZT1UgTElTVEVEIElOIFRISVMgTUVTU0FHRSdTIFRPIExJTkVTLjxvOnA+PC9vOnA+PC9wPg0K
PHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0i
TXNvUGxhaW5UZXh0Ij5JZiB5b3UgYXJlIG9uIHRoZSBXRyBlbWFpbCBsaXN0IG9yIGF0dGVuZCBX
RyBtZWV0aW5ncyBidXQgYXJlIG5vdCBsaXN0ZWQgYXMgYW4gYXV0aG9yIG9yIGNvbnRyaWJ1dG9y
LCB3ZSByZW1pbmQgeW91IG9mIHlvdXIgb2JsaWdhdGlvbnMgdW5kZXIgdGhlIElFVEYgSVBSIHJ1
bGVzIHdoaWNoIGVuY291cmFnZXMgeW91IHRvIG5vdGlmeSB0aGUgSUVURiBpZiB5b3UgYXJlIGF3
YXJlIG9mIElQUiBvZiBvdGhlcnMNCiBvbiBhbiBJRVRGIGNvbnRyaWJ1dGlvbiwgb3IgdG8gcmVm
cmFpbiBmcm9tIHBhcnRpY2lwYXRpbmcgaW4gYW55IGNvbnRyaWJ1dGlvbiBvciBkaXNjdXNzaW9u
IHJlbGF0ZWQgdG8geW91ciB1bmRpc2Nsb3NlZCBJUFIuIEZvciBtb3JlIGluZm9ybWF0aW9uLCBw
bGVhc2Ugc2VlIHRoZSBSRkNzIGxpc3RlZCBhYm92ZSBhbmQNCjxhIGhyZWY9Imh0dHA6Ly90cmFj
LnRvb2xzLmlldGYub3JnL2dyb3VwL2llc2cvdHJhYy93aWtpL0ludGVsbGVjdHVhbFByb3BlcnR5
Ij5odHRwOi8vdHJhYy50b29scy5pZXRmLm9yZy9ncm91cC9pZXNnL3RyYWMvd2lraS9JbnRlbGxl
Y3R1YWxQcm9wZXJ0eTwvYT4uPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0
Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPlBTOiBQbGVh
c2UgaW5jbHVkZSBhbGwgbGlzdGVkIGluIHRoZSBoZWFkZXJzIG9mIHRoaXMgbWVzc2FnZSBpbiB5
b3VyIHJlc3BvbnNlLjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+PG86
cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5UaGFuayB5b3UsPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij5ORVRNT0QgV0cgQ2hhaXJzPG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvUGxhaW5UZXh0Ij48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjxwIGNsYXNzPSJNc29QbGFpblRleHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb1BsYWluVGV4dCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L3NwYW4+DQo8L2JvZHk+DQo8L2h0bWw+DQo=

--_000_D3E612227B6E6aceeciscocom_--


From nobody Fri Aug 26 13:13: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 2E99712D80A; Fri, 26 Aug 2016 13:13:43 -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 vk1yw56y_Qdm; Fri, 26 Aug 2016 13:13:41 -0700 (PDT)
Received: from mail-wm0-x22b.google.com (mail-wm0-x22b.google.com [IPv6:2a00:1450:400c:c09::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A72BE12D74F; Fri, 26 Aug 2016 13:13:40 -0700 (PDT)
Received: by mail-wm0-x22b.google.com with SMTP id q128so6315793wma.1; Fri, 26 Aug 2016 13:13:40 -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=luU9JPb4n8QvhLdEIaV3UH/cHw3gw52VuKEgl+3DFOw=; b=qpHazMBJU38gLNPjMMonhu7IGViEmb7VGSI6bYgIKukrCwBrfdRe/szg071lOzmRls HnejEnquJf0w1PZ2r06oLKuOjhHcqRl+TQswWYqFZyd4eddgi3uqWFH/y91Jm3nZ5K1i t6Tye+oKksDsjKx8xpJSUwute81n4nabyL2grDVeoJceQvprWdHK9mgFbYtNauhgZXo9 ThetHvf7OX/ESiKO2TLHTCOco8fV0ti1BonujLQH+865wlh64KiYZF6VE2DKtdqJdt1d K7K9qWoyX2tQ/uI2knAdGdPr9IKT8n530hmRYfMxXTWEbfkICc9Es1MXRAhpnul5cDKp pgfQ==
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=luU9JPb4n8QvhLdEIaV3UH/cHw3gw52VuKEgl+3DFOw=; b=jMml/mNPpQZCTvn0P+cjerE0CT2MCvxUUznmoI9PGIu3WuKFhfeFhsO6soVKjtRkv0 zcdVdKQW4+M5H48w930N5l2/sVTFS7fuvsnpuakOyuZbPVG2pHgxyiR1aweYmRd90hJs HnWT26hpTB5jYoF037v+ncMa7uu0yBHOEWlAiRgh4s+PRxRf4Stesnh5JjyaqdfV/D4X eOg2eFv2dWjnbomSMiPP7i2B3RsdDZP8xu4CuxwonYVOm+iifpiOHGD4uMlFWfmzNnFl kq0eYXblQY0I1GBh98E9V5eXynfUuLr6JenBC20yNc1XeIggw9ws4SmNgmlvPsL1vFt/ Td+A==
X-Gm-Message-State: AE9vXwPgl8zUERHdy29d+/we99OSLWRSja1CqCFr63lMMhi4ON2Xwzt3JdqmRSL23Zh9uQ==
X-Received: by 10.28.208.140 with SMTP id h134mr503857wmg.101.1472242419037; Fri, 26 Aug 2016 13:13:39 -0700 (PDT)
Received: from [192.168.1.67] (82.red-83-53-209.dynamicip.rima-tde.net. [83.53.209.82]) by smtp.gmail.com with ESMTPSA id q65sm545473wmd.24.2016.08.26.13.13.37 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Aug 2016 13:13:38 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_9EA73B18-5C1C-4739-8770-F2D8F698BD25"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Dean Bogdanovic 
In-Reply-To: 
Date: Fri, 26 Aug 2016 22:13:38 +0200
Message-Id: <40874329-7ED8-41C0-A26C-90866BEC9EE1@gmail.com>
References: <5E95D548-556B-481F-BC97-4C7E2FB876CF@juniper.net> 
To: "Acee Lindem (acee)" 
X-Mailer: Apple Mail (2.3112)
Archived-At: 
Cc: "netmod-chairs@ietf.org" , "netmod@ietf.org" , Routing WG 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-routing-cfg-23
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 20:13:43 -0000

--Apple-Mail=_9EA73B18-5C1C-4739-8770-F2D8F698BD25
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Speaker as a contributor

No, I=E2=80=99m not aware of any IPR that applies to this draft

Dean
=20
> On Aug 26, 2016, at 9:35 PM, Acee Lindem (acee)  =
wrote:
>=20
> Speaker as an author,
>=20
> No, I am not aware of an IPR that applies to this draft.=20
>=20
> Thanks,
> Acee
>=20
> From: Kent Watsen >
> Date: Friday, August 26, 2016 at 1:58 PM
> To: Ladislav Lhotka >, Acee =
Lindem >
> Cc: "netmod@ietf.org " >, "netmod-chairs@ietf.org =
" >
> Subject: Regarding IPR on draft-ietf-netmod-routing-cfg-23
>=20
> Authors, Contributors, WG,
> =20
> As part of the 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"
>   * "Yes, I'm aware of IPR that applies to this draft"
> =20
> If =E2=80=9Cyes=E2=80=9D, has this IPR been disclosed in compliance =
with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more =
details)?   Please state either:
>   * "Yes, the IPR has been disclosed in compliance with IETF IPR =
rules"
>   * "No, the IPR has not been disclosed"
> =20
> If you answer =E2=80=9Cno=E2=80=9D, please provide any additional =
details you think appropriate.
> =20
> If you are listed as a document author or contributor, please answer =
the above by responding to this email regardless of whether or not you =
are aware of any relevant IPR. This document will not advance to the =
next stage until a response has been received from each author and =
listed contributor. NOTE: THIS APPLIES TO ALL OF YOU LISTED IN THIS =
MESSAGE'S TO LINES.
> =20
> If you are on the WG email list or attend WG meetings but are not =
listed as an author or contributor, we remind you of your obligations =
under the IETF IPR rules which encourages you to notify the IETF if you =
are aware of IPR of others on an IETF contribution, or to refrain from =
participating in any contribution or discussion related to your =
undisclosed IPR. For more information, please see the RFCs listed above =
and http://trac.tools.ietf.org/group/iesg/trac/wiki/IntellectualProperty =
.
> =20
> PS: Please include all listed in the headers of this message in your =
response.
> =20
> Thank you,
> NETMOD WG Chairs
> =20
> =20
> =20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


--Apple-Mail=_9EA73B18-5C1C-4739-8770-F2D8F698BD25
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Speaker as a contributor

No, I=E2=80=99m not aware of any IPR =
that applies to this draft

Dean
 
On Aug 26, 2016, at 9:35 PM, =
Acee Lindem (acee) <acee@cisco.com> wrote:

Speaker as an =
author,

No, =
I am not aware of an IPR that applies to this draft. 

Thanks,
Acee

From: Kent Watsen <kwatsen@juniper.net>
Date: Friday, August 26, =
2016 at 1:58 PM
To: Ladislav Lhotka =
<lhotka@nic.cz>, Acee =
Lindem <acee@cisco.com>
Cc: "netmod@ietf.org" <netmod@ietf.org>, "netmod-chairs@ietf.org" =
<netmod-chairs@ietf.org>
Subject: Regarding IPR on =
draft-ietf-netmod-routing-cfg-23

Authors, Contributors, WG,
 
As part of the 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"
  * "Yes, I'm =
aware of IPR that applies to this draft"
 
If =E2=80=9Cyes=E2=80=9D, has this IPR been =
disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 =
and 5378 for more details)?   Please state either:
  * "Yes, the =
IPR has been disclosed in compliance with IETF IPR rules"
  * "No, the IPR =
has not been disclosed"
 
If you answer =
=E2=80=9Cno=E2=80=9D, 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/IntellectualPro=
perty.
 
PS: Please include =
all listed in the headers of this message in your response.
 
Thank you,
NETMOD WG Chairs
 
 
 
_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod

=

--Apple-Mail=_9EA73B18-5C1C-4739-8770-F2D8F698BD25--


From nobody Fri Aug 26 14:24: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 9A61812D133 for ; Fri, 26 Aug 2016 14:24:49 -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 yQHMSsTpe11U for ; Fri, 26 Aug 2016 14:24:47 -0700 (PDT)
Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EE03D12D568 for ; Fri, 26 Aug 2016 14:24:46 -0700 (PDT)
Received: by mail-pf0-x22e.google.com with SMTP id p64so32126413pfb.1 for ; Fri, 26 Aug 2016 14:24:46 -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=NPYDT+chKoO3dzSH4A9QdLWKs2qgIPE6dLuTU/haiXo=; b=WBryhdRbkH5XEpD03XhrAU+lhxK1XwMgv53g6S3536/lQC/VNe8Swz/UJ6p/4nwTMf 96eZT7IjtdLKzz2hQYzq19E41tMiq/lmTViY+Efeh176RSz3Ai329cDpxlWMc9tIILfk XnBGYtZxqUbyATgc2Q8SnDq0OD0u4Ff7lUprSDS8SjjN00AOSLx7NOWbCdLeZxUqh/nc Kc1lRnYZr1++f2nSbMMjryP6d6EpEL4U0vB+ZtOhx7HzJgwhKG9y0ZZzvexirrfmHRii dhmFT3SLxQ6r6iUpjtZ7Cwn0zIkEwioNtBYSDBbHNKjDhhWwTM16DUZr4rbUVUrZG9pW PIag==
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=NPYDT+chKoO3dzSH4A9QdLWKs2qgIPE6dLuTU/haiXo=; b=LzeTEwX/hgKmQ4tnkTrLm4cRF/OeHWlcKLpLYCAR7YrtK+qbJqacsKyvDMFf1jIsCg sTV9pseqJRWSqe0XRxnEgS+BKQv1MGR9af2XzE0RIbbT8VK4V1rrR8MOLeIoLULZW5YK HXBbv6FyW+HP99ySiy8tjayRReQ92M/ueJ9yfwNTJXriFhmRDC3GSd65kaBfB+3Hhyrp vMDbxczyc1Cz9008tIF9/NAa397K5DXBo0oBM8hGDaC87RCELXQJkauTf2QG1nGUd2eN jpFUCoIJ0hp5JsVrrd6UMY10dacIDzfiV1Khro0+jCUnoCMNdR9CY/IwUBsRAXTyAlva gUBQ==
X-Gm-Message-State: AE9vXwMvOiUCZ1qr80eNtPcPhM7zuVin/InQqGPGptCkNdTzforR9bkEWSRpWsGkRc9h5w==
X-Received: by 10.98.63.1 with SMTP id m1mr9729372pfa.14.1472246686538; Fri, 26 Aug 2016 14:24:46 -0700 (PDT)
Received: from ?IPv6:2001:420:30d:1254:8162:bd8c:b348:86d7? ([2001:420:30d:1254:8162:bd8c:b348:86d7]) by smtp.gmail.com with ESMTPSA id n69sm30930059pfa.77.2016.08.26.14.24.45 (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Fri, 26 Aug 2016 14:24:45 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail=_CDE81190-D077-4016-8301-8080FB8A827B"
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Mahesh Jethanandani 
In-Reply-To: <20160826.143230.1673334253843878893.mbj@tail-f.com>
Date: Fri, 26 Aug 2016 14:24:45 -0700
Message-Id: <17D2FB35-C991-46FE-9C18-7F3EABCC282B@gmail.com>
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local> <20160826.143230.1673334253843878893.mbj@tail-f.com>
To: Martin Bjorklund 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 26 Aug 2016 21:24:49 -0000

--Apple-Mail=_CDE81190-D077-4016-8301-8080FB8A827B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Don=E2=80=99t we have something similar with iana-if-types importing =
ietf-interfaces? Not circular, but definitely odd.

The base identity of interface-type is defined in ietf-interfaces, but =
the interface-types are defined in iana-if-type.yang. For anyone, =
including openconfig-interfaces, wanting to use any of the =
interface-types has to not only import iana-if-types but ietf-interfaces =
also.

As a general rule, would it not be better to have the base identity and =
the different types of that identity in the same file?

> On Aug 26, 2016, at 5:32 AM, Martin Bjorklund  wrote:
>=20
> Juergen Schoenwaelder > wrote:
>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
>>>> On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - =
BE) wrote:
>>>>=20
>>>> [...]
>>>>=20
>>>>> In order to correctly compile (using confdc) we also need to =
import
>>>>> iana-entity for the identities defined in there.  However this is =
leading a
>>>>> circular dependency:
>>>>>=20
>>>>> 1.       Iana-entity imports ietf-entity (to 'resolve'
>>>>> entity-physical-class)
>>>>>=20
>>>>> 2.       Ietf-entity imports iana-entity (to obtain the =
indentities defined
>>>>> in there)
>>>>>=20
>>>>> One way to solve this is to move the definition of =
entity-physical-class
>>>>> from ietf-entity to iana-entity which would resolve the fact that
>>>>> iana-entity requires an import of ietf-entity (ietf-entity needs =
to import
>>>>> iana-entity anyhow, so it can also pick the typedef from the same =
module
>>>>> too).
>>>>=20
>>>> I think moving the definition of entity-physical-class into
>>>> iana-entity makes sense.
>>>=20
>>> Ok.  It feels a bit backwards to me though, but I can see the value =
of
>>> having the iana module self-contained.
>>>=20
>>=20
>> Well, it may look backwards if people want to reuse the base identity
>> but none of the IANA assigned identities - but then it might be good
>> if people at least look at IANA assigned identities. Or are there =
other
>> reasons why you think this may be looking 'backwards'?
>=20
> I makes ietf-entity dependent on iana-entity, since the base identity
> is defined in iana-entity.
>=20
> But OTOH, even if we solved that, ietf-entity is dependent on
> iana-entity b/c of the value 'sensor'.
>=20
> So in this case it is probably fine, but I'm not sure about the
> general idea.
>=20
>=20
> /martin
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org 
> https://www.ietf.org/mailman/listinfo/netmod =

Mahesh Jethanandani
mjethanandani@gmail.com




--Apple-Mail=_CDE81190-D077-4016-8301-8080FB8A827B
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Don=E2=80=99t we have something similar with iana-if-types =
importing ietf-interfaces? Not circular, but definitely odd.

The base identity of =
interface-type is defined in ietf-interfaces, but the interface-types =
are defined in iana-if-type.yang. For anyone, including =
openconfig-interfaces, wanting to use any of the interface-types has to =
not only import iana-if-types but ietf-interfaces also.

As a general rule, would =
it not be better to have the base identity and the different types of =
that identity in the same file?

On =
Aug 26, 2016, at 5:32 AM, Martin Bjorklund <mbj@tail-f.com> =
wrote:

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin =
Bjorklund wrote:
Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Fri, Jul 29, 2016 at =
12:50:13PM +0000, Bogaert, Bart (Nokia - BE) wrote:

[...]

In order to correctly compile (using confdc) we also need to =
import
iana-entity for the identities defined in there. =
 However this is leading a
circular dependency:

1. =
      Iana-entity imports ietf-entity (to =
'resolve'
entity-physical-class)

2.       Ietf-entity imports =
iana-entity (to obtain the indentities defined
in =
there)

One way to solve this is to move the =
definition of entity-physical-class
from ietf-entity to =
iana-entity which would resolve the fact that
iana-entity =
requires an import of ietf-entity (ietf-entity needs to import
iana-entity anyhow, so it can also pick the typedef from the =
same module
too).

I think moving the definition of entity-physical-class =
into
iana-entity makes sense.
Ok.  It feels a bit backwards to me though, but I can =
see the value of
having the iana module self-contained.


Well, it may look =
backwards if people want to reuse the base identity
but =
none of the IANA assigned identities - but then it might be good
if people at least look at IANA assigned identities. Or are =
there other
reasons why you think this may be looking =
'backwards'?

I makes ietf-entity dependent on =
iana-entity, since the base identity
is defined in iana-entity.

But OTOH, even if we solved that, =
ietf-entity is dependent on
iana-entity b/c of the value =
'sensor'.

So in this case it =
is probably fine, but I'm not sure about the
general =
idea.


/martin

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



Mahesh Jethanandani
mjethanandani@gmail.com







=

--Apple-Mail=_CDE81190-D077-4016-8301-8080FB8A827B--


From nobody Sat Aug 27 11:31: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 010BC12D135 for ; Sat, 27 Aug 2016 11:31:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AqVnOyOFgM2K for ; Sat, 27 Aug 2016 11:31:54 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0094.outbound.protection.outlook.com [104.47.33.94]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 38AA212D131 for ; Sat, 27 Aug 2016 11:31:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=7KX1+eAxzcYb7YG4GoZwUMZ82bknp76PF3i6AtXPIg0=; b=FvwMnP89KnlB9qpPwqsM+IPu9cmCvmdfD1fmexjY4e3OqEBZqLO7ebjQnrVknvWHOJrciUGmZbTAfIhUWjGAoxG9H5ROehd/lH/n7yTP+CHV+FgKAmEqpIk3kq078g9eUd7ysdYhJINOmDMU2089i2URuRcylSzgv1z3iQDz/w4=
Received: from CY1PR05CA0031.namprd05.prod.outlook.com (10.166.186.169) by SN1PR0501MB1821.namprd05.prod.outlook.com (10.163.131.144) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.8; Sat, 27 Aug 2016 18:31:51 +0000
Received: from BL2FFO11OLC014.protection.gbl (2a01:111:f400:7c09::184) by CY1PR05CA0031.outlook.office365.com (2a01:111:e400:c5a4::41) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3 via Frontend Transport; Sat, 27 Aug 2016 18:31:51 +0000
Authentication-Results: spf=softfail (sender IP is 66.129.239.18) smtp.mailfrom=juniper.net; ietf.org; dkim=none (message not signed) header.d=none;ietf.org; dmarc=none action=none header.from=juniper.net;
Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.18 as permitted sender)
Received: from p-emfe01a-sac.jnpr.net (66.129.239.18) by BL2FFO11OLC014.mail.protection.outlook.com (10.173.160.144) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.587.6 via Frontend Transport; Sat, 27 Aug 2016 18:31:50 +0000
Received: from p-mailhub01.juniper.net (10.160.2.17) by p-emfe01a-sac.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Sat, 27 Aug 2016 11:31:49 -0700
Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26])	by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id u7RIVmqa018745; Sat, 27 Aug 2016 11:31:49 -0700	(envelope-from phil@juniper.net)
Received: from idle.juniper.net (localhost [127.0.0.1])	by idle.juniper.net (8.14.4/8.14.3) with ESMTP id u7RISQQT054060; Sat, 27 Aug 2016 14:28:26 -0400 (EDT)	(envelope-from phil@idle.juniper.net)
Message-ID: <201608271828.u7RISQQT054060@idle.juniper.net>
To: Juergen Schoenwaelder 
In-Reply-To: <20160826092315.GA32387@elstar.local>
Date: Sat, 27 Aug 2016 14:28:26 -0400
From: Phil Shafer 
MIME-Version: 1.0
Content-Type: text/plain
X-EOPAttributedMessage: 0
X-MS-Office365-Filtering-HT: Tenant
X-Forefront-Antispam-Report: CIP:66.129.239.18; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(6009001)(7916002)(2980300002)(199003)(189002)(50466002)(8936002)(305945005)(81156014)(7696003)(8276002)(81166006)(8676002)(92566002)(69596002)(2906002)(105596002)(68736007)(558084003)(106466001)(48376002)(76506005)(1076002)(54356999)(189998001)(53416004)(11100500001)(47776003)(2950100001)(77096005)(97736004)(110136002)(7846002)(356003)(2810700001)(50986999)(7126002)(626004)(4326007)(86362001)(586003)(87936001)(5003940100001)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:SN1PR0501MB1821; H:p-emfe01a-sac.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; A:1; MX:1; LANG:en; 
X-Microsoft-Exchange-Diagnostics: 1; BL2FFO11OLC014; 1:P0EVUl5K3gCx08SZr1CQvRvnuEiKxw5BmqxdJEnNmWi24GaiJdoNdpqzGAoNtFnVxoqc/VBCt9M9GKtkg7bdW8W0u7w3Tf6OMN+iZnYI9XcRsWqUdahUgJliEa+muf+hcmsV7N27hUc6bGRoA3nFzL4xWH3Ik8cfKGK7RoyUUJJEHuVJd5VafeCXv3Lw+/ArJmEgia2xZ8olnt3hcvANWhoedjAQq4MxiqsVJ1zd0uvtwJksV9fc+R8Jck5fuM/Knm3+mqyADLiy2KjzoXcXiC+EPEXhZfs7lX0qIasT/8X/7xk/mVbwko5CRbZQXuIdiV4VHZ2q5f9CKW/y0WtNYv+C2T8hGrkiNKzC5xMq/i+mWICrmLkE356QBd2wYoz6FguIMiyKG3MKHRKdyoPo755thRgXwPQpdc9xHFYDDvzNa3DBllAZs8DYjQJ8QpTX6RKeHPnqTcsnudzHMh0yD4kyagfvs3QLuDWlUIFYs2YUwW464ix8uudz5RWH9Wh6Z77zUWN8zhUWO1zbNjuSi5hQUvWfcJ2Yyz4t0eHBMWLJSlF8CzdI2i4ZjHava2ag
X-MS-Office365-Filtering-Correlation-Id: bc027fd9-5b7e-4f53-9b61-08d3cea869e0
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1821; 2:hmqb4e44wCmNOWAqqH2/uts6oQrmlShO91QfAKRpWd06R3dPxX/Bs2cP/8BUZErsmTPb5fdcqfilEAvEE0oFP60mt0Etwf9SnY5GdG1h0ICvcqeMlns0PpKowdlXYV1Hl0mukE6FmXKPGSU2+CFDgiNOVEDmb0NawbnUfbwoLmY5eSHubV5K7dv9APC1bTnR; 3:qs/PeizvjyzCzPDJSMOHxP4GbbN992WlTmTxgVtpk5BNxQR2DPyl3XL+QFUmbSXc+Atfh+xfaNyNakfp+kbNo1QQVI4m9/iIvZZaeHc+cXuhKqHHD5udbACOOXbHb0QbsYN/jz5zU0nnRvtMTxLb9w7/wNfumnK1764rqrRsZMPvtoUmUrTjA7V1Vb4uhvqpkM3fk+xYGs6KmRpMEAuwuarqQz5asH6Hi4B8T4bJfFs=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0501MB1821;
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1821; 25:UXhBQT5N5oqdIlWexNsCI+YuJP7R5yb1n20Jo+gm9j6lgD40OsGwO5EZe8l4y8TdNjre1at+ifDFNyP3KgwDp352voimnliq6k778XC/kw2qD20BsAlQNJC8x5rz2TuMHrrLCKC+hj+VS4dxBpH46482SCuN2okgFRrreJiG3I6lASKOu6gOAQR/FzBfklVXKLfibLA1P56jrYWxOQNibsc67rP/bjBOFbGoLx6DU/ABHxJp/QBlZyQTqQdGU3+2Vi5GI7X9Z/mq3YT7GgqXigsqb1znzzjLc/ZqNS+Ikeczen4xgsXw0O+Qi2C+R4fDxgN/vL1sliYYiXyv0JeIh9as/jo4Hukl7DMi8/MTOoOvaS8LeKORuDNe49N4EOpQK7pK1BIbpgtimd3Cziv6n2QaJp1P994j/WlvQbfOiE6KMw9lQeslblT+jGf2z43AGTXX2dRRAI94lG9j3OiAuYqhaN3j2AQkTmemPrNH1jrxwGn2bc7vLTyT+ghlMqS9iKnGU+FZEAt1NelsrfKSdGrPi5TQNbKhzfVYpeYLLhJRl3uj6g6htYSwGn+8QTZ7Gh7SN6PlunGjgnZDvP37lOFUrEuhk1OYhvcVRFAus2uRValfYPfSBH72SxAj5vzBzAiCApwBF5Qqjjvw7/o6e/effIHLGLuoBzKhqwGl9mVNjkd1VDBhDVEt1hOJivgUwlO/0aA/X5O9+0+fuIfEahRtwhBDvtqv6iUVqsdyDjsIb/peHdo/zgwRjN0wfuxVf2q5cFDqEQjJs9PsSw3GMA==
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1821; 31:+MSPihFCZp0VCayo9S54c5ufxLvV2asJp5Vp4sdtH1MR1i/NdEgTYb0uQUGsYEgXySbUuRDGeOP12HarRN4dJyNTJ0JoXZUStKjE7iFSMLavaq8TPl50X3hTsEcb7hk6htDMBSg1T+dYX/FxdkOhHt27ug4MVhQF5GGGFXO/NRDtOfUmZ8/TQKBNpNk/m07K/ZLw9U+a0dATVP+wtnrM1XPTOJC89/zIDMukulIAxng=; 20:Eprj6Cd//wretlpYd5KFYgXvULUVwfuVM5r9QO6Ny3dQG/S/9LWO+GOv187xJEQE6Xr9I7tL6iByq6p3UZKb6npNLfaPitHdCyLZHgcQQTX8/L5pXIknzUxXTK8vwjleCkqP22NPn2QTiJp88D86KZMBfGg1ZVPHWJJFfeBxcxo5P6J6VSrBHC0KYCWfHM/wYltTlBlw9vvqNrkUIGuIF1NhK0w2S9JXWmbYgJeHGZYCI40hQY5q5O8yWmyiIjzZ/lP/Ry2SU4wu2YP6CFzgmSBpsqwx9M70dS/XJQ4a5dfEsMPEV6ssXWbcNH4NUsA0I5Ef+U4e6ZWHnKe/V/ZxOxRWMAswQxIoNyRW8aXypIXoCrFF7+T+5sr9STJc+mysF1xKFutZ3P5oyyLaYhIvreX3FGZfpSjnNuPAvT99e8UmXBZyb3fryvizXuudSmo7FuQ4rVUV3aocnSdW20RpqBKwk5dqXkjB9MgUm0Jz/6Ord5qqxHWEcaFJbRG9WFBj
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(13017025)(13015025)(13024025)(13018025)(13023025)(3002001)(10201501046)(6055026); SRVR:SN1PR0501MB1821; BCL:0; PCL:0; RULEID:; SRVR:SN1PR0501MB1821; 
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1821; 4:unn6dxjZm80L/nXbvZ2BtUpVQkbjnZSJV1wMu/9RxfhUjFsftio7V5fqqt9W8raoiLjmeSdE0IZDGTYZVPHZwxd78fRtYs1z6cifhi9wdHhSDT4A2wiAkb1batxAW9jAnk+9myU2MRIMfNJXBPaMP3lO/vBXBaGb1SjJpzPY7V4hKHuqheMk6fOMdgUhkLa4X2Crtf7VXd9xm1GK1oIzsvhghLgZ01QfNToy6beiX5448ytzAi/T9tokn78bqc9BPGri82Fnp5xvCTUesbSWLReVuznw2dRXud6IA0buElhtx+J71sFIjnf8IZj9xnZL+OLZL5uobJH96fONl0CPS6fI/2Stj5UPC30HBuxqQYV7DHqZOhm1D3BnBaA0qlIlD/WT8rHEeb4k2Q8Yogln5frD0N+b/4ZUQzP+wB7bNOHU317su29p+8mWyvvZbScqurLLm8nZ811nzLWsh/8m18YtZqcYocRLvVd80tLRLp1r/zW1ay/UL/9Qj8NU+qTD
X-Forefront-PRVS: 0047BC5ADE
X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; SN1PR0501MB1821; 23:6QgA3G7khXNNYhuz1bmeRFOuuf/OwY5rPpTfAok?= =?us-ascii?Q?d2lr8iFc9Lsnnv0pMsdIcKd+oFt1ZqMUepYFO9EDXfLPVvF535EOWTZ5BC4o?= =?us-ascii?Q?+tEmfaVqaP5NmeONLt1vz9uaF/814UDjzzjMnhiDeXz2viZ0o8uWFYkfYM+E?= =?us-ascii?Q?138XB3A9pRyFdwwyqs2NZpwKTEyQJ17RJ1fZI9YQ9Ss9287yoS7a6Z5WvGPS?= =?us-ascii?Q?0yJi4ibjqxDwZD4xsQCtOM6MOY5izhRGf/gLY59Ezd2RFVwNh/8oe/hN/WE5?= =?us-ascii?Q?7HP0yqRcUPbIFDxWp+JeT6hCqezI6hfgwNZ53cG+gADo/iS1pYwEti9ffgi5?= =?us-ascii?Q?KIgITqmDv1oDOFIBr1LsklLYX8ZiyO82SDuOOVjZWG++cW9Jg5b9R6Wn1Wwu?= =?us-ascii?Q?kh+uLVPUatC7tMQ+p+ld23d6X4IrXeeRdzOY2O3EaqE6zxsVoyzciPTd7XiM?= =?us-ascii?Q?W+cAgB4EM2+VH03VMa2rE/CCC5WyVNjo1rrWO08xR8BIFjJO/m+THdrCbdZf?= =?us-ascii?Q?5LWjVc0higZVSPeZ2XQN4mUiZFNbuwNoUibiy45VEU3N9SjgTlmlqzCh2P7V?= =?us-ascii?Q?nZ6K29GVkcrVhruB03vYEgQ1tazt8vGPq2uiqHj34FEcoa0fG4tT/jaGHajc?= =?us-ascii?Q?MgFAu1QjYJPod+CjI7r3rUrAdthT/2c1hDIiZV/+zh4AOaPqK/fQZWJnBHE7?= =?us-ascii?Q?h42BULrlQONRO5EZnx9egA4xTX4Dw/HGgYzoEGiXTMRNFt6xTEZBVI53DkVu?= =?us-ascii?Q?34BnOa+wYbfUQ01wLbt2MCJI6aWpvGwBD4dh+Sw8r7S4lA1KEk+UdqBKQL13?= =?us-ascii?Q?HCdlXXvv8/JdKpzAVRfc4JcLhx1AzQbpnPnrKrdxGnZVwRRa/9hfIrFPA3iS?= =?us-ascii?Q?OkzsfNbzJ+zYb/dj8M+XqGFpls1RSYN52Cpse4SAHJpoP8m3GqsWl35rlYy/?= =?us-ascii?Q?K+umW6TowNgZE5kIcHeYEgI9xBrZrvQ2cJK3v5r+Q4PudmVCAH4tiSaz4sQN?= =?us-ascii?Q?3I+ib3CUO5Tngeq8DlKg3W1iwVfQqZhtjBivbw6zDTTSHMFzbLHdQZE50UCH?= =?us-ascii?Q?59j0TRMc=3D?=
X-Microsoft-Exchange-Diagnostics: 1; SN1PR0501MB1821; 6:nxBzqhOo6xiZwAPpby8wpKR05Z4vx2Ya4Tfd7JDi3aXg+Pb3WjO3IOkrD/HuqhLQDEBg2CK2IZB2DRGTkMvqOu7X8OY+5lZ0uwsoHxpTQkHTODGoRGv29Q4ddCmePz2YC9cRDNecPS8oaC/kvOmJvGWnmi+pTclknEu+/UuIhAJSgN7hecP97Db1ohAoZbYpitPYMOTrUkHtbQsH1u49T3C8v7Qo0fT9ZAaVt7A09eCPc0aLrmIq6oaOQTKTfqaZUZ8gNj8WUMABJgbrAhy4HyAvmTWjjl6D/7yKMTvLTTprfU9N9sJNx65tRHgLRWv6H/eM/Ap9RC8jHHBkWTMvrQ==; 5:4lIG9cAILQVnuabP9AlbFJ2RXUSO48UNSoKqTNW3WlzCMVITCVv7rXdwFhL+svX0h41wfUZCtkamxh3l9WIumWWUsQmfF8XdUYjauPHR/8crheC6tOccrkntQCAYsm7r+EVYoPM9Q4bO2E1fu/by8w==; 24:LTj3ooR8ao7O8bnRJ3i6JGUN90mObo+rPuxRInj2dXa2whA8DxNOOxE4Dd2QQAlvNMsA0gj2JPQIc0quUjHOq3B8E40AIdJWIaIPZ4XOeWs=; 7:uOZroFZ6iLeL8dwkdVOXl/f84TxzbmCBmJCLRlG1sWZkeewo/ioO7c2P0zu4F5f88C/063ZalxMV1vJSqBRDqIMdnz1LFyha8px2pvbTeVQveFFPZrNbBB6UT21JzhQQPG54fhl9h0SgOl7yAkb38NL8KyfbUtnzos7/qqDV2F9NQ+k2Zf13TMU82UDQO78p7qUbCYw2SfaPMMqBFkahgPPUjRp/Lgz1bRq/wGZcBylyVJmVVbERbu6DR3Hmwvq7
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Aug 2016 18:31:50.8819 (UTC)
X-MS-Exchange-CrossTenant-Id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=bea78b3c-4cdb-4130-854a-1d193232e5f4; Ip=[66.129.239.18];  Helo=[p-emfe01a-sac.jnpr.net]
X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0501MB1821
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] entity naming question
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 27 Aug 2016 18:31:56 -0000

Juergen Schoenwaelder writes:
>I believe it is worth to move to a terminology
>that is far easier to understand and use; as long as the relationship
>to the old MIB modules is clearly documented we are fine I think.

+1

Thanks,
 Phil


From nobody Sun Aug 28 21:40: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 9410D12B057; Sun, 28 Aug 2016 21:40:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.17
X-Spam-Level: 
X-Spam-Status: No, score=-103.17 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, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 sASNjaTuLzz0; Sun, 28 Aug 2016 21:40:31 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C4B712B01F; Sun, 28 Aug 2016 21:40:31 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 57059B810E8; Sun, 28 Aug 2016 21:40:31 -0700 (PDT)
To: mbj@tail-f.com, j.schoenwaelder@jacobs-university.de
X-PHP-Originating-Script: 30:errata_mail_lib.php
From: RFC Errata System 
Message-Id: <20160829044031.57059B810E8@rfc-editor.org>
Date: Sun, 28 Aug 2016 21:40:31 -0700 (PDT)
Archived-At: 
Cc: iesg@ietf.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] [Errata Verified] RFC6643 (4786)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 04:40:33 -0000

The following errata report has been verified for RFC6643,
"Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules". 

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6643&eid=4786

--------------------------------------
Status: Verified
Type: Technical

Reported by: Martin Björklund 
Date Reported: 2016-08-24
Verified by: Benoit Claise (IESG)

Section: 9.1

Original Text
-------------
      If the current object belongs to a conceptual table,
      then a sequence of leaf statements is generated for each INDEX
      object of the conceptual table.  These leafs are named after the
      INDEX objects and of type leafref.


Corrected Text
--------------
      If the current object belongs to a conceptual table,
      then a sequence of leaf statements is generated for each INDEX
      object of the conceptual table, except that a leaf statement is
      not generated for the current object if it is also an INDEX
      object. These leafs are named after the INDEX objects and of type
      leafref.


Notes
-----
The original text would lead to duplicate leaf nodes if the current object is also part of the INDEX.  Section 9.2 contains an example which shows such a situation, without any duplicates.

--------------------------------------
RFC6643 (draft-ietf-netmod-smi-yang-05)
--------------------------------------
Title               : Translation of Structure of Management Information Version 2 (SMIv2) MIB Modules to YANG Modules
Publication Date    : July 2012
Author(s)           : J. Schoenwaelder
Category            : PROPOSED STANDARD
Source              : NETCONF Data Modeling Language
Area                : Operations and Management
Stream              : IETF
Verifying Party     : IESG


From nobody Sun Aug 28 21:46: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 15E5112B01F; Sun, 28 Aug 2016 21:46:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.07
X-Spam-Level: 
X-Spam-Status: No, score=-15.07 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.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XffLWoMN-YdY; Sun, 28 Aug 2016 21:46:19 -0700 (PDT)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6C29A12B057; Sun, 28 Aug 2016 21:46:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=762; q=dns/txt; s=iport; t=1472445978; x=1473655578; h=subject:to:references:cc:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=vWj10a5Y4aI18GfFN8I2K0KaFrscMmcjwGMGkWZeT/A=; b=Bo2wE+sEddDRc2ZykJrRCF78970D94/USBD3cE4ihKb31krvEMjKj8Ib l1r5QqJALldUTLx07Lf+/7cP/yi+fy6Oi6onzwnnEbPiCDng2+LRassjz weOQZ2lGjFEpSpTlFUamWijGsIYSMip6UzbearOfwiDq8Se/2o1j3BgUQ s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CXAgDwvMNX/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBgykBAQEBAYEftmiEEIYdAoFsEAECAQEBAQEBAV4nhGIBAQQjFUEQCxoCJgI?= =?us-ascii?q?CVwYBDAgBAYg8rgOPJAEBAQEBAQEBAQEBAQEBAQEBAR+BA4UrgXiCVYEihiCCW?= =?us-ascii?q?gEEiC2Fd4srjyuJW4V6b4gJh0U1H4QeOocAAQEB?=
X-IronPort-AV: E=Sophos;i="5.28,594,1464652800"; d="scan'208";a="644251662"
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; 29 Aug 2016 04:46:16 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id u7T4kGFM030486; Mon, 29 Aug 2016 04:46:16 GMT
To: IETF Meeting Session Request Tool , session-request@ietf.org
References: <147136747253.22911.11351876026326451336.idtracker@ietfa.amsl.com>
From: Benoit Claise 
Message-ID: 
Date: Mon, 29 Aug 2016 06:46:16 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <147136747253.22911.11351876026326451336.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod-chairs@ietf.org, netmod@ietf.org
Subject: Re: [netmod] netmod - New Meeting Session Request for IETF 97
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 04:46:20 -0000

Hi,
>
> A new meeting session request has just been submitted by Lou Berger, a Chair of the netmod working group.
>
>
> ---------------------------------------------------------
> Working Group Name: NETCONF Data Modeling Language
> Area Name: Operations and Management Area
> Session Requester: Lou Berger
>
> Number of Sessions: 2
> Length of Session(s):  2.5 Hours, 1 Hour
> Number of Attendees: 100
The room was packed last time. I would increase the number of attendees, 
to get a bigger room.

Regards, B.
> Conflicts to Avoid:
>   First Priority: netconf rtgwg
>   Second Priority: i2rs anima isis ospf
>   Third Priority: saag
>
>
> Special Requests:
>    
> ---------------------------------------------------------
>
> .
>


From nobody Sun Aug 28 23:13: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 1D6D212D137; Sun, 28 Aug 2016 23:13:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 liWnLJhEEpaV; Sun, 28 Aug 2016 23:13:07 -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 5539812D12F; Sun, 28 Aug 2016 23:13:07 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:6cc7:4fe7:80a2:f91a] (unknown [IPv6:2001:718:1a02:1:6cc7:4fe7:80a2:f91a]) by mail.nic.cz (Postfix) with ESMTPSA id 8790360B6D; Mon, 29 Aug 2016 08:13:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1472451185; bh=/nyYPatdkif22XoYAIEE5rjfW1+p/UWSCKmc4Zrup4k=; h=From:Date:To; b=ByEdWMUEXdgxxpBVm1QNuxpWguzQsxB19FSaY/GR9gKDGSaUlHA6FKnkZgiRpHtDd nlZeCUIrKLsq0XwKO2sjW7jMooR6OZ7KYoGFg5zrdwlQLWAQuqJVrJhJOjAv9izw6m G6AR+CC5OpMWJSzHtH+3GidS6CUY7jHErZz3mUOw=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <5E95D548-556B-481F-BC97-4C7E2FB876CF@juniper.net>
Date: Mon, 29 Aug 2016 08:13:10 +0200
Content-Transfer-Encoding: 7bit
Message-Id: 
References: <5E95D548-556B-481F-BC97-4C7E2FB876CF@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: "netmod-chairs@ietf.org" , "netmod@ietf.org" 
Subject: Re: [netmod] Regarding IPR on draft-ietf-netmod-routing-cfg-23
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 06:13:09 -0000

No, I'm not aware of any IPR that applies to this draft.

Lada

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





From nobody Sun Aug 28 23:55: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 91014127071 for ; Sun, 28 Aug 2016 23:55:31 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 Kc74uk96wSYF for ; Sun, 28 Aug 2016 23:55:29 -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 3F62512D12F for ; Sun, 28 Aug 2016 23:55:29 -0700 (PDT)
Received: from fr712umx3.dmz.alcatel-lucent.com (unknown [135.245.210.42]) by Websense Email Security Gateway with ESMTPS id 4ADE73ACD6DC8; Mon, 29 Aug 2016 06:55:25 +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 u7T6tPMA016658 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Aug 2016 06:55:26 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 u7T6tNlc030766 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Aug 2016 08:55:25 +0200
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.83]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 29 Aug 2016 08:55:23 +0200
From: "Bogaert, Bart (Nokia - BE)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] BBF extensions to ietf-entity
Thread-Index: AdHpoi/h3dfqTKzQR3WYPaIL6IHWCgVw90YAAJZ/0CA=
Date: Mon, 29 Aug 2016 06:55:23 +0000
Message-ID: 
References:  <20160826.104954.1973625521466218062.mbj@tail-f.com>
In-Reply-To: <20160826.104954.1973625521466218062.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_0702_01D201D3.121A81E0"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] BBF extensions to ietf-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: Mon, 29 Aug 2016 06:55:31 -0000

------=_NextPart_000_0702_01D201D3.121A81E0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

HI Martin,


"Bogaert, Bart (Nokia - BE)"  wrote:
> I would like to bring this to the ietf-entity group.  Currently BBF is 
> proposing to add new RW leafs to the entity object.  This is done in 
> the context of plugable entities and hence it means that when an 
> operator (via a NC client) configures a plugable item it is required 
> to define the entity type.  For this reason additional RW attributes 
> are needed.  Two of the new leafs are class and contained-in (same as the
RO class leaf).
> 
> -          class: we think that the class leaf needs to be mandatory but
> adding this via an augment is not possible as we can't add a mandatory 
> leaf via an augment.  Making class implicit for the client based on 
> "some information" exchanged between device vendors and management 
> applications is maybe not such a sound approach.

Can you explain in more detail how this would be used?  The idea is that
'class' is a property of the physical hw, and that the underlying system
provides this info.  I can see that it could be useful for the client to set
this if the system can't do the classification (i.e., the system-set value
is 'unknown').  But that's probably not the use case you had in mind?


[Bart Bogaert] Assume you have a system with a number of slots that can hold
several different cards and the system was deployed in the field with some
cards inserted and some other slots that were still left empty.  When an
operator wants to extend the system we can have 2 ways of doing this:
1. a field engineer goes 'on-site' and plugs cards in the system.  If done
this way, the system itself can detect what has been inserted and we do not
really need the RW leafs.  However in this case an operator has to wait
configuring user services on these cards until they are inserted.
2. the network operator determines that a node will "run out" of available
ports and hence wants to start planning new configuration and hence he wants
to configure some boards in the empty slots and even may want to start to
pre-configure certain data of the ports contained by these boards.  In that
case we need the RW leaf to indicate which board type will be inserted as
the service that can be offered depends on the board being inserted.  When
the board is inserted, the planned configuration can directly be applied to
the newly inserted board (given the fact that the detected class is the same
as the planned class).

There are customers using method 1 and other customers use method 2.

> -          contained-in: for plugable items contained-in requires to be
> mandatory too as a plugable item can't be "floating" in the device.

Can you explain in more detail what this means, and provide some use cases?


[Bart Bogaert] For DSL we are faced with "wiring" aspects that "ripple
through" to the MDF.  So assume we again have a system with plugable slots.
If we have 2 slots containing the same type of board (same class) and the
operator is applying the pre-configuration mode of working (method 2 in
above), we have to be sure that user A, connected to the first port of the
board plugged in the first slot will really be in slot 1.  If the NC client
has no means to detect which board is plugged in which slot (they are both
of the same class) we need other means to ensure the containment is as
intended (and user A being connected to the first port of the board in slot
A is also visualized as such on the GUI of the NC client).  Using the serial
number of the board seems not very practical as board may break and are sent
to repair or replaced by another board of the same type but with a different
serial number.  I do not think operators will like it a lot to manage a
system in a manual way based on these attributes hence also a need to plan a
board in a specific slot.

Hope this clarifies a bit more.

Best regards,

> Bart Bogaert
> 
> Broadband-Access System Architect Data
> 
> Contact number +32 3 2408310 (+32 477 673952)
> 
>  
> 
> NOKIA
> 
> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 
> 0404 621 642 Register of Legal Entities Antwerp
> 
> 
> 
> <<
> This message (including any attachments) contains confidential 
> information intended for a specific individual and purpose, and is 
> protected by law. If you are not the intended recipient, you should 
> delete this message. Any disclosure, copying, or distribution of this 
> message, or the taking of any action based on it, is strictly 
> prohibited without the prior consent of its author.
> >> 
> 
>  
> 

------=_NextPart_000_0702_01D201D3.121A81E0
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODI5MDY1NTIwWjAjBgkqhkiG9w0B
CQQxFgQU42+0bZAbBncGPq0txzN0tJox3GwwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQCO
5cdra2VZA1fL7Pwi0wkGCKdrqbuhMThdgGPikfkELie/65X4Hld828oveUgAioMo8vupL/7YA6LR
91qIdPNrsSccPWyKUOwR8QhBhUkwOLnkEtqH7G2KXpiB39dr3eZiyTaCvs9lJ1yekcyMCl5Qpnnf
h/Pw8UF9CN29y9DJCJ38464svykgzwMCxo2U5QJYQ2wM2HDza4p1F4K8FOYaBEBOXqBhFc//VCcC
mXTigs4v7jByq17V4BWl8dsb4rnoJ/CZpANNWz7gHiuaRyRXk3SHq7whXM/NDrQBosrD2csf49Xg
htK8eWoPLjVHOpFW1rKi6JFq7PR2Hpn1BVBKAAAAAAAA

------=_NextPart_000_0702_01D201D3.121A81E0--


From nobody Mon Aug 29 00:18: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 7D28412D107 for ; Mon, 29 Aug 2016 00:18:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 utPnb6xfp2UU for ; Mon, 29 Aug 2016 00:18:03 -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 3114312D095 for ; Mon, 29 Aug 2016 00:18:03 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 1B9F023A1E3BF; Mon, 29 Aug 2016 07:18:00 +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 u7T7I03e014119 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Aug 2016 07:18:01 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u7T7HxJc027884 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Aug 2016 09:17:59 +0200
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.83]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 29 Aug 2016 09:17:59 +0200
From: "Bogaert, Bart (Nokia - BE)" 
To: Martin Bjorklund , "j.schoenwaelder@jacobs-university.de" 
Thread-Topic: [netmod] derived-from-or-self leads to circular import
Thread-Index: AQHR/4afRKY0tQ/rSm2MfMZEZSICVqBbCHGAgAACzQCABIA3gA==
Date: Mon, 29 Aug 2016 07:17:58 +0000
Message-ID: 
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local> <20160826.143230.1673334253843878893.mbj@tail-f.com>
In-Reply-To: <20160826.143230.1673334253843878893.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_0715_01D201D6.3B5D3900"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 07:18:05 -0000

------=_NextPart_000_0715_01D201D6.3B5D3900
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Just taking another approach on this: why do we have the restriction on
circular imports?  Is this really required?  If not then this may be solved
in another way too (but will take some time before it gets into the YANG
compilers I'm afraid).

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.
>> 


-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: 26 August 2016 14:33
To: j.schoenwaelder@jacobs-university.de
Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import

Juergen Schoenwaelder  wrote:
> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > Juergen Schoenwaelder  wrote:
> > > On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - BE)
wrote:
> > > 
> > > [...]
> > >  
> > > > In order to correctly compile (using confdc) we also need to 
> > > > import iana-entity for the identities defined in there.  However 
> > > > this is leading a circular dependency:
> > > > 
> > > > 1.       Iana-entity imports ietf-entity (to 'resolve'
> > > > entity-physical-class)
> > > > 
> > > > 2.       Ietf-entity imports iana-entity (to obtain the indentities
defined
> > > > in there)
> > > > 
> > > > One way to solve this is to move the definition of 
> > > > entity-physical-class from ietf-entity to iana-entity which 
> > > > would resolve the fact that iana-entity requires an import of 
> > > > ietf-entity (ietf-entity needs to import iana-entity anyhow, so 
> > > > it can also pick the typedef from the same module too).
> > > 
> > > I think moving the definition of entity-physical-class into 
> > > iana-entity makes sense.
> > 
> > Ok.  It feels a bit backwards to me though, but I can see the value 
> > of having the iana module self-contained.
> >
> 
> Well, it may look backwards if people want to reuse the base identity 
> but none of the IANA assigned identities - but then it might be good 
> if people at least look at IANA assigned identities. Or are there 
> other reasons why you think this may be looking 'backwards'?

I makes ietf-entity dependent on iana-entity, since the base identity is
defined in iana-entity.

But OTOH, even if we solved that, ietf-entity is dependent on iana-entity
b/c of the value 'sensor'.

So in this case it is probably fine, but I'm not sure about the general
idea.


/martin

------=_NextPart_000_0715_01D201D6.3B5D3900
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODI5MDcxNzU3WjAjBgkqhkiG9w0B
CQQxFgQUKfO+GiAj2TRo2o6fAQlehLlKWLgwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQBc
qQsFWvHXNBbtBRksZpYIZs4AHodSjYcdN9GbT90F6zD5CsesJQnU53P6R71oPizvdkIiMTwK8WtO
gw07Y8+WTa2qttXegGCi8xbQNjKj7C6fveAmqBzlPCOnW3bM2bxKVFdAcKGMklUzUbwItbQ0MDwX
h0GDhFEHqh4f4ruuwhUqS/Y/VGYEPSpr3FAGoYSuX8occFB7Hdgyme95bwaIqMmG1fMTRs26DrA7
NFVd8nGD0kvaYVl9ETL+u1za2dyg/wj2w2R7G4/v7zd3uz+UG91bGRm+UJ/aFJan7QFMmikc6A8V
Wftd2X2gcdUdyRG0mlUce1R2II6NjT/+j7CPAAAAAAAA

------=_NextPart_000_0715_01D201D6.3B5D3900--


From nobody Mon Aug 29 00:27: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 33CC4127071 for ; Mon, 29 Aug 2016 00:27:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 Z-jgS3OwN3ST for ; Mon, 29 Aug 2016 00:27:09 -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 C11DA127058 for ; Mon, 29 Aug 2016 00:27:08 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 0373B8D0; Mon, 29 Aug 2016 09:27:07 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id xlhTFBeUHF5q; Mon, 29 Aug 2016 09:27:04 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Mon, 29 Aug 2016 09:27:05 +0200 (CEST)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 10EF6200A6; Mon, 29 Aug 2016 09:27:05 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id PKc17ocKdVOL; Mon, 29 Aug 2016 09:27:02 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id AFE5C200A5; Mon, 29 Aug 2016 09:27:02 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 49D443C512A3; Mon, 29 Aug 2016 09:27:01 +0200 (CEST)
Date: Mon, 29 Aug 2016 09:27:00 +0200
From: Juergen Schoenwaelder 
To: "Bogaert, Bart (Nokia - BE)" 
Message-ID: <20160829072700.GA36733@elstar.local>
Mail-Followup-To: "Bogaert, Bart (Nokia - BE)" , Martin Bjorklund , "netmod@ietf.org" 
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local> <20160826.143230.1673334253843878893.mbj@tail-f.com> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] derived-from-or-self leads to circular import
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, 29 Aug 2016 07:27:11 -0000

I fail to see what this thread has to do with circular imports.

/js

On Mon, Aug 29, 2016 at 07:17:58AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> Just taking another approach on this: why do we have the restriction on
> circular imports?  Is this really required?  If not then this may be solved
> in another way too (but will take some time before it gets into the YANG
> compilers I'm afraid).
> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data
> Contact number +32 3 2408310 (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium
> Fortis 220-0002334-42
> VAT BE 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential information
> intended for a specific individual and purpose, and is protected by law. If
> you are not the intended recipient, you should delete this message. Any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited without the prior consent of its
> author.
> >> 
> 
> 
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com] 
> Sent: 26 August 2016 14:33
> To: j.schoenwaelder@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
> 
> Juergen Schoenwaelder  wrote:
> > On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - BE)
> wrote:
> > > > 
> > > > [...]
> > > >  
> > > > > In order to correctly compile (using confdc) we also need to 
> > > > > import iana-entity for the identities defined in there.  However 
> > > > > this is leading a circular dependency:
> > > > > 
> > > > > 1.       Iana-entity imports ietf-entity (to 'resolve'
> > > > > entity-physical-class)
> > > > > 
> > > > > 2.       Ietf-entity imports iana-entity (to obtain the indentities
> defined
> > > > > in there)
> > > > > 
> > > > > One way to solve this is to move the definition of 
> > > > > entity-physical-class from ietf-entity to iana-entity which 
> > > > > would resolve the fact that iana-entity requires an import of 
> > > > > ietf-entity (ietf-entity needs to import iana-entity anyhow, so 
> > > > > it can also pick the typedef from the same module too).
> > > > 
> > > > I think moving the definition of entity-physical-class into 
> > > > iana-entity makes sense.
> > > 
> > > Ok.  It feels a bit backwards to me though, but I can see the value 
> > > of having the iana module self-contained.
> > >
> > 
> > Well, it may look backwards if people want to reuse the base identity 
> > but none of the IANA assigned identities - but then it might be good 
> > if people at least look at IANA assigned identities. Or are there 
> > other reasons why you think this may be looking 'backwards'?
> 
> I makes ietf-entity dependent on iana-entity, since the base identity is
> defined in iana-entity.
> 
> But OTOH, even if we solved that, ietf-entity is dependent on iana-entity
> b/c of the value 'sensor'.
> 
> So in this case it is probably fine, but I'm not sure about the general
> idea.
> 
> 
> /martin



-- 
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 Aug 29 00:33: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 5894412D095 for ; Mon, 29 Aug 2016 00:33:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 UTKM0Zy8lP6B for ; Mon, 29 Aug 2016 00:33:07 -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 A48E1127058 for ; Mon, 29 Aug 2016 00:32:57 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id 4A87644D05AD2; Mon, 29 Aug 2016 07:32:54 +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 u7T7WtJo002341 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Aug 2016 07:32:55 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u7T7WsUb019658 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Aug 2016 09:32:54 +0200
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.83]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 29 Aug 2016 09:32:54 +0200
From: "Bogaert, Bart (Nokia - BE)" 
To: Juergen Schoenwaelder 
Thread-Topic: [netmod] derived-from-or-self leads to circular import
Thread-Index: AQHR/4afRKY0tQ/rSm2MfMZEZSICVqBbCHGAgAACzQCABIA3gP//4WwAgAAh8rA=
Date: Mon, 29 Aug 2016 07:32:54 +0000
Message-ID: 
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local> <20160826.143230.1673334253843878893.mbj@tail-f.com>  <20160829072700.GA36733@elstar.local>
In-Reply-To: <20160829072700.GA36733@elstar.local>
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_072C_01D201D8.5136B830"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 07:33:11 -0000

------=_NextPart_000_072C_01D201D8.5136B830
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

"Reorganization" of the modules as they are currently defined in IETF is
required in order to avoid the "circular import" error reported by the ConfD
compiler (e.g. confdc of TailF).  I guess that when we remove this
restriction (as far as I remember, a #include equivalent is possible in
C/C++) then at least the modules compile in its current form (that means
after correcting the calls to derived-from-or-self to having only parameters
instead of 3 as they are currently defined in the IETF modules).  I agree
that this is not related to the comment made whether re-organizing
iana-entities in such a way that it defines the identity (rather then
importing it from ietf-entity).

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.
>> 


-----Original Message-----
From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de] 
Sent: 29 August 2016 09:27
To: Bogaert, Bart (Nokia - BE)
Cc: Martin Bjorklund; netmod@ietf.org
Subject: Re: [netmod] derived-from-or-self leads to circular import

I fail to see what this thread has to do with circular imports.

/js

On Mon, Aug 29, 2016 at 07:17:58AM +0000, Bogaert, Bart (Nokia - BE) wrote:
> Just taking another approach on this: why do we have the restriction 
> on circular imports?  Is this really required?  If not then this may 
> be solved in another way too (but will take some time before it gets 
> into the YANG compilers I'm afraid).
> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data Contact number +32 3 2408310 
> (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 
> 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential 
> information intended for a specific individual and purpose, and is 
> protected by law. If you are not the intended recipient, you should 
> delete this message. Any disclosure, copying, or distribution of this 
> message, or the taking of any action based on it, is strictly 
> prohibited without the prior consent of its author.
> >> 
> 
> 
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: 26 August 2016 14:33
> To: j.schoenwaelder@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
> 
> Juergen Schoenwaelder  wrote:
> > On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
> > > Juergen Schoenwaelder  wrote:
> > > > On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - 
> > > > BE)
> wrote:
> > > > 
> > > > [...]
> > > >  
> > > > > In order to correctly compile (using confdc) we also need to 
> > > > > import iana-entity for the identities defined in there.  
> > > > > However this is leading a circular dependency:
> > > > > 
> > > > > 1.       Iana-entity imports ietf-entity (to 'resolve'
> > > > > entity-physical-class)
> > > > > 
> > > > > 2.       Ietf-entity imports iana-entity (to obtain the
indentities
> defined
> > > > > in there)
> > > > > 
> > > > > One way to solve this is to move the definition of 
> > > > > entity-physical-class from ietf-entity to iana-entity which 
> > > > > would resolve the fact that iana-entity requires an import of 
> > > > > ietf-entity (ietf-entity needs to import iana-entity anyhow, 
> > > > > so it can also pick the typedef from the same module too).
> > > > 
> > > > I think moving the definition of entity-physical-class into 
> > > > iana-entity makes sense.
> > > 
> > > Ok.  It feels a bit backwards to me though, but I can see the 
> > > value of having the iana module self-contained.
> > >
> > 
> > Well, it may look backwards if people want to reuse the base 
> > identity but none of the IANA assigned identities - but then it 
> > might be good if people at least look at IANA assigned identities. 
> > Or are there other reasons why you think this may be looking
'backwards'?
> 
> I makes ietf-entity dependent on iana-entity, since the base identity 
> is defined in iana-entity.
> 
> But OTOH, even if we solved that, ietf-entity is dependent on 
> iana-entity b/c of the value 'sensor'.
> 
> So in this case it is probably fine, but I'm not sure about the 
> general idea.
> 
> 
> /martin



-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
Fax:   +49 421 200 3103         

------=_NextPart_000_072C_01D201D8.5136B830
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODI5MDczMjUzWjAjBgkqhkiG9w0B
CQQxFgQUV7X73c+5y5Ph8g32/aJM0ZUJBvQwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQAs
HrU7u+djlcGbqekCPGR83/KyuEx0TQSuRIbLZGTcnCBby4GipApHi3HkWRO4K0SzXodsr8DkMlef
tj+NHON4dVpwX0I5avkyb3Og+WpQZkYkLVrSvZySTJWVLOvCTtH2f8dV6Ujsu1MMxcEj0gVP3bwL
amHTLsQ+Mo2TA7gETMP+obKXqn1PUCikjrl/tW9L6dRwC2GAljEv2dFJnDp1fFDj7sgQh3Kyws4n
ViBpONo+q16OoG0zKI0TkzNNSQvL83JkyWMFImvvtS03ionJUx2N8SvTIVxK1EOX0dL44Ql54aP2
sPdYwcQHbgHZPn7dmk1DYfcBeH3eP9/EDxG+AAAAAAAA

------=_NextPart_000_072C_01D201D8.5136B830--


From nobody Mon Aug 29 02:07: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 A8C8412D1AC for ; Mon, 29 Aug 2016 02:07:24 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 aAgSmOLSGcOb for ; Mon, 29 Aug 2016 02:07:22 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 06FC912D191 for ; Mon, 29 Aug 2016 02:07:21 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 421471AE018C; Mon, 29 Aug 2016 11:07:19 +0200 (CEST)
Date: Mon, 29 Aug 2016 11:06:23 +0200 (CEST)
Message-Id: <20160829.110623.2040913040360172503.mbj@tail-f.com>
To: bart.bogaert@nokia.com
From: Martin Bjorklund 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] BBF extensions to ietf-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: Mon, 29 Aug 2016 09:07:25 -0000

Hi,

[We had mail server problems during the weekend, so this reply might
not get the thread's history right.]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Martin Bjorklund  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > I would like to bring this to the ietf-entity group.  Currently BBF is
> > proposing to add new RW leafs to the entity object.  This is done in the
> > context of plugable entities and hence it means that when an operator (via a
> > NC client) configures a plugable item it is required to define the entity
> > type.  For this reason additional RW attributes are needed.  Two of the new
> > leafs are class and contained-in (same as the RO class leaf). 
> > 
> > -          class: we think that the class leaf needs to be mandatory but
> > adding this via an augment is not possible as we can't add a mandatory leaf
> > via an augment.  Making class implicit for the client based on "some
> > information" exchanged between device vendors and management applications is
> > maybe not such a sound approach.
> 
> Can you explain in more detail how this would be used?  The idea is
> that 'class' is a property of the physical hw, and that the underlying
> system provides this info.  I can see that it could be useful for the
> client to set this if the system can't do the classification (i.e.,
> the system-set value is 'unknown').  But that's probably not the use
> case you had in mind?
> 
> [Bart Bogaert] Assume you have a system with a number of slots that can hold
> several different cards and the system was deployed in the field with some
> cards inserted and some other slots that were still left empty.  When an
> operator wants to extend the system we can have 2 ways of doing this:
> 1. a field engineer goes 'on-site' and plugs cards in the system.  If done
> this way, the system itself can detect what has been inserted and we do not
> really need the RW leafs.  However in this case an operator has to wait
> configuring user services on these cards until they are inserted.
> 2. the network operator determines that a node will "run out" of available
> ports and hence wants to start planning new configuration and hence he wants
> to configure some boards in the empty slots and even may want to start to
> pre-configure certain data of the ports contained by these boards.  In that
> case we need the RW leaf to indicate which board type will be inserted as
> the service that can be offered depends on the board being inserted.  When
> the board is inserted, the planned configuration can directly be applied to
> the newly inserted board (given the fact that the detected class is the same
> as the planned class).

Shouldn't this be handled by the support for pre-configuration in the
interfaces data model?  I.e., the general model would be that the
entity/hardware list is monitoring of the hardware that is really
present, and other models that need to refer to this hardware (like
interfaces) support pre-configuration.

The interface model lacks an explicit pointer to the entity/hardware
model; but in many systems this reference is implicit in the name of
the interface.


/martin



> There are customers using method 1 and other customers use method 2.
> 
> > -          contained-in: for plugable items contained-in requires to be
> > mandatory too as a plugable item can't be "floating" in the device.
> 
> Can you explain in more detail what this means, and provide some use
> cases?
>
> [Bart Bogaert] For DSL we are faced with "wiring" aspects that "ripple
> through" to the MDF.  So assume we again have a system with plugable slots.
> If we have 2 slots containing the same type of board (same class) and the
> operator is applying the pre-configuration mode of working (method 2 in
> above), we have to be sure that user A, connected to the first port of the
> board plugged in the first slot will really be in slot 1.  If the NC client
> has no means to detect which board is plugged in which slot (they are both
> of the same class) we need other means to ensure the containment is as
> intended (and user A being connected to the first port of the board in slot
> A is also visualized as such on the GUI of the NC client).  Using the serial
> number of the board seems not very practical as board may break and are sent
> to repair or replaced by another board of the same type but with a different
> serial number.  I do not think operators will like it a lot to manage a
> system in a manual way based on these attributes hence also a need to plan a
> board in a specific slot.


From nobody Mon Aug 29 02:18: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 63D1212D50D for ; Mon, 29 Aug 2016 02:18:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 TubsJ0N8mWZ3 for ; Mon, 29 Aug 2016 02:18:22 -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 588D412D505 for ; Mon, 29 Aug 2016 02:18:22 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id ACD3C62AD32F9; Mon, 29 Aug 2016 09:18:18 +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 u7T9IJS9025946 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Aug 2016 09:18:20 GMT
Received: from FR711WXCHHUB02.zeu.alcatel-lucent.com (fr711wxchhub02.zeu.alcatel-lucent.com [135.239.2.112]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u7T9IJpe013942 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Aug 2016 11:18:19 +0200
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.83]) by FR711WXCHHUB02.zeu.alcatel-lucent.com ([135.239.2.112]) with mapi id 14.03.0195.001; Mon, 29 Aug 2016 11:18:19 +0200
From: "Bogaert, Bart (Nokia - BE)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] BBF extensions to ietf-entity
Thread-Index: AQHSAdSd3dfqTKzQR3WYPaIL6IHWCqBfqKbg
Date: Mon, 29 Aug 2016 09:18:18 +0000
Message-ID: 
References: <20160829.110623.2040913040360172503.mbj@tail-f.com>
In-Reply-To: <20160829.110623.2040913040360172503.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_073F_01D201E7.0AD96C20"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] BBF extensions to ietf-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: Mon, 29 Aug 2016 09:18:25 -0000

------=_NextPart_000_073F_01D201E7.0AD96C20
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Hi Martin,

In BBF this pointer from HW to interface will be available (it has been
proposed in the Berling BBF meeting already).

Best regards - Vriendelijke groeten,
Bart Bogaert
Broadband-Access System Architect Data
Contact number +32 3 2408310 (+32 477 673952)

NOKIA
Copernicuslaan 50, 2018 Antwerp, Belgium
Fortis 220-0002334-42
VAT BE 0404 621 642 Register of Legal Entities Antwerp

<<
This message (including any attachments) contains confidential information
intended for a specific individual and purpose, and is protected by law. If
you are not the intended recipient, you should delete this message. Any
disclosure, copying, or distribution of this message, or the taking of any
action based on it, is strictly prohibited without the prior consent of its
author.
>> 


-----Original Message-----
From: Martin Bjorklund [mailto:mbj@tail-f.com] 
Sent: 29 August 2016 11:06
To: Bogaert, Bart (Nokia - BE)
Cc: netmod@ietf.org
Subject: Re: [netmod] BBF extensions to ietf-entity

Hi,

[We had mail server problems during the weekend, so this reply might not get
the thread's history right.]

"Bogaert, Bart (Nokia - BE)"  wrote:
> Martin Bjorklund  wrote:
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > I would like to bring this to the ietf-entity group.  Currently BBF 
> > is proposing to add new RW leafs to the entity object.  This is done 
> > in the context of plugable entities and hence it means that when an 
> > operator (via a NC client) configures a plugable item it is required 
> > to define the entity type.  For this reason additional RW attributes 
> > are needed.  Two of the new leafs are class and contained-in (same as
the RO class leaf).
> > 
> > -          class: we think that the class leaf needs to be mandatory but
> > adding this via an augment is not possible as we can't add a 
> > mandatory leaf via an augment.  Making class implicit for the client 
> > based on "some information" exchanged between device vendors and 
> > management applications is maybe not such a sound approach.
> 
> Can you explain in more detail how this would be used?  The idea is 
> that 'class' is a property of the physical hw, and that the underlying 
> system provides this info.  I can see that it could be useful for the 
> client to set this if the system can't do the classification (i.e., 
> the system-set value is 'unknown').  But that's probably not the use 
> case you had in mind?
> 
> [Bart Bogaert] Assume you have a system with a number of slots that 
> can hold several different cards and the system was deployed in the 
> field with some cards inserted and some other slots that were still 
> left empty.  When an operator wants to extend the system we can have 2
ways of doing this:
> 1. a field engineer goes 'on-site' and plugs cards in the system.  If 
> done this way, the system itself can detect what has been inserted and 
> we do not really need the RW leafs.  However in this case an operator 
> has to wait configuring user services on these cards until they are
inserted.
> 2. the network operator determines that a node will "run out" of 
> available ports and hence wants to start planning new configuration 
> and hence he wants to configure some boards in the empty slots and 
> even may want to start to pre-configure certain data of the ports 
> contained by these boards.  In that case we need the RW leaf to 
> indicate which board type will be inserted as the service that can be 
> offered depends on the board being inserted.  When the board is 
> inserted, the planned configuration can directly be applied to the 
> newly inserted board (given the fact that the detected class is the same
as the planned class).

Shouldn't this be handled by the support for pre-configuration in the
interfaces data model?  I.e., the general model would be that the
entity/hardware list is monitoring of the hardware that is really present,
and other models that need to refer to this hardware (like
interfaces) support pre-configuration.

The interface model lacks an explicit pointer to the entity/hardware model;
but in many systems this reference is implicit in the name of the interface.


/martin



> There are customers using method 1 and other customers use method 2.
> 
> > -          contained-in: for plugable items contained-in requires to be
> > mandatory too as a plugable item can't be "floating" in the device.
> 
> Can you explain in more detail what this means, and provide some use 
> cases?
>
> [Bart Bogaert] For DSL we are faced with "wiring" aspects that "ripple 
> through" to the MDF.  So assume we again have a system with plugable
slots.
> If we have 2 slots containing the same type of board (same class) and 
> the operator is applying the pre-configuration mode of working (method 
> 2 in above), we have to be sure that user A, connected to the first 
> port of the board plugged in the first slot will really be in slot 1.  
> If the NC client has no means to detect which board is plugged in 
> which slot (they are both of the same class) we need other means to 
> ensure the containment is as intended (and user A being connected to 
> the first port of the board in slot A is also visualized as such on 
> the GUI of the NC client).  Using the serial number of the board seems 
> not very practical as board may break and are sent to repair or 
> replaced by another board of the same type but with a different serial 
> number.  I do not think operators will like it a lot to manage a 
> system in a manual way based on these attributes hence also a need to plan
a board in a specific slot.


------=_NextPart_000_073F_01D201E7.0AD96C20
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODI5MDkxODE3WjAjBgkqhkiG9w0B
CQQxFgQUeJmiorTsMB0EIeUaO2O3+CVebq8wgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQAP
fDbPC51GL/Hf9pfLE0w1nNEOrP6Knt05NQEf/SsArEYnhP39aZB7WSFOu4oiqRVxObFvWjMKGWZp
2yjnniPkWq2MT3GgoU+F9c7x6NYI/X+XXNET+1WXP16boAwIe6vL26HDNR7x1gYpTiMBN257xB62
HlIuwpVoz41kAMbVYb0zOA3RFnM1DdnQsb1pec6yKWF59mMFR7wF14IlcnMAcnHkBLC5P20gAvua
LiT64Yh2RFZ/UNcCsfCqONM9/oVsvfVQ0aqdM4RrXoZg4Zng1oQflRMsCfnXoFJj+LJBeHLdgxW3
RRwjrLyYBL7jDqJTYKjybift4ME1eISqoHYbAAAAAAAA

------=_NextPart_000_073F_01D201E7.0AD96C20--


From nobody Mon Aug 29 02:26: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 766D612D17E for ; Mon, 29 Aug 2016 02:26:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 H5ihg859GxhW for ; Mon, 29 Aug 2016 02:26:31 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2A61312B017 for ; Mon, 29 Aug 2016 02:26:31 -0700 (PDT)
Received: from localhost (unknown [173.38.220.42]) by mail.tail-f.com (Postfix) with ESMTPSA id 518241AE018C; Mon, 29 Aug 2016 11:26:30 +0200 (CEST)
Date: Mon, 29 Aug 2016 11:25:34 +0200 (CEST)
Message-Id: <20160829.112534.27697508444036407.mbj@tail-f.com>
To: bart.bogaert@nokia.com
From: Martin Bjorklund 
In-Reply-To: 
References: <20160829.110623.2040913040360172503.mbj@tail-f.com> 
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] BBF extensions to ietf-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: Mon, 29 Aug 2016 09:26:32 -0000

"Bogaert, Bart (Nokia - BE)"  wrote:
> Hi Martin,
> 
> In BBF this pointer from HW to interface will be available (it has been
> proposed in the Berling BBF meeting already).

I assume this is done as an augmentation?  Is it an augmentation to
the interface list, or to the hardware list?  I.e., is it a pointer
from an interface to the hardware, or the other way around?

I would prefer to view the hardware list as just monitoring (config
false) [1], and have config true pointers from the higher-level
concepts back to the hardware [2].  Possibly with config false
back-pointers.

[1] this doesn't preclude the config true list in current ietf-entity.

[2] this pointer is (as noted) often implicit in the interface name
today.


/martin





> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data
> Contact number +32 3 2408310 (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium
> Fortis 220-0002334-42
> VAT BE 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential information
> intended for a specific individual and purpose, and is protected by law. If
> you are not the intended recipient, you should delete this message. Any
> disclosure, copying, or distribution of this message, or the taking of any
> action based on it, is strictly prohibited without the prior consent of its
> author.
> >> 
> 
> 
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com] 
> Sent: 29 August 2016 11:06
> To: Bogaert, Bart (Nokia - BE)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] BBF extensions to ietf-entity
> 
> Hi,
> 
> [We had mail server problems during the weekend, so this reply might not get
> the thread's history right.]
> 
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > Martin Bjorklund  wrote:
> > "Bogaert, Bart (Nokia - BE)"  wrote:
> > > I would like to bring this to the ietf-entity group.  Currently BBF 
> > > is proposing to add new RW leafs to the entity object.  This is done 
> > > in the context of plugable entities and hence it means that when an 
> > > operator (via a NC client) configures a plugable item it is required 
> > > to define the entity type.  For this reason additional RW attributes 
> > > are needed.  Two of the new leafs are class and contained-in (same as
> the RO class leaf).
> > > 
> > > -          class: we think that the class leaf needs to be mandatory but
> > > adding this via an augment is not possible as we can't add a 
> > > mandatory leaf via an augment.  Making class implicit for the client 
> > > based on "some information" exchanged between device vendors and 
> > > management applications is maybe not such a sound approach.
> > 
> > Can you explain in more detail how this would be used?  The idea is 
> > that 'class' is a property of the physical hw, and that the underlying 
> > system provides this info.  I can see that it could be useful for the 
> > client to set this if the system can't do the classification (i.e., 
> > the system-set value is 'unknown').  But that's probably not the use 
> > case you had in mind?
> > 
> > [Bart Bogaert] Assume you have a system with a number of slots that 
> > can hold several different cards and the system was deployed in the 
> > field with some cards inserted and some other slots that were still 
> > left empty.  When an operator wants to extend the system we can have 2
> ways of doing this:
> > 1. a field engineer goes 'on-site' and plugs cards in the system.  If 
> > done this way, the system itself can detect what has been inserted and 
> > we do not really need the RW leafs.  However in this case an operator 
> > has to wait configuring user services on these cards until they are
> inserted.
> > 2. the network operator determines that a node will "run out" of 
> > available ports and hence wants to start planning new configuration 
> > and hence he wants to configure some boards in the empty slots and 
> > even may want to start to pre-configure certain data of the ports 
> > contained by these boards.  In that case we need the RW leaf to 
> > indicate which board type will be inserted as the service that can be 
> > offered depends on the board being inserted.  When the board is 
> > inserted, the planned configuration can directly be applied to the 
> > newly inserted board (given the fact that the detected class is the same
> as the planned class).
> 
> Shouldn't this be handled by the support for pre-configuration in the
> interfaces data model?  I.e., the general model would be that the
> entity/hardware list is monitoring of the hardware that is really present,
> and other models that need to refer to this hardware (like
> interfaces) support pre-configuration.
> 
> The interface model lacks an explicit pointer to the entity/hardware model;
> but in many systems this reference is implicit in the name of the interface.
> 
> 
> /martin
> 
> 
> 
> > There are customers using method 1 and other customers use method 2.
> > 
> > > -          contained-in: for plugable items contained-in requires to be
> > > mandatory too as a plugable item can't be "floating" in the device.
> > 
> > Can you explain in more detail what this means, and provide some use 
> > cases?
> >
> > [Bart Bogaert] For DSL we are faced with "wiring" aspects that "ripple 
> > through" to the MDF.  So assume we again have a system with plugable
> slots.
> > If we have 2 slots containing the same type of board (same class) and 
> > the operator is applying the pre-configuration mode of working (method 
> > 2 in above), we have to be sure that user A, connected to the first 
> > port of the board plugged in the first slot will really be in slot 1.  
> > If the NC client has no means to detect which board is plugged in 
> > which slot (they are both of the same class) we need other means to 
> > ensure the containment is as intended (and user A being connected to 
> > the first port of the board in slot A is also visualized as such on 
> > the GUI of the NC client).  Using the serial number of the board seems 
> > not very practical as board may break and are sent to repair or 
> > replaced by another board of the same type but with a different serial 
> > number.  I do not think operators will like it a lot to manage a 
> > system in a manual way based on these attributes hence also a need to plan
> a board in a specific slot.
> 


From nobody Mon Aug 29 02:31: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 4FFC512D149 for ; Mon, 29 Aug 2016 02:31:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 8nbzM4adi6w3 for ; Mon, 29 Aug 2016 02:31:04 -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 4348312D13F for ; Mon, 29 Aug 2016 02:31:04 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id DD2B77DB8FE3F; Mon, 29 Aug 2016 09:31:00 +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 u7T9V2tk012161 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Aug 2016 09:31:02 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u7T9V1lF003190 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Aug 2016 11:31:01 +0200
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.83]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 29 Aug 2016 11:31:01 +0200
From: "Bogaert, Bart (Nokia - BE)" 
To: Martin Bjorklund 
Thread-Topic: [netmod] BBF extensions to ietf-entity
Thread-Index: AQHSAdSd3dfqTKzQR3WYPaIL6IHWCqBfqKbg///gwACAACKLAA==
Date: Mon, 29 Aug 2016 09:31:01 +0000
Message-ID: 
References: <20160829.110623.2040913040360172503.mbj@tail-f.com>  <20160829.112534.27697508444036407.mbj@tail-f.com>
In-Reply-To: <20160829.112534.27697508444036407.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_074B_01D201E8.D199BE40"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] BBF extensions to ietf-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: Mon, 29 Aug 2016 09:31:07 -0000

------=_NextPart_000_074B_01D201E8.D199BE40
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

"Bogaert, Bart (Nokia - BE)"  wrote:
> Hi Martin,
> 
> In BBF this pointer from HW to interface will be available (it has 
> been proposed in the Berling BBF meeting already).

I assume this is done as an augmentation?  Is it an augmentation to the
interface list, or to the hardware list?  I.e., is it a pointer from an
interface to the hardware, or the other way around?
[Bart Bogaert] It is an augmentation to the hardware list

Bart

I would prefer to view the hardware list as just monitoring (config
false) [1], and have config true pointers from the higher-level concepts
back to the hardware [2].  Possibly with config false back-pointers.

[1] this doesn't preclude the config true list in current ietf-entity.

[2] this pointer is (as noted) often implicit in the interface name today.


/martin





> 
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data Contact number +32 3 2408310 
> (+32 477 673952)
> 
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE 
> 0404 621 642 Register of Legal Entities Antwerp
> 
> <<
> This message (including any attachments) contains confidential 
> information intended for a specific individual and purpose, and is 
> protected by law. If you are not the intended recipient, you should 
> delete this message. Any disclosure, copying, or distribution of this 
> message, or the taking of any action based on it, is strictly 
> prohibited without the prior consent of its author.
> >> 
> 
> 
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: 29 August 2016 11:06
> To: Bogaert, Bart (Nokia - BE)
> Cc: netmod@ietf.org
> Subject: Re: [netmod] BBF extensions to ietf-entity
> 
> Hi,
> 
> [We had mail server problems during the weekend, so this reply might 
> not get the thread's history right.]
> 
> "Bogaert, Bart (Nokia - BE)"  wrote:
> > Martin Bjorklund  wrote:
> > "Bogaert, Bart (Nokia - BE)"  wrote:
> > > I would like to bring this to the ietf-entity group.  Currently 
> > > BBF is proposing to add new RW leafs to the entity object.  This 
> > > is done in the context of plugable entities and hence it means 
> > > that when an operator (via a NC client) configures a plugable item 
> > > it is required to define the entity type.  For this reason 
> > > additional RW attributes are needed.  Two of the new leafs are 
> > > class and contained-in (same as
> the RO class leaf).
> > > 
> > > -          class: we think that the class leaf needs to be mandatory
but
> > > adding this via an augment is not possible as we can't add a 
> > > mandatory leaf via an augment.  Making class implicit for the 
> > > client based on "some information" exchanged between device 
> > > vendors and management applications is maybe not such a sound
approach.
> > 
> > Can you explain in more detail how this would be used?  The idea is 
> > that 'class' is a property of the physical hw, and that the 
> > underlying system provides this info.  I can see that it could be 
> > useful for the client to set this if the system can't do the 
> > classification (i.e., the system-set value is 'unknown').  But 
> > that's probably not the use case you had in mind?
> > 
> > [Bart Bogaert] Assume you have a system with a number of slots that 
> > can hold several different cards and the system was deployed in the 
> > field with some cards inserted and some other slots that were still 
> > left empty.  When an operator wants to extend the system we can have 
> > 2
> ways of doing this:
> > 1. a field engineer goes 'on-site' and plugs cards in the system.  
> > If done this way, the system itself can detect what has been 
> > inserted and we do not really need the RW leafs.  However in this 
> > case an operator has to wait configuring user services on these 
> > cards until they are
> inserted.
> > 2. the network operator determines that a node will "run out" of 
> > available ports and hence wants to start planning new configuration 
> > and hence he wants to configure some boards in the empty slots and 
> > even may want to start to pre-configure certain data of the ports 
> > contained by these boards.  In that case we need the RW leaf to 
> > indicate which board type will be inserted as the service that can 
> > be offered depends on the board being inserted.  When the board is 
> > inserted, the planned configuration can directly be applied to the 
> > newly inserted board (given the fact that the detected class is the 
> > same
> as the planned class).
> 
> Shouldn't this be handled by the support for pre-configuration in the 
> interfaces data model?  I.e., the general model would be that the 
> entity/hardware list is monitoring of the hardware that is really 
> present, and other models that need to refer to this hardware (like
> interfaces) support pre-configuration.
> 
> The interface model lacks an explicit pointer to the entity/hardware 
> model; but in many systems this reference is implicit in the name of the
interface.
> 
> 
> /martin
> 
> 
> 
> > There are customers using method 1 and other customers use method 2.
> > 
> > > -          contained-in: for plugable items contained-in requires to
be
> > > mandatory too as a plugable item can't be "floating" in the device.
> > 
> > Can you explain in more detail what this means, and provide some use 
> > cases?
> >
> > [Bart Bogaert] For DSL we are faced with "wiring" aspects that 
> > "ripple through" to the MDF.  So assume we again have a system with 
> > plugable
> slots.
> > If we have 2 slots containing the same type of board (same class) 
> > and the operator is applying the pre-configuration mode of working 
> > (method
> > 2 in above), we have to be sure that user A, connected to the first 
> > port of the board plugged in the first slot will really be in slot 1.
> > If the NC client has no means to detect which board is plugged in 
> > which slot (they are both of the same class) we need other means to 
> > ensure the containment is as intended (and user A being connected to 
> > the first port of the board in slot A is also visualized as such on 
> > the GUI of the NC client).  Using the serial number of the board 
> > seems not very practical as board may break and are sent to repair 
> > or replaced by another board of the same type but with a different 
> > serial number.  I do not think operators will like it a lot to 
> > manage a system in a manual way based on these attributes hence also 
> > a need to plan
> a board in a specific slot.
> 

------=_NextPart_000_074B_01D201E8.D199BE40
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODI5MDkzMTAwWjAjBgkqhkiG9w0B
CQQxFgQUb5Yhzs1aUcF3K/M56WCx2dHUiaEwgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQAN
Lbl12uFZLFLslrkxW0mhun+8rvfslDTIhx1Xez/meX0AJvK24ZEtOK3C7B8DAIorklpNA9ytPuJ4
GvdBp3M8XKGxS4RZbClmAkgRy5RZlw0rXY35GWQZgciV7g+00ZQZykRbeIVTscwpZn6fgU60b3Bm
P79ZrgSnWfZ3EvK0++0+Uv3s+XfgBd1ygmrDEXbE2RKGFNzzAY6HCGy48jrfdLxHjBjGBob/kSuv
UkVuMdoU3TIeWKujjFVLH5KBarE3DREwrzmdKtR1VMEPWvgXm16M0xEDVVUcptPPxEqi+2q/OsoE
95+olCEDb6nxmSZl+c4QyHISrvdLPPyTTNkwAAAAAAAA

------=_NextPart_000_074B_01D201E8.D199BE40--


From nobody Mon Aug 29 03:34: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 5F67112D5A2 for ; Mon, 29 Aug 2016 03:34:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 X9HpYuXCrEsp for ; Mon, 29 Aug 2016 03:34:14 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3C8FB12D5A5 for ; Mon, 29 Aug 2016 03:34:13 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:6cc7:4fe7:80a2:f91a] (unknown [IPv6:2001:718:1a02:1:6cc7:4fe7:80a2:f91a]) by mail.nic.cz (Postfix) with ESMTPSA id EA552681D7; Mon, 29 Aug 2016 12:34:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1472466851; bh=n5pjSawJXumUpW5iI8EvQp5fis4PEjwHXEMpjB+iYJo=; h=From:Date:To; b=NWDTw94dEtHXh2n6i0+tdpFnVaVAfECFwq5h1gaXpgtG2ZY/ShGqS+p5MXDFB6H/R aFBGdL1HDfdGaBs+JOKftUcIaZ+XYjjqNOs6zY4+bRzte2By4Pi26e5khVrBX03cZ3 t2N2KS/aT0F8/Ak+GD96Xwk3/aQaQX7LHbIoB8+M=
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_2879F4E8-5198-427E-B5C6-4DAD26DDFFA0"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail
From: Ladislav Lhotka 
In-Reply-To: 
Date: Mon, 29 Aug 2016 12:34:15 +0200
Message-Id: <7E63DECD-A1D3-441A-9BFF-5AE83CB529CA@nic.cz>
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local> <20160826.143230.1673334253843878893.mbj@tail-f.com> 
To: "Bogaert, Bart (Nokia - BE)" 
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] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 10:34:17 -0000

--Apple-Mail=_2879F4E8-5198-427E-B5C6-4DAD26DDFFA0
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii


> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE) =
 wrote:
>=20
> Just taking another approach on this: why do we have the restriction =
on
> circular imports?  Is this really required?  If not then this may be =
solved
> in another way too (but will take some time before it gets into the =
YANG
> compilers I'm afraid).

In fact, it isn't really needed. Unlike imports in programming languages =
such as Python, import in YANG doesn't incorporate the imported module =
contents, just gives access to objects in a foreign namespace.

Lada

>=20
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data
> Contact number +32 3 2408310 (+32 477 673952)
>=20
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium
> Fortis 220-0002334-42
> VAT BE 0404 621 642 Register of Legal Entities Antwerp
>=20
> <<
> This message (including any attachments) contains confidential =
information
> intended for a specific individual and purpose, and is protected by =
law. If
> you are not the intended recipient, you should delete this message. =
Any
> disclosure, copying, or distribution of this message, or the taking of =
any
> action based on it, is strictly prohibited without the prior consent =
of its
> author.
>>>=20
>=20
>=20
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: 26 August 2016 14:33
> To: j.schoenwaelder@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
>=20
> Juergen Schoenwaelder  wrote:
>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
>>>> On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia - =
BE)
> wrote:
>>>>=20
>>>> [...]
>>>>=20
>>>>> In order to correctly compile (using confdc) we also need to
>>>>> import iana-entity for the identities defined in there.  However
>>>>> this is leading a circular dependency:
>>>>>=20
>>>>> 1.       Iana-entity imports ietf-entity (to 'resolve'
>>>>> entity-physical-class)
>>>>>=20
>>>>> 2.       Ietf-entity imports iana-entity (to obtain the =
indentities
> defined
>>>>> in there)
>>>>>=20
>>>>> One way to solve this is to move the definition of
>>>>> entity-physical-class from ietf-entity to iana-entity which
>>>>> would resolve the fact that iana-entity requires an import of
>>>>> ietf-entity (ietf-entity needs to import iana-entity anyhow, so
>>>>> it can also pick the typedef from the same module too).
>>>>=20
>>>> I think moving the definition of entity-physical-class into
>>>> iana-entity makes sense.
>>>=20
>>> Ok.  It feels a bit backwards to me though, but I can see the value
>>> of having the iana module self-contained.
>>>=20
>>=20
>> Well, it may look backwards if people want to reuse the base identity
>> but none of the IANA assigned identities - but then it might be good
>> if people at least look at IANA assigned identities. Or are there
>> other reasons why you think this may be looking 'backwards'?
>=20
> I makes ietf-entity dependent on iana-entity, since the base identity =
is
> defined in iana-entity.
>=20
> But OTOH, even if we solved that, ietf-entity is dependent on =
iana-entity
> b/c of the value 'sensor'.
>=20
> So in this case it is probably fine, but I'm not sure about the =
general
> idea.
>=20
>=20
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





--Apple-Mail=_2879F4E8-5198-427E-B5C6-4DAD26DDFFA0
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-----

iEYEARECAAYFAlfED6gACgkQWQVCj+dOjAykewCgnUTiu+qvBtOWsk7Vl8yP6xba
z+4AnR2ao74aEIgNVroRwzprPycRehej
=ijhM
-----END PGP SIGNATURE-----

--Apple-Mail=_2879F4E8-5198-427E-B5C6-4DAD26DDFFA0--


From nobody Mon Aug 29 03:42: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 4066B12D5C2 for ; Mon, 29 Aug 2016 03:42:08 -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 cBDHS9RFXZ7e for ; Mon, 29 Aug 2016 03:42:06 -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 243D212D59F for ; Mon, 29 Aug 2016 03:42:06 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 94D6E1E5A34; Mon, 29 Aug 2016 03:37:30 -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 dzC9Ziey2pzn; Mon, 29 Aug 2016 03:37:30 -0700 (PDT)
Received: from [192.168.1.129] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id BAE141E5A1E; Mon, 29 Aug 2016 03:37:29 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: William Lupton 
In-Reply-To: <7E63DECD-A1D3-441A-9BFF-5AE83CB529CA@nic.cz>
Date: Mon, 29 Aug 2016 11:42:03 +0100
Content-Transfer-Encoding: quoted-printable
Message-Id: <28C16153-ED60-47ED-B647-C362F77B534C@broadband-forum.org>
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local> <20160826.143230.1673334253843878893.mbj@tail-f.com>  <7E63DECD-A1D3-441A-9BFF-5AE83CB529CA@nic.cz>
To: Ladislav Lhotka 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 10:42:08 -0000

Regardless of whether circular import is permitted, isn=E2=80=99t it =
best avoided from a layering point of view? In general I would think =
that a module should be importing things that (a) it needs, and (b) =
don=E2=80=99t need it. W.

> On 29 Aug 2016, at 11:34, Ladislav Lhotka  wrote:
>=20
>> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE) =
 wrote:
>>=20
>> Just taking another approach on this: why do we have the restriction =
on
>> circular imports?  Is this really required?  If not then this may be =
solved
>> in another way too (but will take some time before it gets into the =
YANG
>> compilers I'm afraid).
>=20
> In fact, it isn't really needed. Unlike imports in programming =
languages such as Python, import in YANG doesn't incorporate the =
imported module contents, just gives access to objects in a foreign =
namespace.


From nobody Mon Aug 29 03:51: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 5B98212D1A9 for ; Mon, 29 Aug 2016 03:51:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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 qFsKa5zSX-dH for ; Mon, 29 Aug 2016 03:51:05 -0700 (PDT)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 91B35127077 for ; Mon, 29 Aug 2016 03:51:04 -0700 (PDT)
X-AuditID: c1b4fb30-abfff700000009f9-8e-57c413965455
Received: from ESESSHC020.ericsson.se (Unknown_Domain [153.88.183.78]) by  (Symantec Mail Security) with SMTP id 4D.75.02553.69314C75; Mon, 29 Aug 2016 12:51:02 +0200 (CEST)
Received: from [159.107.197.173] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.80) with Microsoft SMTP Server id 14.3.301.0; Mon, 29 Aug 2016 12:51:01 +0200
To: Andy Bierman , Martin Bjorklund 
References: <6d87e060-3c52-38f6-e499-da3d7c20a783@ericsson.com> <20160826.102122.372934259558220723.mbj@tail-f.com>  <20160826.143830.937655299426629223.mbj@tail-f.com> 
From: Balazs Lengyel 
Message-ID: 
Date: Mon, 29 Aug 2016 12:51:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrLLMWRmVeSWpSXmKPExsUyM2K7n+404SPhBpuabCweHJnFbtHd/Yzd Yv7FRlYHZo8lS34yeWz8tZjFo6X/IksAcxSXTUpqTmZZapG+XQJXxvxr7cwFU4orDpy6xt7A uM6ri5GTQ0LARKJj/mT2LkYuDiGB9YwS/6fuY4Jw1jJKLF9yih2kSlhAT+LeF5AEB4eIgIfE mjluEDUzmCTeXXnPDFLDLKAucefUYzYQm03ASGJq/3kWEJtXwF7iw453LCC9LAKqEgvXCYOY ogIxEuv7EiAqBCVOznwCVs0pECix+f4GqIn6Etfv3GeFsOUlmrfOBosLCWhIPLzwl3UCo8As JO2zkLTMQtKygJF5FaNocWpxUm66kZFealFmcnFxfp5eXmrJJkZgoB7c8ttgB+PL546HGAU4 GJV4eBPeHQoXYk0sK67MPcQowcGsJMKbJHQkXIg3JbGyKrUoP76oNCe1+BCjNAeLkjiv/0vF cCGB9MSS1OzU1ILUIpgsEwenVANjY9rN0srFP2ed6bz36OykRRx3+VQkXk0TVOyN+HX6tkXq one/kvM3sU4zfL3pzd3npT/spAtvtl6VOFT3N43h+6aOm1fz+i8fi9EsEmFffi7aWKP5icNl zifxlys+zvprt1XthFDRdRvR4AWxYVt1dk/vmJj+1U293aO75crCFTtlTl4JeOaepMRSnJFo qMVcVJwIADxhPX5QAgAA
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] Design-Time 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, 29 Aug 2016 10:51:07 -0000


  
    
  
  
    
Hello Andy,

    
Martin's main problem was that we would need to update the
      original modules if the mount changes. I showed that design-time
      mount can be defined without modifying the original modules, if
      you specify the mount information in a separate file. So what
      specific problems are you concerned about?

    
I do not want to make schema-mount a purely design-time solution.
      However I feel that the ability to define the mounts in design
      time is an important use-case that does not cause any problems.

    

    
regards Balazs

    

    

    
On 2016-08-26 19:53, Andy Bierman
      wrote:

    

    

      
      
Hi,
        


        

        
I agree with Martin about not specifying which YANG modules

        
can be mounted under some mount point, in the YANG module.

        


        

        
The mount point needs some basic properties (like "config
          root", "opstate root", whatever).

        
Then data nodes are classified somehow (e.g.
          config=true/false) and that determines

        
what content can be mounted under that mount-point.

        


        

        
The combination of modules on the server needs to be a
          deployment decision to

        
prevent issues like Martin describes below.

        


        

        


        

        
Andy

        


        

      

      


        
On Fri, Aug 26, 2016 at 5:38 AM, Martin
          Bjorklund <mbj@tail-f.com>
          wrote:

          
Ladislav
            Lhotka <lhotka@nic.cz> wrote:

            > Martin Bjorklund <mbj@tail-f.com>
            writes:

            >

            > > Hi,

            > >

            > > [replying to the first post in this (old) thread;
            the thread got a bit

            > > off-topic]

            > >

            > > Balazs Lengyel <balazs.lengyel@ericsson.com>
            wrote:

            > >> Hello,

            > >>

            > >> As I understand it, Schema-mount today does
            not support an important

            > >> use-case which we definitely need, but others
            also indicated they

            > >> want.

            > >>

            > >> I want to specify off-line in design time
            which models will be mounted

            > >> where. Many of my nodes know in design-time
            what their model structure

            > >> will be, so I want a way to be able to
            document this in YANG.

            > >

            > > I'd like to understand this use case in more
            detail. You say that

            > > that a "node knows in design-time" that YANG
            models it will use. Thus

            > > it seems natural to be able to specify which other
            modules to mount in

            > > the YANG module itself.

            >

            > Did you have a chance to look into my slides from
            Berlin? I sketched some

            > solutions there.

            

            Well, that's a *solution*. I'd like to understand the
            *problem* first ;)

            

            > > The problem I see with this is that it is very
            limited to the use case

            > > where each implementation defines its own YANG
            modules. Suppose you

            > > have such a model, for example:

            > >

            > >  module A {

            > >   ...

            > >   mount ... {

            > >    mount-module B;

            > >    mount-module C;

            > >   }

            > > }

            > >

            > > [pseudo-code for module A that specifies that it
            mounts B and C]

            > >

            > > Now, suppose you take this module A to another
            implementation, and it

            > > needs to augment something into module C;
            essentially this means that

            > > it would like to mount B, C and new module D.
            This will not be

            > > possible unless it modifies module A.

            >

            > Not necessarily, D could contain an augment with a
            target specified by a

            > schema node identifier that uses nodes from both A and
            C.

            

            Not if B and D are defined as standalone modules, e.g. if B
            is

            ietf-interfaces and D is ietf-ip.

            

            > Imagine that instead of "ietf-ip" augmenting
            "ietf-interfaces" it would

            > be the other way around: "ietf-interfaces" mounts
            "ietf-ip". Then the

            > augment in ietf-ipv6-router-advertisements

            >

            > augment "/if:interfaces-state/if:interface/ip:ipv6"
            { ... }

            >

            > needn't be changed.

            

            This would be an entirely different kind of mount! The
            current mount

            doesn't work like that; it doesn't give you visibility into
            the

            combined models - by design.

            

            

            > The major problem with this IMO is that it needs a new
            YANG statement.

            >

            > >

            > >> In

            > >> today's proposal the only way to find the
            Yang-Mounts is to read it

            > >> from the live node.

            > >>

            > >> * OAM integrators or operators want to be able
            to write CLI scripts

            > >> and Netconf messages without accessing
            (expensive) real nodes. For

            > >> this they need to know the mounts

            > >> * We want to generate some fancy documentation
            from YANG automatically

            > >> in design-time.

            > >

            > > In a way this is no different from the situation
            today - in order to

            > > learn what YANG modules a device supports you need
            to connect and

            > > parse the <hello> message (or
            ietf-yang-library data in the near

            > > future). This info could also be made available
            off-line in a file.

            >

            > Yup. So we just need some machine-readable description
            of the structure

            > of mounted schemas.

            >

            > >

            > > It should certainly be possible to define a file
            format that a device

            > > somehow could "publish" off-line that contained
            all the info that is

            > > available at run-time. This file format could be
            exactly the same as

            > > you would get if you did a NETCONF <get/>
            operation with some filter

            > > to only retreive the ietf-yang-library data at the
            mount points.

            >

            > Well, if you have multiple levels of mounts, it will
            get messy: you

            > wouldn't know which yang-library data belongs to which
            mount point.

            

            Why not - imagine that you do a full <get/> on such a
            device, it will

            return the nested yang library data just fine.

            

            

            /martin

            

            

            > I believe some variation on YSDL could work, and as I
            wrote in another

            > thread, we could also incorporate datastores: after
            defining the

            > (multilevel) schemas, each datastore will get one
            assigned - and they

            > can also share them where needed.

            >

            > Lada

            >

            > >

            > >

            > >

            > > /martin

            > >

            > >

            > >>

            > >> * Many use cases need the possibility to mount
            schemas, but do not

            > >> need the added complexity of schema changes
            in run-time.

            > >> Notwithstanding the case of "YANG Features",
            for me the model schema

            > >> is a mostly static description of a nodes
            capabilities. Most of the

            > >> time I do not want to worry about the node
            changing its schema on

            > >> the fly.

            > >>

            > >>

            > >> For this I propose 2 YANG extensions

            > >>

            > >> extension schema-mount {

            > >> description "Indicates that a YANG Module is
            to be mounted into

            > >> another module.

            > >> The argument specifies the name of the module
            to be mounted.";

            > >> argument mounted-module;

            > >> }

            > >>

            > >> extension schema-mount-target {

            > >> description "Specifies the target node under
            which a YANG module is to

            > >> be mounted.

            > >> The statement can only be used inside a
            schema-mount statement.

            > >> The argument follows the same rules as an
            augment statement's target.

            > >> argument target-node;

            > >> }

            > >>

            > >> The two extension statements can be placed in
            a separate module or the

            > >> mounted module.

            > >>

            > >> I don't insist on the solution, but I need the
            off-line/design-time

            > >> specification of yang-mount to be possible.
            IMHO the design-time mount

            > >> use-case is more important than the
            dynamic-mount.

            > >>

            > >> regards Balazs

            > >> --

            > >> Balazs Lengyel           Ericsson
            Hungary Ltd.

            > >> Senior Specialist

            > >> Mobile: +36-70-330-7909       email: Balazs.Lengyel@ericsson.com

            > >

            > > _______________________________________________

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

          

        

        

      

      

      

      

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


    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Mon Aug 29 04:08: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 C1CAF12D5A5 for ; Mon, 29 Aug 2016 04:07:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, 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 IFGnyhags2RQ for ; Mon, 29 Aug 2016 04:07:55 -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 E646812D62F for ; Mon, 29 Aug 2016 04:07:54 -0700 (PDT)
Received: from fr712umx4.dmz.alcatel-lucent.com (unknown [135.245.210.45]) by Websense Email Security Gateway with ESMTPS id F0EDCF48A8140; Mon, 29 Aug 2016 11:07:50 +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 u7TB7qDk022783 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 29 Aug 2016 11:07:52 GMT
Received: from FR711WXCHHUB01.zeu.alcatel-lucent.com (fr711wxchhub01.zeu.alcatel-lucent.com [135.239.2.111]) by fr712usmtp2.zeu.alcatel-lucent.com (GMO) with ESMTP id u7TB7pPt028122 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 29 Aug 2016 13:07:51 +0200
Received: from FR712WXCHMBA09.zeu.alcatel-lucent.com ([169.254.5.83]) by FR711WXCHHUB01.zeu.alcatel-lucent.com ([135.239.2.111]) with mapi id 14.03.0195.001; Mon, 29 Aug 2016 13:07:51 +0200
From: "Bogaert, Bart (Nokia - BE)" 
To: Ladislav Lhotka 
Thread-Topic: [netmod] derived-from-or-self leads to circular import
Thread-Index: AQHR/4afRKY0tQ/rSm2MfMZEZSICVqBbCHGAgAACzQCABIA3gIAAFb2AgAAlYxA=
Date: Mon, 29 Aug 2016 11:07:51 +0000
Message-ID: 
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local> <20160826.143230.1673334253843878893.mbj@tail-f.com>  <7E63DECD-A1D3-441A-9BFF-5AE83CB529CA@nic.cz>
In-Reply-To: <7E63DECD-A1D3-441A-9BFF-5AE83CB529CA@nic.cz>
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_07BC_01D201F6.58696350"
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 11:07:58 -0000

------=_NextPart_000_07BC_01D201F6.58696350
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE)
 wrote:
>=20
> Just taking another approach on this: why do we have the restriction=20
> on circular imports?  Is this really required?  If not then this may=20
> be solved in another way too (but will take some time before it gets=20
> into the YANG compilers I'm afraid).

In fact, it isn't really needed. Unlike imports in programming languages
such as Python, import in YANG doesn't incorporate the imported module
contents, just gives access to objects in a foreign namespace.


[Bart Bogaert] This comes from RFC6020bis (and I guess it=92s in RFC6020 =
too):
There MUST NOT be any circular chains of imports. For example, if
module "a" imports module "b", "b" cannot import "a".

If this restriction is not really needed then why do we have that
restriction stated as such in the RFC?  The ConfD compiler reports =
exactly
this failure when trying to compile the IETF entity model for YANG 1.1
(tried 6.2 Confd-basic which can be obtained freely).  iana-entity.yang
imports ietf-entity (for the entity-physical-class identity) and
ietf-entity.yang imports iana-entity for the sensor identity - well that =
is
after changing the ietf-entiy model to also fix the error that the
derived-from-or-self function only has 2 parameters instead of 3 as
currently in the YANG models (the call to derived-from-or-self checks =
the
class leaf for "ent:sensor").  Fact is that the way the IETF/IANA entity
model is now defined in YANG results in something that results in
compilation errors and we need something that compiles error-free, =
meaning
we have to modify the iana and ietf-entity YANG model in some way.

Bart

Lada

>=20
> Best regards - Vriendelijke groeten,
> Bart Bogaert
> Broadband-Access System Architect Data Contact number +32 3 2408310=20
> (+32 477 673952)
>=20
> NOKIA
> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE=20
> 0404 621 642 Register of Legal Entities Antwerp
>=20
> <<
> This message (including any attachments) contains confidential=20
> information intended for a specific individual and purpose, and is=20
> protected by law. If you are not the intended recipient, you should=20
> delete this message. Any disclosure, copying, or distribution of this=20
> message, or the taking of any action based on it, is strictly=20
> prohibited without the prior consent of its author.
>>>=20
>=20
>=20
> -----Original Message-----
> From: Martin Bjorklund [mailto:mbj@tail-f.com]
> Sent: 26 August 2016 14:33
> To: j.schoenwaelder@jacobs-university.de
> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
> Subject: Re: [netmod] derived-from-or-self leads to circular import
>=20
> Juergen Schoenwaelder  wrote:
>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>> Juergen Schoenwaelder  wrote:
>>>> On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia -=20
>>>> BE)
> wrote:
>>>>=20
>>>> [...]
>>>>=20
>>>>> In order to correctly compile (using confdc) we also need to=20
>>>>> import iana-entity for the identities defined in there.  However=20
>>>>> this is leading a circular dependency:
>>>>>=20
>>>>> 1.       Iana-entity imports ietf-entity (to 'resolve'
>>>>> entity-physical-class)
>>>>>=20
>>>>> 2.       Ietf-entity imports iana-entity (to obtain the =
indentities
> defined
>>>>> in there)
>>>>>=20
>>>>> One way to solve this is to move the definition of=20
>>>>> entity-physical-class from ietf-entity to iana-entity which would=20
>>>>> resolve the fact that iana-entity requires an import of=20
>>>>> ietf-entity (ietf-entity needs to import iana-entity anyhow, so it =

>>>>> can also pick the typedef from the same module too).
>>>>=20
>>>> I think moving the definition of entity-physical-class into=20
>>>> iana-entity makes sense.
>>>=20
>>> Ok.  It feels a bit backwards to me though, but I can see the value=20
>>> of having the iana module self-contained.
>>>=20
>>=20
>> Well, it may look backwards if people want to reuse the base identity =

>> but none of the IANA assigned identities - but then it might be good=20
>> if people at least look at IANA assigned identities. Or are there=20
>> other reasons why you think this may be looking 'backwards'?
>=20
> I makes ietf-entity dependent on iana-entity, since the base identity=20
> is defined in iana-entity.
>=20
> But OTOH, even if we solved that, ietf-entity is dependent on=20
> iana-entity b/c of the value 'sensor'.
>=20
> So in this case it is probably fine, but I'm not sure about the=20
> general idea.
>=20
>=20
> /martin
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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





------=_NextPart_000_07BC_01D201F6.58696350
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
AQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTYwODI5MTEwNzUwWjAjBgkqhkiG9w0B
CQQxFgQUfpNbfaDyoAz8pGm7oKEsk6DFErowgaUGCSsGAQQBgjcQBDGBlzCBlDCBhTETMBEGCgmS
JomT8ixkARkWA2NvbTEWMBQGCgmSJomT8ixkARkWBmx1Y2VudDEUMBIGCgmSJomT8ixkARkWBG5h
MDIxFzAVBgNVBAoTDkFsY2F0ZWwgTHVjZW50MScwJQYDVQQDEx5BbGNhdGVsIEx1Y2VudCBJbnRl
cm5hbCBTdWIgQ0ECCl0WEbsAAAAA0PEwgacGCyqGSIb3DQEJEAILMYGXoIGUMIGFMRMwEQYKCZIm
iZPyLGQBGRYDY29tMRYwFAYKCZImiZPyLGQBGRYGbHVjZW50MRQwEgYKCZImiZPyLGQBGRYEbmEw
MjEXMBUGA1UEChMOQWxjYXRlbCBMdWNlbnQxJzAlBgNVBAMTHkFsY2F0ZWwgTHVjZW50IEludGVy
bmFsIFN1YiBDQQIKXRYRuwAAAADQ8TCBtwYJKoZIhvcNAQkPMYGpMIGmMAsGCWCGSAFlAwQBKjAL
BglghkgBZQMEARYwCgYIKoZIhvcNAwcwCwYJYIZIAWUDBAECMA4GCCqGSIb3DQMCAgIAgDAHBgUr
DgMCBzANBggqhkiG9w0DAgIBQDANBggqhkiG9w0DAgIBKDAHBgUrDgMCGjALBglghkgBZQMEAgMw
CwYJYIZIAWUDBAICMAsGCWCGSAFlAwQCATAKBggqhkiG9w0CBTANBgkqhkiG9w0BAQEFAASCAQCK
K+iVTIxj5/F9d9Tln9B0Zdu+wlwoUru8m0+1C/cgub5cCh+nWxxO1PuJ4z5R/oP3BpbHF4/IHUz7
Ie7ZjAwn21tHss9QD4vt52OBT0JJFUj8w46+bMcSQDmuFqGkONUHGW+pG8j5d9+QIFV/gD+/ojBR
aXe2IS0/JAa54S0pxos6kW0adusuwFJ8IfzxVjw6pLmGlOW9TsGoBnbO+qvH63DxC+ODnlnbCuYn
nhTpQkAxGCq+2LhSt8c8q5o153rDZ54/zFC9lM/BQG2Ys5XSAvd/1vPVw/A0AHKstLm0LcUow1T1
OburDKzsE/cyL819pI8uWAHRjDCWk3DfZErOAAAAAAAA

------=_NextPart_000_07BC_01D201F6.58696350--


From nobody Mon Aug 29 04:08: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 2F53B12D649 for ; Mon, 29 Aug 2016 04:08:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 iJTw9psavY_J for ; Mon, 29 Aug 2016 04:08:19 -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 6022412D62E for ; Mon, 29 Aug 2016 04:08:13 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:6cc7:4fe7:80a2:f91a] (unknown [IPv6:2001:718:1a02:1:6cc7:4fe7:80a2:f91a]) by mail.nic.cz (Postfix) with ESMTPSA id D698B74442; Mon, 29 Aug 2016 13:08:11 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1472468891; bh=jXAFjTI0uuyuiO5/khNJ7NE8Xxk6ozT8YWilPwuFHNw=; h=From:Date:To; b=sLwHeWjFvp9MQ/9SvpWD9jwEKnVbwHRNeJLC69ZD2x3Omway/vV/XbTJ7/bqYxhbV nVHRJQBqVkSzVMMe9OYaPWNgrSV06J5hRkgM02mx5Rybb0xvurqrFGmQKXWI9+7/wR bsTkv2zP9mQy/KxEWRjGg06aJ4ujyZfXhXzDSEw0=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <28C16153-ED60-47ED-B647-C362F77B534C@broadband-forum.org>
Date: Mon, 29 Aug 2016 13:08:16 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <75E1A126-C8E7-4951-93BF-49647CF4E6BF@nic.cz>
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local> <20160826.143230.1673334253843878893.mbj@tail-f.com>  <7E63DECD-A1D3-441A-9BFF-5AE83CB529CA@nic.cz> <28C16153-ED60-47ED-B647-C362F77B534C@broadband-forum.org>
To: William Lupton 
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] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 11:08:21 -0000

> On 29 Aug 2016, at 12:42, William Lupton  =
wrote:
>=20
> Regardless of whether circular import is permitted, isn=E2=80=99t it =
best avoided from a layering point of view? In general I would think =
that a module should be importing things that (a) it needs, and (b) =
don=E2=80=99t need it. W.

If possible, yes. However, not everything is strictly layered, sometimes =
it might be useful to put definitions into separate modules even if they =
are coupled in both directions.

Where cyclic references would be really harmful (groupings, identities), =
YANG spec excludes them explicitly - because they are harmful within the =
same module, too.

Lada

>=20
>> On 29 Aug 2016, at 11:34, Ladislav Lhotka  wrote:
>>=20
>>> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE) =
 wrote:
>>>=20
>>> Just taking another approach on this: why do we have the restriction =
on
>>> circular imports?  Is this really required?  If not then this may be =
solved
>>> in another way too (but will take some time before it gets into the =
YANG
>>> compilers I'm afraid).
>>=20
>> In fact, it isn't really needed. Unlike imports in programming =
languages such as Python, import in YANG doesn't incorporate the =
imported module contents, just gives access to objects in a foreign =
namespace.

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





From nobody Mon Aug 29 07:20: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 B13BA12D776 for ; Mon, 29 Aug 2016 07:20:15 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 jc8TcFakFmHP for ; Mon, 29 Aug 2016 07:20:12 -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 4DF0512D765 for ; Mon, 29 Aug 2016 07:20:11 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 324DC1E5A0A; Mon, 29 Aug 2016 07:15:35 -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 3ElJdgvuxwbn; Mon, 29 Aug 2016 07:15:35 -0700 (PDT)
Received: from [192.168.1.129] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id 2E25B1E5A07; Mon, 29 Aug 2016 07:15:34 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_82E6B93B-A17A-4F4C-A323-8DD2432DA674"
From: William Lupton 
In-Reply-To: 
Date: Mon, 29 Aug 2016 15:20:08 +0100
Message-Id: 
References:  <87pop4x2vu.fsf@hobgoblin.ariadne.com> 
To: Andy Bierman 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements in drafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 14:20:15 -0000

--Apple-Mail=_82E6B93B-A17A-4F4C-A323-8DD2432DA674
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Andy,

This thread started with discussion of an apparent ambiguity in the =
current text:

OLD

It is acceptable to reuse the same revision statement within unpublished =
versions (i.e., Internet-Drafts), but the revision date MUST be updated =
to a higher value each time the Internet-Draft is re-posted.

=E2=80=94=E2=80=94=20

It became clear from the subsequent discussion (thanks Randy!) that the =
above text isn=E2=80=99t intended to mean =E2=80=9Creuse the identical =
revision statement, INCLUDING THE REVISION DATE=E2=80=9D but to mean =
=E2=80=9Creuse the revision statement, UPDATING THE REVISION DATE=E2=80=9D=
.

Then other people raised other points, e.g only updating the revision =
date if the YANG has changed, distinguishing between the document and =
the YANG contained therein, and distinguishing between YANG in IDs and =
YANG created by other SDOs. My proposed new text tries to address all of =
these:

NEW:

It is not required to keep the full revision history of draft versions =
(e.g., modules contained within Internet-Drafts). That is, within a =
sequence of draft versions, only the most recent revision need be =
recorded in the module. However, if the module has changed, the revision =
date of the most recent revision MUST be updated to a later date =
whenever a new version is made available (e.g., via a new version of an =
Internet-Draft).

=E2=80=94=E2=80=94

I believe that this retains the original intent in a way that resolves =
the original ambiguity and addresses the other points that were raised. =
It it=E2=80=99s =E2=80=9Cworse=E2=80=9D, how is it worse (apart from =
being longer, on which point mea culpa)?

Thanks,
William

> On 19 Aug 2016, at 15:42, Andy Bierman  wrote:
>=20
> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley > wrote:
> Andy Bierman > writes:
> > An Internet-Draft is NOT a means of "publishing" a specification;
>=20
> As I said, that's the theory, but practice is considerably different.
>=20
> Anybody that implements a work-in-progress knows they are taking a =
risk
> on an unstable document.  The guideline already says MUST update
> the revision date.
>=20
> Not sure what more you want to guidelines document to do.
> =20
> Dale
>=20
> Andy

--Apple-Mail=_82E6B93B-A17A-4F4C-A323-8DD2432DA674
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8


Andy,

This thread started with discussion of an apparent =
ambiguity in the current text:

OLD

It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is =
re-posted.

=E2=80=94=E2=80=94 

It became clear from the =
subsequent discussion (thanks Randy!) that the above text isn=E2=80=99t =
intended to mean =E2=80=9Creuse the identical revision statement, =
INCLUDING THE REVISION DATE=E2=80=9D but to mean =E2=80=9Creuse the =
revision statement, UPDATING THE REVISION DATE=E2=80=9D.

Then other people raised =
other points, e.g only updating the revision date if the YANG has =
changed, distinguishing between the document and the YANG contained =
therein, and distinguishing between YANG in IDs and YANG created by =
other SDOs. My proposed new text tries to address all of =
these:

NEW:

It is not required to keep the full revision =
history of draft versions (e.g., modules contained within =
Internet-Drafts). That is, within a sequence of draft versions, only the =
most recent revision need be recorded in the module. However, if =
the module has changed, the revision date of the most recent revision =
MUST be updated to a later date whenever a new version is made available =
(e.g., via a new version of an Internet-Draft).

=E2=80=94=E2=80=94

I believe that this =
retains the original intent in a way that resolves the original =
ambiguity and addresses the other points that were raised. It it=E2=80=99s=
 =E2=80=9Cworse=E2=80=9D, how is it worse (apart from being longer, on =
which point mea culpa)?

Thanks,
William

On =
19 Aug 2016, at 15:42, Andy Bierman <andy@yumaworks.com> =
wrote:

On Fri, =
Aug 19, 2016 at 7:13 AM, Dale R. Worley <worley@ariadne.com> wrote:
Andy Bierman <andy@yumaworks.com> =
writes:

> An Internet-Draft is NOT a means of "publishing" a =
specification;



As I said, that's the theory, but practice is considerably =
different.

Anybody that implements a =
work-in-progress knows they are taking a risk
on an =
unstable document.  The guideline already says MUST =
update
the revision date.

Not sure what more you want to =
guidelines document to do.
 

Dale

Andy
=

--Apple-Mail=_82E6B93B-A17A-4F4C-A323-8DD2432DA674--


From nobody Mon Aug 29 09:01: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 9F86912D79A for ; Mon, 29 Aug 2016 09:01:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 RQceovwvmC8d for ; Mon, 29 Aug 2016 09:01:37 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 2602C12D75E for ; Mon, 29 Aug 2016 09:01:36 -0700 (PDT)
X-AuditID: c1b4fb3a-0618b980000009bd-24-57c45c5f5735
Received: from ESESSHC017.ericsson.se (Unknown_Domain [153.88.183.69]) by  (Symantec Mail Security) with SMTP id 09.F8.02493.F5C54C75; Mon, 29 Aug 2016 18:01:35 +0200 (CEST)
Received: from [159.107.197.173] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.71) with Microsoft SMTP Server id 14.3.301.0; Mon, 29 Aug 2016 18:00:51 +0200
To: "netmod@ietf.org" 
From: Balazs Lengyel 
Message-ID: 
Date: Mon, 29 Aug 2016 18:00:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZGbHdVTc+5ki4QedSJYv5FxtZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CV0X/xMWvBSq6Ki//lGxhncXQxcnJICJhI9Lb2M3YxcnEICaxn lPh4cj4rhLOWUWLNi6VMIFUiAuoSM3euZwOx2QSMJKb2n2cBsYUFPCXm//wDFucVsJeY1LwN qJ6Dg0VAVeL3UmkQU1QgRmJ9XwJEhaDEyZlPwDqZBSwkZs4/zwhhy0tsfzuHGcQWEtCQeHjh L+sERt5ZSFpmIWmZhaRlASPzKkbR4tTi4tx0IyO91KLM5OLi/Dy9vNSSTYzAsDm45bfVDsaD zx0PMQpwMCrx8Ca8OxQuxJpYVlyZe4hRgoNZSYR3hf+RcCHelMTKqtSi/Pii0pzU4kOM0hws SuK8/i8Vw4UE0hNLUrNTUwtSi2CyTBycUg2My5455nw4ednrfqjoZP+C2T9DjVZev+WYr1DH 3/27TiBcYYugE/PPRb+0hONv65jKX/0Rm2K0aN6lGElfvsbDuxcnvvv2UVJC379v7QT1+ZX9 NysVj7sbu+Ue/RYa8yeuln/j95Uav2fNrzq+Jdkv60LHXXWz+ZV6l2uYb5j0rom7t/qQrra6 EktxRqKhFnNRcSIAWnx2JhcCAAA=
Archived-At: 
Subject: [netmod] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 29 Aug 2016 16:01:42 -0000

Hello,

We have the following design pattern.

1) An enumeration or a set of identities are defined that define a set 
of options generally supported by Ericsson products.  (e.g. supported 
compression algorithms)
2) The specific node sets in run-time a leaf-list indicating the set of 
values that this specific node supports (e.g. 
nodes-supported-compression-types: zip, gzip, bz)
3) For some function the user has to select a specific option value 
(e.g. leaf file-compression for transferring backup files)

Problem: how do you restrict values for (3) - file-compression so that 
it is one of the nodes-supported-compression-types. The natural solution 
would be to use a must expression or a leaf-ref, but as 
nodes-supported-compression-types is config-false data, it is not 
allowed to constrain the config=true leaf, file-compression, with it.

It would be perfectly reasonable because the 
nodes-supported-compression-types only change during upgrade, but YANG 
does not allow this.

I would still like to have some modeled solution, not just plain English 
stating the constraint. Any idea how to do it?

regards Balazs


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Tue Aug 30 03:38: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 3A17812D0A9 for ; Tue, 30 Aug 2016 03:38:32 -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 PpsnhJqh6wMa for ; Tue, 30 Aug 2016 03:38:29 -0700 (PDT)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 2888A12B071 for ; Tue, 30 Aug 2016 03:38:29 -0700 (PDT)
Received: from localhost (unknown [195.113.220.110]) by trail.lhotka.name (Postfix) with ESMTPSA id B24481CC02E4; Tue, 30 Aug 2016 12:38:32 +0200 (CEST)
From: Ladislav Lhotka 
To: "Bogaert\, Bart \(Nokia - BE\)" 
In-Reply-To: 
References: <20160729133257.GA3317@elstar.local> <20160826.124304.1561054177442678773.mbj@tail-f.com> <20160826122229.GA32769@elstar.local> <20160826.143230.1673334253843878893.mbj@tail-f.com>  <7E63DECD-A1D3-441A-9BFF-5AE83CB529CA@nic.cz> 
User-Agent: Notmuch/0.22.1 (http://notmuchmail.org) Emacs/24.4.51.2 (x86_64-apple-darwin14.0.0)
Date: Tue, 30 Aug 2016 12:38:27 +0200
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] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 30 Aug 2016 10:38:32 -0000

"Bogaert, Bart (Nokia - BE)"  writes:

> [ Unknown signature status ]
>> On 29 Aug 2016, at 09:17, Bogaert, Bart (Nokia - BE)
>  wrote:
>>=20
>> Just taking another approach on this: why do we have the restriction=20
>> on circular imports?  Is this really required?  If not then this may=20
>> be solved in another way too (but will take some time before it gets=20
>> into the YANG compilers I'm afraid).
>
> In fact, it isn't really needed. Unlike imports in programming languages
> such as Python, import in YANG doesn't incorporate the imported module
> contents, just gives access to objects in a foreign namespace.
>
>
> [Bart Bogaert] This comes from RFC6020bis (and I guess it=C2=92s in RFC60=
20 too):
> There MUST NOT be any circular chains of imports. For example, if
> module "a" imports module "b", "b" cannot import "a".

Yes, but it's way too late to change this in 6020bis. We could consider
removing this restriction in the next revision of YANG.

Lada

>
> If this restriction is not really needed then why do we have that
> restriction stated as such in the RFC?  The ConfD compiler reports exactly
> this failure when trying to compile the IETF entity model for YANG 1.1
> (tried 6.2 Confd-basic which can be obtained freely).  iana-entity.yang
> imports ietf-entity (for the entity-physical-class identity) and
> ietf-entity.yang imports iana-entity for the sensor identity - well that =
is
> after changing the ietf-entiy model to also fix the error that the
> derived-from-or-self function only has 2 parameters instead of 3 as
> currently in the YANG models (the call to derived-from-or-self checks the
> class leaf for "ent:sensor").  Fact is that the way the IETF/IANA entity
> model is now defined in YANG results in something that results in
> compilation errors and we need something that compiles error-free, meaning
> we have to modify the iana and ietf-entity YANG model in some way.
>
> Bart
>
> Lada
>
>>=20
>> Best regards - Vriendelijke groeten,
>> Bart Bogaert
>> Broadband-Access System Architect Data Contact number +32 3 2408310=20
>> (+32 477 673952)
>>=20
>> NOKIA
>> Copernicuslaan 50, 2018 Antwerp, Belgium Fortis 220-0002334-42 VAT BE=20
>> 0404 621 642 Register of Legal Entities Antwerp
>>=20
>> <<
>> This message (including any attachments) contains confidential=20
>> information intended for a specific individual and purpose, and is=20
>> protected by law. If you are not the intended recipient, you should=20
>> delete this message. Any disclosure, copying, or distribution of this=20
>> message, or the taking of any action based on it, is strictly=20
>> prohibited without the prior consent of its author.
>>>>=20
>>=20
>>=20
>> -----Original Message-----
>> From: Martin Bjorklund [mailto:mbj@tail-f.com]
>> Sent: 26 August 2016 14:33
>> To: j.schoenwaelder@jacobs-university.de
>> Cc: Bogaert, Bart (Nokia - BE); netmod@ietf.org
>> Subject: Re: [netmod] derived-from-or-self leads to circular import
>>=20
>> Juergen Schoenwaelder  wrote:
>>> On Fri, Aug 26, 2016 at 12:43:04PM +0200, Martin Bjorklund wrote:
>>>> Juergen Schoenwaelder  wrote:
>>>>> On Fri, Jul 29, 2016 at 12:50:13PM +0000, Bogaert, Bart (Nokia -=20
>>>>> BE)
>> wrote:
>>>>>=20
>>>>> [...]
>>>>>=20
>>>>>> In order to correctly compile (using confdc) we also need to=20
>>>>>> import iana-entity for the identities defined in there.  However=20
>>>>>> this is leading a circular dependency:
>>>>>>=20
>>>>>> 1.       Iana-entity imports ietf-entity (to 'resolve'
>>>>>> entity-physical-class)
>>>>>>=20
>>>>>> 2.       Ietf-entity imports iana-entity (to obtain the indentities
>> defined
>>>>>> in there)
>>>>>>=20
>>>>>> One way to solve this is to move the definition of=20
>>>>>> entity-physical-class from ietf-entity to iana-entity which would=20
>>>>>> resolve the fact that iana-entity requires an import of=20
>>>>>> ietf-entity (ietf-entity needs to import iana-entity anyhow, so it=20
>>>>>> can also pick the typedef from the same module too).
>>>>>=20
>>>>> I think moving the definition of entity-physical-class into=20
>>>>> iana-entity makes sense.
>>>>=20
>>>> Ok.  It feels a bit backwards to me though, but I can see the value=20
>>>> of having the iana module self-contained.
>>>>=20
>>>=20
>>> Well, it may look backwards if people want to reuse the base identity=20
>>> but none of the IANA assigned identities - but then it might be good=20
>>> if people at least look at IANA assigned identities. Or are there=20
>>> other reasons why you think this may be looking 'backwards'?
>>=20
>> I makes ietf-entity dependent on iana-entity, since the base identity=20
>> is defined in iana-entity.
>>=20
>> But OTOH, even if we solved that, ietf-entity is dependent on=20
>> iana-entity b/c of the value 'sensor'.
>>=20
>> So in this case it is probably fine, but I'm not sure about the=20
>> general idea.
>>=20
>>=20
>> /martin
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>

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


From nobody Tue Aug 30 03:53: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 E7EB312D0BB for ; Tue, 30 Aug 2016 03:53:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.059
X-Spam-Level: 
X-Spam-Status: No, score=-15.059 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.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c-Irq_PqHASw for ; Tue, 30 Aug 2016 03:53:31 -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 2C8C712B05E for ; Tue, 30 Aug 2016 03:53:31 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=17921; q=dns/txt; s=iport; t=1472554411; x=1473764011; h=subject:references:to:from:message-id:date:mime-version: in-reply-to; bh=LXP8IoZ3iU9ts56ofbtQdY3wtyqNW0c0RyNICZt4HR0=; b=iQo7AVuujFR02EnIA8zItFRq0oU+Q0gjEudyLKvqPxxCAYPBA2zktUo/ yJ3daKWYLMKdsF9bmixGj9vSX9BL7KfGooX2TBZbEnN5rv9j0OBrgxeG8 wDyQsY//mHPt20u7yNMui29a8qH9UZslj76iPFNaiWUfLxArpjKoL5rlf I=;
X-IronPort-AV: E=Sophos;i="5.30,255,1470700800";  d="scan'208,217";a="687051743"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 30 Aug 2016 10:53:29 +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 u7UArTws002073; Tue, 30 Aug 2016 10:53:29 GMT
References: <2BBEF519D867E04EA729626C246A978715D4D5D7@eusaamb101.ericsson.se>
To: NETMOD Working Group , "Robert Wilton -X (rwilton - Ensoft Ltd at Cisco)" 
From: Benoit Claise 
X-Forwarded-Message-Id: <2BBEF519D867E04EA729626C246A978715D4D5D7@eusaamb101.ericsson.se>
Message-ID: 
Date: Tue, 30 Aug 2016 12:53:27 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <2BBEF519D867E04EA729626C246A978715D4D5D7@eusaamb101.ericsson.se>
Content-Type: multipart/alternative; boundary="------------4B2AD0C46177001D39B32FFB"
Archived-At: 
Subject: [netmod] Fwd: RE: Regarding IEEE/IETF coordination draft 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: Tue, 30 Aug 2016 10:53:34 -0000

This is a multi-part message in MIME format.
--------------4B2AD0C46177001D39B32FFB
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

Dear all,

As discussed with the IEEE, here is a way to progress 
draft-wilton-netmod-intf-vlan-yang
Rob, please update your draft with an Informational intended status.

Regards, Benoit

-------- Forwarded Message --------
Subject: 	RE: Regarding IEEE/IETF coordination draft 
draft-wilton-netmod-intf-vlan-yang
Date: 	Thu, 18 Aug 2016 19:51:14 +0000
From: 	Glenn Parsons 
To: 	Benoit Claise , Romascanu, Dan (Dan) 
, ops-ads@ietf.org 
CC: 	netconf-chairs@ietf.org , Robert Wilton -X 
(rwilton - Ensoft Ltd at Cisco) , Pat Thaler 
, Eric Gray , John 
Messenger , Paul Nikolich 
 (paul.nikolich@att.net) 



Subject: Regarding IEEE/IETF coordination draft 
draft-Wilton-netmod-intf-vlan-yang

To: Benoit Claise, Dan Romascanu

Date: July 28, 2016

Dear Benoit, Dan,

Thank you for your email (attached below) regarding IEEE/IETF

coordination draft draft-Wilton-netmod-intf-vlan-yang

In its July 2016 plenary meeting, IEEE 802.1  held detailed discussions

of YANG models for 802.1Q and 802.1X, the related interfaces, interface

stacks, and the service(s) offered to higher layer entities both in end

stations and attached to bridge ports. IEEE 802.1 will continue this

work in its September 2016 interim.

IEEE 802.1 agrees that progression of draft-Wilton-netmod-intf-vlan-yang

as an Informational RFC would be appropriate to meet immediate needs,

and values the details included in the document to ensure that the draft

does not deviate from 802.1 standards. IEEE 802.1 will continue its work

on standard YANG model, appreciates the contribution that other work can

make towards that standards goal, and would welcome participation by

IETF experts in its face-to-face discussions and teleconferences.

Regards,

Glenn.

--

Glenn Parsons - Chair, IEEE 802.1

glenn.parsons@ericsson.com 

+1-613-963-8141

*From:*Benoit Claise [mailto:bclaise@cisco.com]
*Sent:* Thursday, July 21, 2016 2:19 PM
*To:* Romascanu, Dan (Dan); John Messenger; ops-ads@ietf.org; Glenn Parsons
*Cc:* netconf-chairs@ietf.org; Robert Wilton -X (rwilton - Ensoft Ltd at 
Cisco); Pat Thaler; Eric Gray
*Subject:* Regarding IEEE/IETF coordination draft 
draft-wilton-netmod-intf-vlan-yang

Dear 802.1 WG,

In the IETF, we're considering how to 
progressdraft-wilton-netmod-intf-vlan-yang-03 
 , 
Sub-interface VLAN YANG Data Models, in order to allow IETF forwarding 
services to interact with 802.1Q VLAN tagged frames.
One option considered is to publish this draft as Informational RFC (as 
opposed to Proposed Standard), with the understanding that IEEE 802.1 
could develop an end station interface model that would considered as 
the reference standard.
Is this a viable solution from the viewpoint of 802.1Q?

The latest draft version contains YANG "must" statements to try to 
constrain the model such that only 802.1 compatible frames result.

Regards, Dan Romascanu (IETF Liaison Manager to IEEE-SA, Benoit Claise 
(IETF Operations and Management Area Director)




--------------4B2AD0C46177001D39B32FFB
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  

    
  
  
    Dear all,

    

    As discussed with the IEEE, here is a way to progress
    draft-wilton-netmod-intf-vlan-yang

    Rob, please update your draft with an Informational intended status.

    

    Regards, Benoit

    


      -------- Forwarded Message --------
      

        
          

            Subject:
            
            RE: Regarding IEEE/IETF coordination draft
              draft-wilton-netmod-intf-vlan-yang
          

          

            Date: 
            Thu, 18 Aug 2016 19:51:14 +0000
          

          

            From: 
            Glenn Parsons <glenn.parsons@ericsson.com>
          

          

            To: 
            Benoit Claise <bclaise@cisco.com>, Romascanu, Dan
              (Dan) <dromasca@avaya.com>, ops-ads@ietf.org
              <ops-ads@ietf.org>
          

          

            CC: 
            netconf-chairs@ietf.org <netconf-chairs@ietf.org>,
              Robert Wilton -X (rwilton - Ensoft Ltd at Cisco)
              <rwilton@cisco.com>, Pat Thaler
              <pthaler@BROADCOM.COM>, Eric Gray
              <eric.gray@ericsson.com>, John Messenger
              <jmessenger@advaoptical.com>, Paul Nikolich
              <paul.nikolich@att.net> (paul.nikolich@att.net)
              <paul.nikolich@att.net>
          

        
      

      

      

      
      
      
      

        
Subject:
            Regarding IEEE/IETF coordination draft
            draft-Wilton-netmod-intf-vlan-yang

        
To:
            Benoit Claise, Dan Romascanu

        
Date: 
            July 28, 2016

        
 

        
 

        
Dear
            Benoit, Dan,

        
 

        
Thank
            you for your email (attached below) regarding IEEE/IETF

        
coordination
            draft draft-Wilton-netmod-intf-vlan-yang

        
 

        
In
            its July 2016 plenary meeting, IEEE 802.1  held detailed
            discussions

        
of 
            YANG models for 802.1Q and 802.1X, the related interfaces,
            interface

        
stacks,
            and the service(s) offered to higher layer entities both in
            end

        
stations
            and attached to bridge ports. IEEE 802.1 will continue this

        
work
            in its September 2016 interim.

        
 

        
IEEE
            802.1 agrees that progression of
            draft-Wilton-netmod-intf-vlan-yang

        
as
            an Informational RFC would be appropriate to meet immediate
            needs,

        
and
            values the details included in the document to ensure that
            the draft

        
does
            not deviate from 802.1 standards. IEEE 802.1 will continue
            its work

        
on
            standard YANG model, appreciates the contribution that other
            work can

        
make
            towards that standards goal, and would welcome participation
            by

        
IETF
            experts in its face-to-face discussions and teleconferences.

        
 

        
 

        
Regards,

        
Glenn.

        
 

        
--

        
Glenn
            Parsons - Chair, IEEE 802.1

        
glenn.parsons@ericsson.com

        
+1-613-963-8141

        
 

        
 

        
 

        
 

        

          

            
From:
                Benoit Claise [mailto:bclaise@cisco.com]
                

                Sent: Thursday, July 21, 2016 2:19 PM

                To: Romascanu, Dan (Dan); John Messenger;
                ops-ads@ietf.org; Glenn Parsons

                Cc: netconf-chairs@ietf.org; Robert Wilton -X
                (rwilton - Ensoft Ltd at Cisco); Pat Thaler; Eric Gray

                Subject: Regarding IEEE/IETF coordination draft
                draft-wilton-netmod-intf-vlan-yang

          

        

        
 

        
Dear 802.1 WG,

          

          In the IETF, we're considering how to progress
            draft-wilton-netmod-intf-vlan-yang-03 , Sub-interface
          VLAN YANG Data Models, in order to allow IETF forwarding
          services to interact with 802.1Q VLAN tagged frames.

          One option considered is to publish this draft as
          Informational RFC (as opposed to Proposed Standard), with the
          understanding that IEEE 802.1 could develop an end station
          interface model that would considered as the reference
          standard.

          Is this a viable solution from the viewpoint of 802.1Q?

          

          The latest draft version contains YANG "must" statements to
          try to constrain the model such that only 802.1 compatible
          frames result.

          

          Regards, Dan Romascanu (IETF Liaison Manager to IEEE-SA,
          Benoit Claise (IETF Operations and Management Area Director)
          

           

          

          

          

      

    

  


--------------4B2AD0C46177001D39B32FFB--


From nobody Tue Aug 30 06:15: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 92BE012D0A5 for ; Tue, 30 Aug 2016 06:15:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 ZNHn2qsx9Szv for ; Tue, 30 Aug 2016 06:15:33 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 94F2112D52D for ; Tue, 30 Aug 2016 06:14:21 -0700 (PDT)
Received: from [10.147.40.138] (unknown [173.38.220.52]) by mail.tail-f.com (Postfix) with ESMTPSA id D4BF21AE03DD; Tue, 30 Aug 2016 15:14:15 +0200 (CEST)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/signed; boundary="Apple-Mail=_DC620602-8E19-487B-A5B3-CEE5F5989A21"; protocol="application/pgp-signature"; micalg=pgp-sha512
X-Pgp-Agent: GPGMail
From: Jan Lindblad 
In-Reply-To: 
Date: Tue, 30 Aug 2016 15:14:21 +0200
Message-Id: <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com>
References: 
To: Balazs Lengyel 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 30 Aug 2016 13:15:39 -0000

--Apple-Mail=_DC620602-8E19-487B-A5B3-CEE5F5989A21
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Balazs,

> We have the following design pattern.
>=20
> 1) An enumeration or a set of identities are defined that define a set =
of options generally supported by Ericsson products.  (e.g. supported =
compression algorithms)
> 2) The specific node sets in run-time a leaf-list indicating the set =
of values that this specific node supports (e.g. =
nodes-supported-compression-types: zip, gzip, bz)
> 3) For some function the user has to select a specific option value =
(e.g. leaf file-compression for transferring backup files)
>=20
> Problem: how do you restrict values for (3) - file-compression so that =
it is one of the nodes-supported-compression-types. The natural solution =
would be to use a must expression or a leaf-ref, but as =
nodes-supported-compression-types is config-false data, it is not =
allowed to constrain the config=3Dtrue leaf, file-compression, with it.
>=20
> It would be perfectly reasonable because the =
nodes-supported-compression-types only change during upgrade, but YANG =
does not allow this.
>=20
> I would still like to have some modeled solution, not just plain =
English stating the constraint. Any idea how to do it?

I have seen this use case many times. I usually solve this by making a =
container with device specific limits, lists of supported values, etc, =
which is config true but with nacm rules preventing everyone from making =
changes. Then I have a device specific database initialization file with =
the correct settings for this device, which is loaded into the database =
at first boot.

/jan


--Apple-Mail=_DC620602-8E19-487B-A5B3-CEE5F5989A21
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

iQEcBAEBCgAGBQJXxYatAAoJEBSCnbqufIisjPIH+waiOhSSqtI/SS1gbwdOIjKE
HITukDkvvzbVSdVliGSQBWAPBy3l+Pnd12WT8RxLmYSD9MSk77MSWPsf6EwaATDP
F/M42sc3RfY4xDW1zXrsarzvev6O2sg1o3EW+EXYPcW2Fn8tEgpj7JL24yS++eQ6
T3lK4VhXuiyCrh3jgSn6TD8t0YaBNNkrwLCKO905YpfeJwaExISSBUKHfalS0Dnx
y2FMQyYnG6K0j9CTJ5QcbSjM/H2GoUehtoiGnfh7DwBVK14RhEgir4/L4wxfvHVA
DNvqC+gLCKNahSlko+vRaHGrLX0G7rckluWk1oz2uRDS/rouHjJt9ADEuhORD2k=
=F5kY
-----END PGP SIGNATURE-----

--Apple-Mail=_DC620602-8E19-487B-A5B3-CEE5F5989A21--


From nobody Tue Aug 30 07:07: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 0F83712D65E for ; Tue, 30 Aug 2016 07:07:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dwes3YoKyHcQ for ; Tue, 30 Aug 2016 07:07:47 -0700 (PDT)
Received: from resqmta-ch2-08v.sys.comcast.net (resqmta-ch2-08v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:40]) (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 3711A12D5F7 for ; Tue, 30 Aug 2016 07:07:47 -0700 (PDT)
Received: from resomta-ch2-09v.sys.comcast.net ([69.252.207.105]) by resqmta-ch2-08v.sys.comcast.net with SMTP id ejhRbkBMO84vjejhab2Wz8; Tue, 30 Aug 2016 14:07:46 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-09v.sys.comcast.net with SMTP id ejhZbUCmxm47VejhabMi8Q; Tue, 30 Aug 2016 14:07:46 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7UE7jTb004123; Tue, 30 Aug 2016 10:07:45 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7UE7jCY004116; Tue, 30 Aug 2016 10:07:45 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: Balazs Lengyel 
In-Reply-To:  (balazs.lengyel@ericsson.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Tue, 30 Aug 2016 10:07:45 -0400
Message-ID: <8737lm2vv2.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfIg0zrcVEDDfrW1AV/IOURXJllQ8uUcQIsRul5ldFyotGmQWGv4ILo0ST0EGC80NmfmaBcAITnxIymnsDSO/tlgrhV5DTa49HPIMOb/BHQaqGVHW669p 4ysOXD90LK2lFWFvn+4b9fnSfZTvI6mQSz3z0sd/XC1odfH1lMbRmPJ//ZeqjgzC4M10knowzFecNS+CUrhVJe0cOPytuqPuYz4=
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 30 Aug 2016 14:07:51 -0000

Balazs Lengyel  writes:
> Problem: how do you restrict values for (3) - file-compression so that 
> it is one of the nodes-supported-compression-types. The natural solution 
> would be to use a must expression or a leaf-ref, but as 
> nodes-supported-compression-types is config-false data, it is not 
> allowed to constrain the config=true leaf, file-compression, with it.

I'm no expert at this, but it seems to me that the way to do it is to
have the overall data structure be config-true but make the contained
supported-compression-types be config-false.  You can nest config-false
nodes in a config-true structure.  The Yang would be something like
this:

typedef Compression-Method {
  ...
}

list node {
  config true;
  key name;

  string name;

  leaf-list supported-compression-methods {
    type Compression-Method;
    config false;
  }

  Compression-Method compression-method;
  must "compression-method ... supported-compression-methods";
}

Dale


From nobody Tue Aug 30 15:17:28 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 BA1C112D820 for ; Tue, 30 Aug 2016 15:17:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.901
X-Spam-Level: 
X-Spam-Status: No, score=-6.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H2=-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 aFBEzjPbucMb for ; Tue, 30 Aug 2016 15:17:23 -0700 (PDT)
Received: from smtp-us.alcatel-lucent.com (us-hpatc-esg-01.alcatel-lucent.com [135.245.18.27]) (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 D07EA12D51A for ; Tue, 30 Aug 2016 15:17:23 -0700 (PDT)
Received: from us70tumx1.dmz.alcatel-lucent.com (unknown [135.245.18.13]) by Websense Email Security Gateway with ESMTPS id 3FF69D7558604 for ; Tue, 30 Aug 2016 22:17:19 +0000 (GMT)
Received: from us70tusmtp1.zam.alcatel-lucent.com (us70tusmtp1.zam.alcatel-lucent.com [135.5.2.63]) by us70tumx1.dmz.alcatel-lucent.com (GMO) with ESMTP id u7UMHMSH021785 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 30 Aug 2016 22:17:22 GMT
Received: from US70UWXCHHUB02.zam.alcatel-lucent.com (us70uwxchhub02.zam.alcatel-lucent.com [135.5.2.49]) by us70tusmtp1.zam.alcatel-lucent.com (GMO) with ESMTP id u7UMHMKC011625 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Tue, 30 Aug 2016 22:17:22 GMT
Received: from US70TWXCHMBA11.zam.alcatel-lucent.com ([169.254.5.103]) by US70UWXCHHUB02.zam.alcatel-lucent.com ([135.5.2.49]) with mapi id 14.03.0195.001; Tue, 30 Aug 2016 18:17:10 -0400
From: "Sterne, Jason (Nokia - CA)" 
To: "netmod@ietf.org" 
Thread-Topic: Using an empty type in a list key
Thread-Index: AdIDDD+zdnreDFObQSq39pPc7YROeg==
Date: Tue, 30 Aug 2016 22:17:10 +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.17]
Content-Type: multipart/alternative; boundary="_000_A125E53CE190A749957C19483DC79F9F5CD0F6EAUS70TWXCHMBA11z_"
MIME-Version: 1.0
Archived-At: 
Subject: [netmod] Using an empty type in a list key
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 30 Aug 2016 22:17:26 -0000

--_000_A125E53CE190A749957C19483DC79F9F5CD0F6EAUS70TWXCHMBA11z_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi all,

I saw the addition of empty types in list keys in YANG 1.1 but had troubles=
 finding more details in the NETMOD list.  Is it discussed in the YANG 1.1 =
issues page (and if so, where is that now ?  I tried an old link and it did=
n't work) ?

If I take this example where I have a set of a apartments 1,2,3 but there m=
ay also be occasional 'bis' apartments (e.g. 7bis).

list apartment {
    key "number bis";
    leaf number {
        type int16;
    }
    leaf bis {
        type empty;
    }
    leaf description {
         type string;
    }
}

Can I create list entries like this ?


    5
    apartment 5


    8
    
    apartment 8bis


    8
    apartment 8


Doesn't the empty type have two states and the absence/presence of the leaf=
/tag indicates those states ?

I realize that a Boolean type could be used for bis but the use case (a que=
stion of preference/style) is that 'bis' is unusual and so it becomes noisy=
 to have to set false all the time when creating apartment entri=
es.  It may be useful to only have to specify  in the rare cases that=
 it is needed.

Regards,
Jason


--_000_A125E53CE190A749957C19483DC79F9F5CD0F6EAUS70TWXCHMBA11z_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi all,


 


I saw the addition of empty types in list keys in YANG 1.1 but had tro=
ubles finding more details in the NETMOD list.  Is it discussed in the=
 YANG 1.1 issues page (and if so, where is that now ?  I tried an old =
link and it didn’t work) ?


 


If I take this example where I have a set of a apartments 1,2,3 but th=
ere may also be occasional ‘bis’ apartments (e.g. 7bis).


 


list apartment {


    key “number bis”;


    leaf number {


        type int16;


    }


    leaf bis {


        type empty;


    }


    leaf description {


         type string;


    }


}


 


Can I create list entries like this ?


 


<apartment>


    <number>5</number>


    <description>apartment 5</description><=
/div>

<apartment>


<apartment>


    <number>8</number>


    <bis/>


    <description>apartment 8bis</description&g=
t;


<apartment>


<apartment>


    <number>8</number>


    <description>apartment 8</description><=
/div>

<apartment>


 


Doesn’t the empty type have two states and the absence/presence =
of the leaf/tag indicates those states ?


 


I realize that a Boolean type could be used for bis but the use case (=
a question of preference/style) is that ‘bis’ is unusual and so=
 it becomes noisy to have to set <bis>false</bis> all the time =
when creating apartment entries.  It may be useful to only
have to specify <bis/> in the rare cases that it is needed.


 


Regards,


Jason


 





--_000_A125E53CE190A749957C19483DC79F9F5CD0F6EAUS70TWXCHMBA11z_--


From nobody Wed Aug 31 00:35: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 D284312D0DA for ; Wed, 31 Aug 2016 00:35:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 Eda3avOniYmG for ; Wed, 31 Aug 2016 00:35:07 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19E4912D11B for ; Wed, 31 Aug 2016 00:35:06 -0700 (PDT)
X-AuditID: c1b4fb25-ca31e98000001071-f7-57c688a9ab65
Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by  (Symantec Mail Security) with SMTP id 2B.67.04209.9A886C75; Wed, 31 Aug 2016 09:35:05 +0200 (CEST)
Received: from [159.107.197.179] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.35) with Microsoft SMTP Server id 14.3.301.0; Wed, 31 Aug 2016 09:35:01 +0200
To: Jan Lindblad 
References:  <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com>
From: Balazs Lengyel 
Message-ID: <79de91b0-7084-401c-6967-23519b511c4a@ericsson.com>
Date: Wed, 31 Aug 2016 09:35:01 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrALMWRmVeSWpSXmKPExsUyM2K7ou7KjmPhBh++yVn8n9XHaDH/YiOr A5PHkiU/mTw2/lrMEsAUxWWTkpqTWZZapG+XwJVx7NA5loInAhU3375hb2A8wNvFyMkhIWAi MfHjEcYuRi4OIYH1jBInPzSxQzhrGSWuTNrCCFIlLBAhsfLxDnYQW0RASeJEaztrFyMHUFGx xIcD9SBhZgF1iTunHrOB2GwCRhJT+8+zgNi8AvYSm769BitnEVCVWP0pHsQUFYiRWN+XAFEh KHFy5hOwak4BO4lV91+wg5QwA3U+2FoGMVxeYvvbOcwgtpCAhsTDC39ZJzAKzELSPQuhYxaS jgWMzKsYRYtTi5Ny042M9VKLMpOLi/Pz9PJSSzYxAsPx4JbfqjsYL79xPMQowMGoxMO74OTR cCHWxLLiytxDjBIczEoivLH1x8KFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnN Tk0tSC2CyTJxcEo1MNoqrn/56FWwIvfHPRyr7uTN+3su7niz57PzyxZfvMNqYXQxatUuKZO2 cOtzB6USdy4z67tku61yxSkvqRi3G+xXX8Z9q+qQEvvP7faDwfZBwuSfm7nOX5AR0PL6MaVx 8qFvYkttz0kZn7vX6WFpqMcZFtgnetnWIelu6Q8bVpusKZWhS+USFyuxFGckGmoxFxUnAgBy T5ecQwIAAA==
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 07:35:09 -0000

Hello Jan,

This may be the best solution we have, but nacm rules may be changed, 
and then device limits might be edited by the operator, and then we have 
a problem.

The good solution would be to indicate that this is read-only static 
data, and allow must, leafref towards it. However I don't see a way to 
do this in YANG at the moment short of an ericsson-extension.

regards Balazs


On 2016-08-30 15:14, Jan Lindblad wrote:
> Balazs,
>
>> We have the following design pattern.
>>
>> 1) An enumeration or a set of identities are defined that define a set of options generally supported by Ericsson products.  (e.g. supported compression algorithms)
>> 2) The specific node sets in run-time a leaf-list indicating the set of values that this specific node supports (e.g. nodes-supported-compression-types: zip, gzip, bz)
>> 3) For some function the user has to select a specific option value (e.g. leaf file-compression for transferring backup files)
>>
>> Problem: how do you restrict values for (3) - file-compression so that it is one of the nodes-supported-compression-types. The natural solution would be to use a must expression or a leaf-ref, but as nodes-supported-compression-types is config-false data, it is not allowed to constrain the config=true leaf, file-compression, with it.
>>
>> It would be perfectly reasonable because the nodes-supported-compression-types only change during upgrade, but YANG does not allow this.
>>
>> I would still like to have some modeled solution, not just plain English stating the constraint. Any idea how to do it?
> I have seen this use case many times. I usually solve this by making a container with device specific limits, lists of supported values, etc, which is config true but with nacm rules preventing everyone from making changes. Then I have a device specific database initialization file with the correct settings for this device, which is loaded into the database at first boot.
>
> /jan
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Wed Aug 31 01:02: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 1E70712D0AC for ; Wed, 31 Aug 2016 01:02:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.497
X-Spam-Level: 
X-Spam-Status: No, score=-3.497 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.723, RCVD_IN_DNSWL_MED=-2.3, 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 oNnkbTk5cTfC for ; Wed, 31 Aug 2016 01:02:09 -0700 (PDT)
Received: from sessmg22.ericsson.net (sessmg22.ericsson.net [193.180.251.58]) (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 9EDA912D13A for ; Wed, 31 Aug 2016 01:02:09 -0700 (PDT)
X-AuditID: c1b4fb3a-c7bff700000009bd-88-57c68efd1831
Received: from ESESSHC003.ericsson.se (Unknown_Domain [153.88.183.27]) by  (Symantec Mail Security) with SMTP id 33.7E.02493.DFE86C75; Wed, 31 Aug 2016 10:02:07 +0200 (CEST)
Received: from [159.107.197.179] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.29) with Microsoft SMTP Server id 14.3.301.0; Wed, 31 Aug 2016 10:02:05 +0200
To: "Bogaert, Bart (Nokia - BE)" , "netmod@ietf.org" 
References: 
From: Balazs Lengyel 
Message-ID: 
Date: Wed, 31 Aug 2016 10:02:05 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/html; charset="windows-1252"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrGLMWRmVeSWpSXmKPExsUyM2K7tO7/vmPhBtd/GVps/vCSyWL+xUZW ByaPJUt+MnncvXWJKYApissmJTUnsyy1SN8ugStj7crNLAVbPCo+TrnC1sC427KLkYNDQsBE 4vnm/C5GLg4hgfWMEm8W9rBDOGsZJZrfLGDpYuTkEBZwllg3aSsbiC0ikCDxs/sFE4gtJBAn 8XXnUkYQm03ASGJq/3mwel4Be4nHnRfZQWwWAVWJE/8eMoEsExWIkVjflwBRIihxcuYTFpAw p0C8xOPFYiBhZgF9iet37rNC2PISzVtnM0Ns0pB4eOEv6wRG/llIumchaZmFpGUBI/MqRtHi 1OLi3HQjI73Uoszk4uL8PL281JJNjMDQO7jlt9UOxoPPHQ8xCnAwKvHwLjh5NFyINbGsuDL3 EKMEB7OSCK8RMHCFeFMSK6tSi/Lji0pzUosPMUpzsCiJ8/q/VAwXEkhPLEnNTk0tSC2CyTJx cEo1MK7Rmv79+OlJ0ow7Z+8556DEr8+x2UtqVc28/qWz/c27bFNzO29+4X93eMHC/wkam5t/ busLlty+zGnTi72ugl2VS+te331gsK8w9qVj80u1h7oP536t6FvV+ae+qOrmv3m/w89ZLQq7 mde5PXriT/NcU8U5bw/+WN+w88aHI1lOPXOzip9fWVWnxFKckWioxVxUnAgA0IJqujkCAAA=
Archived-At: 
Subject: Re: [netmod] derived-from-or-self leads to circular import
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 08:02:14 -0000


  
    
  
  
    
Hello Bart,

    
A nice solution could be to separate ietf-entity into 2 yang
      modules (YAMs). One handling only generic entity stuff and another
      handling sensor related stuff. If ietf-entity does not include
      any entity-type specific stuff it does not need to import
      iana-entity any more. This is how it works with ietf-interfaces
      and iana-if-type. Ietf-interfaces does not include anything that
      is if-type specific. Problem solved.

    
regards Balazs

    

    

    
On 2016-07-29 14:50, Bogaert, Bart
      (Nokia - BE) wrote:

    

    

      
      
      
      

        
Hi,

        

        
The IETF draft entity model has added the
          following:

        

            container sensor-data {

        

            when 'derived-from-or-self(../class,

        

            "iana-entity", "sensor")' {

        

        
We already know that derived-from-or-self
          actually only has 2 parameters so it is expected to become

        

        
 container sensor-data {

        
 when 'derived-from-or-self(../class,

        
 "iana-entity:sensor")' {

        

        
In order to correctly compile (using
          confdc) we also need to import iana-entity for the identities
          defined in there. However this is leading a circular
          dependency:

        
1. Iana-entity
          imports ietf-entity (to resolve entity-physical-class)

        
2. Ietf-entity
          imports iana-entity (to obtain the indentities defined in
          there)

        

        
One way to solve this is to move the
          definition of entity-physical-class from ietf-entity to
          iana-entity which would resolve the fact that iana-entity
          requires an import of ietf-entity (ietf-entity needs to import
          iana-entity anyhow, so it can also pick the typedef from the
          same module too).

        

        
Whatever solution is chosen, the circular
          import needs to be resolved (or circular imports should be
          allowed  after all: what has been imported can be tracked
          removing the need to re-import something that was already
          imported).

        

        
Best regards - Vriendelijke groeten,

        
Bart Bogaert

        
Broadband-Access
            System Architect Data

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

        

        
NOKIA

        
Copernicuslaan 50, 2018 Antwerp, Belgium

          Fortis 220-0002334-42

          VAT BE 0404 621 642 Register of Legal Entities Antwerp

          

          

        
<<

            This message (including any attachments) contains
            confidential information intended for a specific individual
            and purpose, and is protected by law. If you are not the
            intended recipient, you should delete this message. Any
            disclosure, copying, or distribution of this message, or the
            taking of any action based on it, is strictly prohibited
            without the prior consent of its author.

            >> 

        

      

      

      

      

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


    

    

    
-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com 


  



From nobody Wed Aug 31 01:54: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 1C90D12DA50 for ; Wed, 31 Aug 2016 01:54:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.449
X-Spam-Level: 
X-Spam-Status: No, score=-2.449 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RP_MATCHES_RCVD=-0.548, 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 0Kq64_Q7NAcm for ; Wed, 31 Aug 2016 01:54:02 -0700 (PDT)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 6C3A412DA4B for ; Wed, 31 Aug 2016 01:54:01 -0700 (PDT)
Received: from localhost (h-85-226.a165.priv.bahnhof.se [94.254.85.226]) by mail.tail-f.com (Postfix) with ESMTPSA id 3B7111AE035B; Wed, 31 Aug 2016 10:54:00 +0200 (CEST)
Date: Wed, 31 Aug 2016 10:54:00 +0200 (CEST)
Message-Id: <20160831.105400.1504024157055343657.mbj@tail-f.com>
To: balazs.lengyel@ericsson.com
From: Martin Bjorklund 
In-Reply-To: <79de91b0-7084-401c-6967-23519b511c4a@ericsson.com>
References:  <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com> <79de91b0-7084-401c-6967-23519b511c4a@ericsson.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] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 08:54:04 -0000

Balazs Lengyel  wrote:
> Hello Jan,
> 
> This may be the best solution we have, but nacm rules may be changed,
> and then device limits might be edited by the operator, and then we
> have a problem.
> 
> The good solution would be to indicate that this is read-only static
> data, and allow must, leafref towards it. However I don't see a way to
> do this in YANG at the moment short of an ericsson-extension.

I think this is the only correct solution available today.  I.e.,
describe the behavior in description text, and/or add an extension
that makes this formal and machnie readable for your tools:

  leaf-list supported-compression-algorithm {
    config false;
    type eri:compression-algorithm;
    description
      "Lists the compression algorithms supported by this device.";
  }

  leaf compression-algorithm {
    config true;
    type eri:compression-algorithm;
    description
      "Must be one of the values listed in
       supported-compression-algorithm.";
    eri:restrict-to "../supported-compression-algorithm";
  }

But I assume that the list of supported-compression-algorithm can
change with a software upgrade, and if so, how do you handle the case
that the config contains a value that is removed in a software
upgrade?


/martin


> 
> regards Balazs
> 
> 
> On 2016-08-30 15:14, Jan Lindblad wrote:
> > Balazs,
> >
> >> We have the following design pattern.
> >>
> >> 1) An enumeration or a set of identities are defined that define a set
> >> of options generally supported by Ericsson products.  (e.g. supported
> >> compression algorithms)
> >> 2) The specific node sets in run-time a leaf-list indicating the set
> >> of values that this specific node supports
> >> (e.g. nodes-supported-compression-types: zip, gzip, bz)
> >> 3) For some function the user has to select a specific option value
> >> (e.g. leaf file-compression for transferring backup files)
> >>
> >> Problem: how do you restrict values for (3) - file-compression so that
> >> it is one of the nodes-supported-compression-types. The natural
> >> solution would be to use a must expression or a leaf-ref, but as
> >> nodes-supported-compression-types is config-false data, it is not
> >> allowed to constrain the config=true leaf, file-compression, with it.
> >>
> >> It would be perfectly reasonable because the
> >> nodes-supported-compression-types only change during upgrade, but YANG
> >> does not allow this.
> >>
> >> I would still like to have some modeled solution, not just plain
> >> English stating the constraint. Any idea how to do it?
> > I have seen this use case many times. I usually solve this by making a
> > container with device specific limits, lists of supported values, etc,
> > which is config true but with nacm rules preventing everyone from
> > making changes. Then I have a device specific database initialization
> > file with the correct settings for this device, which is loaded into
> > the database at first boot.
> >
> > /jan
> >
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909 email: Balazs.Lengyel@ericsson.com
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Wed Aug 31 02:10: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 BC6C012D883 for ; Wed, 31 Aug 2016 02:10:42 -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 iqmE2AaEB8ap for ; Wed, 31 Aug 2016 02:10:41 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C19C112D8AD for ; Wed, 31 Aug 2016 02:10:39 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id DBA5B1520012; Wed, 31 Aug 2016 11:10:37 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id l3pWXfc9IYoZ; Wed, 31 Aug 2016 11:10:37 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id B48991520011; Wed, 31 Aug 2016 11:10:37 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id p6zP4gfwUkaW; Wed, 31 Aug 2016 11:10:37 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 94832152000E; Wed, 31 Aug 2016 11:10:37 +0200 (CEST)
Message-ID: <57C69F18.7000006@transpacket.com>
Date: Wed, 31 Aug 2016 11:10:48 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Balazs Lengyel , netmod@ietf.org
References:  <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com> <79de91b0-7084-401c-6967-23519b511c4a@ericsson.com>
In-Reply-To: <79de91b0-7084-401c-6967-23519b511c4a@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 09:10:42 -0000

If you design your models using identityref and define the identities in 
separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. 
you can just chose not to load the particular YANG models containing the 
identities not supported when your device starts.

If you absolutely can not define your identities in separate YANG files 
(better modularity is indeed the edge YANG has over other modeling 
languages and it should be used) you can use feature with some 
limitations e.g. instead of leaf of type enumeration you will have a 
choice with each case containing if-feature and presence container for 
example.

If you can not change the model to be modular and your implementation 
does not support it 100% then you are not supporting the model and you 
are free to be creative with the workaround but then YANG is not the 
problem.

I also see alternative discussion value in the subject line. Lets say 
one would like to specify in a standard way a list of values supported 
by a device as valid /interface/interface/name values e.g. ("ge0", 
"ge1", .... "xe0", "xe1", "me0"). This can be useful in many ways e.g. 
tab completion. Also the supported types for each of the interface names 
and so on further reducing the entropy. Does anyone else see value in that?

On 08/31/2016 09:35 AM, Balazs Lengyel wrote:
> Hello Jan,
>
> This may be the best solution we have, but nacm rules may be changed, 
> and then device limits might be edited by the operator, and then we 
> have a problem.
>
> The good solution would be to indicate that this is read-only static 
> data, and allow must, leafref towards it. However I don't see a way to 
> do this in YANG at the moment short of an ericsson-extension.
>
> regards Balazs
>
>
> On 2016-08-30 15:14, Jan Lindblad wrote:
>> Balazs,
>>
>>> We have the following design pattern.
>>>
>>> 1) An enumeration or a set of identities are defined that define a 
>>> set of options generally supported by Ericsson products.  (e.g. 
>>> supported compression algorithms)
>>> 2) The specific node sets in run-time a leaf-list indicating the set 
>>> of values that this specific node supports (e.g. 
>>> nodes-supported-compression-types: zip, gzip, bz)
>>> 3) For some function the user has to select a specific option value 
>>> (e.g. leaf file-compression for transferring backup files)
>>>
>>> Problem: how do you restrict values for (3) - file-compression so 
>>> that it is one of the nodes-supported-compression-types. The natural 
>>> solution would be to use a must expression or a leaf-ref, but as 
>>> nodes-supported-compression-types is config-false data, it is not 
>>> allowed to constrain the config=true leaf, file-compression, with it.
>>>
>>> It would be perfectly reasonable because the 
>>> nodes-supported-compression-types only change during upgrade, but 
>>> YANG does not allow this.
>>>
>>> I would still like to have some modeled solution, not just plain 
>>> English stating the constraint. Any idea how to do it?
>> I have seen this use case many times. I usually solve this by making 
>> a container with device specific limits, lists of supported values, 
>> etc, which is config true but with nacm rules preventing everyone 
>> from making changes. Then I have a device specific database 
>> initialization file with the correct settings for this device, which 
>> is loaded into the database at first boot.
>>
>> /jan
>>
>
Vladimir


From nobody Wed Aug 31 03:38: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 A1E3E12D17A for ; Wed, 31 Aug 2016 03:38:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 R3LU93_UYnKq for ; Wed, 31 Aug 2016 03:38:04 -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 C6E7E12D192 for ; Wed, 31 Aug 2016 03:38:03 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:8061:38d1:960b:57f6] (unknown [IPv6:2001:718:1a02:1:8061:38d1:960b:57f6]) by mail.nic.cz (Postfix) with ESMTPSA id 568B361E74; Wed, 31 Aug 2016 12:38:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1472639882; bh=Zam2so2Ch0+l/bKzb/iOcIOpVD28fqEejrWULZP2u4U=; h=From:Date:To; b=rTtBLOKSLk/d0wAeW3kxicdbd//iDGIEDbprTb3RPBKmPcjyvhWXK9LxFEwAxkaZ/ LYuDD9Lshnn0JRxxiIYx2xacOF295EQSxagjcr+WSrjo3PTDM0osdCGjnnU6OKkdoK uC61cN+hSw2NdQJK/I4kwX2H3ayeWMum0ssFvjBQ=
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: <57C69F18.7000006@transpacket.com>
Date: Wed, 31 Aug 2016 12:38:05 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References:  <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com> <79de91b0-7084-401c-6967-23519b511c4a@ericsson.com> <57C69F18.7000006@transpacket.com>
To: Vladimir Vassilev 
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] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 10:38:06 -0000

> On 31 Aug 2016, at 11:10, Vladimir Vassilev  =
wrote:
>=20
> If you design your models using identityref and define the identities =
in separate modules e.g. compression-zip.yang, compression-gzip.yang, =
etc. you can just chose not to load the particular YANG models =
containing the identities not supported when your device starts.

Right, and I have proposed this approach several times in the past. =
However, some people prefer that the modules defining identities mirror =
IANA and similar registries. In the case of iana-interface-types it also =
means that implementations have to deal with obsolete, obscure and =
experimental interface types that happen to be in the IANA registry but =
nobody will ever want to use.

Lada

>=20
> If you absolutely can not define your identities in separate YANG =
files (better modularity is indeed the edge YANG has over other modeling =
languages and it should be used) you can use feature with some =
limitations e.g. instead of leaf of type enumeration you will have a =
choice with each case containing if-feature and presence container for =
example.
>=20
> If you can not change the model to be modular and your implementation =
does not support it 100% then you are not supporting the model and you =
are free to be creative with the workaround but then YANG is not the =
problem.
>=20
> I also see alternative discussion value in the subject line. Lets say =
one would like to specify in a standard way a list of values supported =
by a device as valid /interface/interface/name values e.g. ("ge0", =
"ge1", .... "xe0", "xe1", "me0"). This can be useful in many ways e.g. =
tab completion. Also the supported types for each of the interface names =
and so on further reducing the entropy. Does anyone else see value in =
that?
>=20
> On 08/31/2016 09:35 AM, Balazs Lengyel wrote:
>> Hello Jan,
>>=20
>> This may be the best solution we have, but nacm rules may be changed, =
and then device limits might be edited by the operator, and then we have =
a problem.
>>=20
>> The good solution would be to indicate that this is read-only static =
data, and allow must, leafref towards it. However I don't see a way to =
do this in YANG at the moment short of an ericsson-extension.
>>=20
>> regards Balazs
>>=20
>>=20
>> On 2016-08-30 15:14, Jan Lindblad wrote:
>>> Balazs,
>>>=20
>>>> We have the following design pattern.
>>>>=20
>>>> 1) An enumeration or a set of identities are defined that define a =
set of options generally supported by Ericsson products.  (e.g. =
supported compression algorithms)
>>>> 2) The specific node sets in run-time a leaf-list indicating the =
set of values that this specific node supports (e.g. =
nodes-supported-compression-types: zip, gzip, bz)
>>>> 3) For some function the user has to select a specific option value =
(e.g. leaf file-compression for transferring backup files)
>>>>=20
>>>> Problem: how do you restrict values for (3) - file-compression so =
that it is one of the nodes-supported-compression-types. The natural =
solution would be to use a must expression or a leaf-ref, but as =
nodes-supported-compression-types is config-false data, it is not =
allowed to constrain the config=3Dtrue leaf, file-compression, with it.
>>>>=20
>>>> It would be perfectly reasonable because the =
nodes-supported-compression-types only change during upgrade, but YANG =
does not allow this.
>>>>=20
>>>> I would still like to have some modeled solution, not just plain =
English stating the constraint. Any idea how to do it?
>>> I have seen this use case many times. I usually solve this by making =
a container with device specific limits, lists of supported values, etc, =
which is config true but with nacm rules preventing everyone from making =
changes. Then I have a device specific database initialization file with =
the correct settings for this device, which is loaded into the database =
at first boot.
>>>=20
>>> /jan
>>>=20
>>=20
> Vladimir
>=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 Aug 31 03:55: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 1833D12DAC3 for ; Wed, 31 Aug 2016 03:55:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.789
X-Spam-Level: 
X-Spam-Status: No, score=-1.789 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, T_DKIM_INVALID=0.01] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=hansfords.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 Pd614OgZCHZ4 for ; Wed, 31 Aug 2016 03:55:38 -0700 (PDT)
Received: from server.myfast.site (server.myfast.site [212.113.130.90]) (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 6882612D16F for ; Wed, 31 Aug 2016 03:55:38 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=hansfords.net; s=default; h=Content-Type:References:In-Reply-To:Date: Subject:From:Cc:To:MIME-Version:Sender:Reply-To:Message-ID: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=WYgLfEdT6sHwypuZu1D45cP1BZPkYMmvVRmRC/2+ayE=; b=H/EuIvrq9Y4Yz2hxnknfgJsjq jCpdPfNugx7zlNmKohz0NvEspDSGrQtMM8NsCLgZczOxchzqimQJQq9XBIELTV1nXT1iVCTw5PuQc yo8vBC72MVq4zGsuw6L7u2DzqdQtVqxkaF0MfkJ/2NgjwT8qOOMWk7j5699Of4lD2E9L88iZ7xkQy Og4ePWYRf/p/574WIYsRfRccMv2SLnwOGL6nowRNzJQmc16CHFT1g+XQprdM9G+koA4HFD6bb5mY5 YLplL+jrD8ulsEJ/fGdI7rElkGYTIUGyNGxbKTK38sDLhSiTTYKdrjrMkADctPRID8vN3XVcGxZG7 so2dmGQ+Q==;
Received: from host-212-159-131-152.static.as13285.net ([212.159.131.152]:58340 helo=[IPv6:::ffff:192.168.1.180]) by server.myfast.site with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.87) (envelope-from ) id 1bf3B4-003qYl-F6; Wed, 31 Aug 2016 11:55:34 +0100
MIME-Version: 1.0
To: William Lupton ,  Andy Bierman 
From: Jonathan Hansford 
Date: Wed, 31 Aug 2016 11:56:18 +0100
Importance: normal
X-Priority: 3
In-Reply-To: 
References:  <87pop4x2vu.fsf@hobgoblin.ariadne.com>  
Content-Type: multipart/alternative; boundary="_3761695E-7423-4CD1-AA87-2AB55F76606C_"
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - server.myfast.site
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - hansfords.net
X-Get-Message-Sender-Via: server.myfast.site: authenticated_id: jonathan@hansfords.net
X-Authenticated-Sender: server.myfast.site: jonathan@hansfords.net
Message-Id: <20160831105538.6882612D16F@ietfa.amsl.com>
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements indrafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 10:55:41 -0000

--_3761695E-7423-4CD1-AA87-2AB55F76606C_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain; charset="utf-8"

How about:

NEW:

It is not required to keep the full revision history of draft versions (e.g=
., modules contained within Internet-Drafts). That is, within a sequence of=
 draft versions, only the most recent revision need be recorded in the modu=
le. However, whenever a new (i.e. changed) version is made available (e.g.,=
 via a new version of an Internet-Draft), the revision date of that new ver=
sion MUST be updated to a date later than that of the previous version.

Jonathan

From: William Lupton=

--_3761695E-7423-4CD1-AA87-2AB55F76606C_
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html; charset="utf-8"


How about:
<=
o:p> 
NEW:
=
 
It is not required to keep the full re=
vision history of draft versions (e.g., modules contained within Internet-D=
rafts). That is, within a sequence of draft versions, only the most recent =
revision need be recorded in the module. However, whenever a new (i.e. chan=
ged) version is made available (e.g., via a new version of an Internet-Draf=
t), the revision date of that new version MUST be updated to a date later t=
han that of the previous version.
&=
nbsp;
Jonathan
 <=
/o:p>
From: William Lupton
Sent: 29 August 2016 15:20To: Andy Bierman
C=
c: netmod@ietf.org
Subject=
: Re: [netmod] RFC 6087bis guidance re use of revision statements indra=
fts
 
Andy=
, 
This thread started with discussion of an apparent ambigu=
ity in the current text:
&nbs=
p;
OLD
=

 
=
It is =
acceptable to reuse the same revision statement within unpublished versions=
 (i.e., Internet-Drafts), but the revision date MUST be updated to a higher=
 value each time the Internet-Draft is re-posted.
 
=E2=80=94=E2=80=94 
 
It became clear from the=
 subsequent discussion (thanks Randy!) that the above text isn=E2=80=99t in=
tended to mean =E2=80=9Creuse the identical revision statement, INCLUDING T=
HE REVISION DATE=E2=80=9D but to mean =E2=80=9Creuse the revision statement=
, UPDATING THE REVISION DATE=E2=80=9D.
 
Then other=
 people raised other points, e.g only updating the revision date if the YAN=
G has changed, distinguishing between the document and the YANG contained t=
herein, and distinguishing between YANG in IDs and YANG created by other SD=
Os. My proposed new text tries to address all of these:
 
NEW:

It is not required to keep the full revision history of =
draft versions (e.g., modules contained within Internet-Drafts). That is, w=
ithin a sequence of draft versions, only the most recent revision need be&n=
bsp;recorded in the module. However, if the module has changed, the revisio=
n date of the most recent revision MUST be updated to a later date whenever=
 a new version is made available (e.g., via a new version of an Intern=
et-Draft).
 =

=E2=80=94=E2=80=94
 
I believe that this retains the original intent in a way that resolv=
es the original ambiguity and addresses the other points that were raised. =
It it=E2=80=99s =E2=80=9Cworse=E2=80=9D, how is it worse (apart from being =
longer, on which point mea culpa)?
 
Thanks,
William
 
On 19 Aug 2016, a=
t 15:42, Andy Bierman <andy@yumawo=
rks.com> wrote:
=
 
On Fri, Aug 19, 2016 a=
t 7:13 AM, Dale R. Worley <worley@ariadne.com> wrote:
Andy Bierman <=
;andy@yumaworks.com> writes:> An Internet-Draft is NOT a means of "publishing" a specifi=
cation;

As I said, that's the theory, but practice is considerably d=
ifferent.
 =

Anybody that implements a work-i=
n-progress knows they are taking a risk
on an unstable document.  The guideline already says MUST =
update
the revision date.
 
Not sure what more you want to guidelines document =
to do.
 
Dale
 
<=
/div>
Andy
 =

=

--_3761695E-7423-4CD1-AA87-2AB55F76606C_--


From nobody Wed Aug 31 04:10: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 0ED2F12DAD8 for ; Wed, 31 Aug 2016 04:10:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 CjCUBwRmW53d for ; Wed, 31 Aug 2016 04:10:28 -0700 (PDT)
Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (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 925EF12DAD2 for ; Wed, 31 Aug 2016 04:10:21 -0700 (PDT)
X-AuditID: c1b4fb2d-917ff700000019a3-74-57c6bb197c51
Received: from ESESSHC018.ericsson.se (Unknown_Domain [153.88.183.72]) by  (Symantec Mail Security) with SMTP id E6.1A.06563.91BB6C75; Wed, 31 Aug 2016 13:10:19 +0200 (CEST)
Received: from [159.107.197.179] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.74) with Microsoft SMTP Server id 14.3.301.0; Wed, 31 Aug 2016 13:10:17 +0200
To: Ladislav Lhotka , Vladimir Vassilev 
References:  <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com> <79de91b0-7084-401c-6967-23519b511c4a@ericsson.com> <57C69F18.7000006@transpacket.com> 
From: Balazs Lengyel 
Message-ID: 
Date: Wed, 31 Aug 2016 13:10:17 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrDLMWRmVeSWpSXmKPExsUyM2K7h6707mPhBhtXaVlcWDWXzWL+xUZW i1Pzv7E6MHssWfKTyWPT5TuMHlc/nGQJYI7isklJzcksSy3St0vgyrg1fTprwSO1ig+zp7M0 MB6V72Lk5JAQMJHYfPgNaxcjF4eQwHpGiQMT37FDOGsZJVqeHGQFqRIWiJBY+XgHO4gtIhAs sbXjNxtE0T9GiUlTu1hAEswCohLrL15iArHZBIwkpvafB4vzCthL9HUuBmrm4GARUJU4eFEf xBQViJFY35cAUSEocXLmE7BqTgEriTtXTjGDlDADdT7YWgYxXF5i+9s5zCC2kICGxMMLf1kn MArMQtI9C6FjFpKOBYzMqxhFi1OLi3PTjYz1Uosyk4uL8/P08lJLNjECw/Tglt+6OxhXv3Y8 xCjAwajEw7vg5NFwIdbEsuLK3EOMEhzMSiK8N3ccCxfiTUmsrEotyo8vKs1JLT7EKM3BoiTO 6/9SMVxIID2xJDU7NbUgtQgmy8TBKdXAWGxqbntwfYS35ddz2gK+zgIrS1cbRAX+2ODZL9dv 3cDcoafocv6FomvAzaXCr09883gy/UEkV+0znwmpZzfc/MX0NdEjS4id8ZzsF7mOuUuyn5rb THhaFLV4zQa3ycUiZy4Iqi0tf9F0Sfn8TectVW+rlP8G5/GX16zWCEvisM9Y2muWzFylxFKc kWioxVxUnAgAhB9spk8CAAA=
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 11:10:32 -0000

Hello,

The problem is not just about identities. It can be a value range. 
Sometimes we have a generic module like iana-interface type that list a 
lot of identities, and I don't want to have one YAM file per identity, 
to allow a fine control. Also sadly it is not possible to have a 
deviation removing identities. IMHO would be needed.

I would be more interested in having an extension saying static-data. 
This would state that that part of config is set by the system, and can 
not be modified by the user. So I could have conditions based on it, but 
the user might not modify it.

regards Balazs


On 2016-08-31 12:38, Ladislav Lhotka wrote:
>> On 31 Aug 2016, at 11:10, Vladimir Vassilev  wrote:
>>
>> If you design your models using identityref and define the identities in separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. you can just chose not to load the particular YANG models containing the identities not supported when your device starts.
> Right, and I have proposed this approach several times in the past. However, some people prefer that the modules defining identities mirror IANA and similar registries. In the case of iana-interface-types it also means that implementations have to deal with obsolete, obscure and experimental interface types that happen to be in the IANA registry but nobody will ever want to use.
>
> Lada
>
>> If you absolutely can not define your identities in separate YANG files (better modularity is indeed the edge YANG has over other modeling languages and it should be used) you can use feature with some limitations e.g. instead of leaf of type enumeration you will have a choice with each case containing if-feature and presence container for example.
>>
>> If you can not change the model to be modular and your implementation does not support it 100% then you are not supporting the model and you are free to be creative with the workaround but then YANG is not the problem.
>>
>> I also see alternative discussion value in the subject line. Lets say one would like to specify in a standard way a list of values supported by a device as valid /interface/interface/name values e.g. ("ge0", "ge1", .... "xe0", "xe1", "me0"). This can be useful in many ways e.g. tab completion. Also the supported types for each of the interface names and so on further reducing the entropy. Does anyone else see value in that?
>>
>> On 08/31/2016 09:35 AM, Balazs Lengyel wrote:
>>> Hello Jan,
>>>
>>> This may be the best solution we have, but nacm rules may be changed, and then device limits might be edited by the operator, and then we have a problem.
>>>
>>> The good solution would be to indicate that this is read-only static data, and allow must, leafref towards it. However I don't see a way to do this in YANG at the moment short of an ericsson-extension.
>>>
>>> regards Balazs
>>>
>>>
>>> On 2016-08-30 15:14, Jan Lindblad wrote:
>>>> Balazs,
>>>>
>>>>> We have the following design pattern.
>>>>>
>>>>> 1) An enumeration or a set of identities are defined that define a set of options generally supported by Ericsson products.  (e.g. supported compression algorithms)
>>>>> 2) The specific node sets in run-time a leaf-list indicating the set of values that this specific node supports (e.g. nodes-supported-compression-types: zip, gzip, bz)
>>>>> 3) For some function the user has to select a specific option value (e.g. leaf file-compression for transferring backup files)
>>>>>
>>>>> Problem: how do you restrict values for (3) - file-compression so that it is one of the nodes-supported-compression-types. The natural solution would be to use a must expression or a leaf-ref, but as nodes-supported-compression-types is config-false data, it is not allowed to constrain the config=true leaf, file-compression, with it.
>>>>>
>>>>> It would be perfectly reasonable because the nodes-supported-compression-types only change during upgrade, but YANG does not allow this.
>>>>>
>>>>> I would still like to have some modeled solution, not just plain English stating the constraint. Any idea how to do it?
>>>> I have seen this use case many times. I usually solve this by making a container with device specific limits, lists of supported values, etc, which is config true but with nacm rules preventing everyone from making changes. Then I have a device specific database initialization file with the correct settings for this device, which is loaded into the database at first boot.
>>>>
>>>> /jan
>>>>
>> Vladimir
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> --
> Ladislav Lhotka, CZ.NIC Labs
> PGP Key ID: E74E8C0C
>
>
>
>
>

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Wed Aug 31 04:14: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 CAED212DAD4 for ; Wed, 31 Aug 2016 04:14:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.221
X-Spam-Level: 
X-Spam-Status: No, score=-4.221 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 aUffk_vvbFOM for ; Wed, 31 Aug 2016 04:14:02 -0700 (PDT)
Received: from sesbmg23.ericsson.net (sesbmg23.ericsson.net [193.180.251.37]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5B1D612DACC for ; Wed, 31 Aug 2016 04:14:02 -0700 (PDT)
X-AuditID: c1b4fb25-8bfff70000001071-e9-57c6bbf70543
Received: from ESESSHC014.ericsson.se (Unknown_Domain [153.88.183.60]) by  (Symantec Mail Security) with SMTP id 03.9A.04209.7FBB6C75; Wed, 31 Aug 2016 13:14:00 +0200 (CEST)
Received: from [159.107.197.179] (153.88.183.153) by smtp.internal.ericsson.com (153.88.183.62) with Microsoft SMTP Server id 14.3.301.0; Wed, 31 Aug 2016 13:13:59 +0200
To: Martin Bjorklund 
References:  <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com> <79de91b0-7084-401c-6967-23519b511c4a@ericsson.com> <20160831.105400.1504024157055343657.mbj@tail-f.com>
From: Balazs Lengyel 
Message-ID: <2dc7a2b4-0d2d-15bc-eb33-1e037801b0aa@ericsson.com>
Date: Wed, 31 Aug 2016 13:13:59 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160831.105400.1504024157055343657.mbj@tail-f.com>
Content-Type: text/plain; charset="windows-1252"; format=flowed
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrBLMWRmVeSWpSXmKPExsUyM2K7je6P3cfCDX681LP4P6uP0aK7+xm7 xfyLjawOzB5Llvxk8tj4azFLAFMUl01Kak5mWWqRvl0CV8b6v03sBVdZK/41HmJqYFzB0sXI ySEhYCIxd8cvpi5GLg4hgfWMEhNaJzBDOGsZJZ51tzGCVAkLREisfLyDHcQWEVCVeLJzLQtE 0QNGiSWX9zCDJJgFNCTWf28BG8smYCQxtf88mM0rYC/x7U43mM0C0nx7NdAgDg5RgRiJ9X0J ECWCEidnPgEr4RRwlPg95RgbSAkzUOuDrWUQ0+Ultr+dA7ZJCGjTwwt/WScwCsxC0j0LoWMW ko4FjMyrGEWLU4uTctONjPVSizKTi4vz8/TyUks2MQLD8+CW36o7GC+/cTzEKMDBqMTDu+Dk 0XAh1sSy4srcQ4wSHMxKIrw3dxwLF+JNSaysSi3Kjy8qzUktPsQozcGiJM7r/1IxXEggPbEk NTs1tSC1CCbLxMEp1cDImvQp9eOjhXc+sXXWTowsPXltheWt441iR4MNG6c1OdhuOdnQvmH6 6dxT6t0TDXPqblV/usg0J4xNuPX74p5jVWLy0tP4fq188vNr9L/bkse3R7Fv//RBpYqNz215 TJF0g9+Zt+nK82aGR5furtJfmxUavK9iVTbn0gbnbt6VByLmH1rx+OcTJZbijERDLeai4kQA MwJct0sCAAA=
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 11:14:07 -0000

That would be a backward incompatible change, which is a general 
problem, not specific to this issue. (like changing a datatype from 
int16 to int8).

In this sense the data set by the system becomes part of the model and 
thus must be covered by backward compatibility rules.

Balazs


On 2016-08-31 10:54, Martin Bjorklund wrote:
> But I assume that the list of supported-compression-algorithm can
> change with a software upgrade, and if so, how do you handle the case
> that the config contains a value that is removed in a software
> upgrade?

-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com


From nobody Wed Aug 31 04:18: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 683AA12DAE2 for ; Wed, 31 Aug 2016 04:17:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.62
X-Spam-Level: 
X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 dHdBF2sX8fgT for ; Wed, 31 Aug 2016 04:17:55 -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 67E9D12DADF for ; Wed, 31 Aug 2016 04:17:55 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 3F69B1E5A07; Wed, 31 Aug 2016 04:13:12 -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 Fa1czH9FulXJ; Wed, 31 Aug 2016 04:13:12 -0700 (PDT)
Received: from [192.168.1.127] (host165-120-184-57.range165-120.btcentralplus.com [165.120.184.57]) by c8a.amsl.com (Postfix) with ESMTPSA id 0D4D51E5A06; Wed, 31 Aug 2016 04:13:10 -0700 (PDT)
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: multipart/alternative; boundary="Apple-Mail=_32A5E666-B8CE-4781-93B0-40DA55B29797"
From: William Lupton 
X-Priority: 3
In-Reply-To: <20160831105106.CFADA1E5A07@c8a.amsl.com>
Date: Wed, 31 Aug 2016 12:17:52 +0100
Message-Id: <8954A825-D818-4888-BBE7-A66CA388EFE7@broadband-forum.org>
References:  <87pop4x2vu.fsf@hobgoblin.ariadne.com>   <20160831105106.CFADA1E5A07@c8a.amsl.com>
To: Jonathan Hansford 
X-Mailer: Apple Mail (2.3124)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements indrafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 11:17:58 -0000

--Apple-Mail=_32A5E666-B8CE-4781-93B0-40DA55B29797
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

I like this. In particular I like the clean use of =E2=80=9Cversion=E2=80=9D=
 and =E2=80=9Crevision=E2=80=9D. Editorial nit: add a comma after =
=E2=80=9Ci.e.=E2=80=9D because that=E2=80=99s the style used for =
=E2=80=9Ce.g.=E2=80=9D. Tx, W.

> On 31 Aug 2016, at 11:56, Jonathan Hansford  =
wrote:
>=20
> How about:
> =20
> NEW:
> =20
> It is not required to keep the full revision history of draft versions =
(e.g., modules contained within Internet-Drafts). That is, within a =
sequence of draft versions, only the most recent revision need be =
recorded in the module. However, whenever a new (i.e. changed) version =
is made available (e.g., via a new version of an Internet-Draft), the =
revision date of that new version MUST be updated to a date later than =
that of the previous version.
> =20
> Jonathan
> =20
> From: William Lupton 
> Sent: 29 August 2016 15:20
> To: Andy Bierman 
> Cc: netmod@ietf.org 
> Subject: Re: [netmod] RFC 6087bis guidance re use of revision =
statements indrafts
> =20
> Andy,
> =20
> This thread started with discussion of an apparent ambiguity in the =
current text:
> =20
> OLD
> =20
> It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is re-posted.
> =20
> =E2=80=94=E2=80=94=20
> =20
> It became clear from the subsequent discussion (thanks Randy!) that =
the above text isn=E2=80=99t intended to mean =E2=80=9Creuse the =
identical revision statement, INCLUDING THE REVISION DATE=E2=80=9D but =
to mean =E2=80=9Creuse the revision statement, UPDATING THE REVISION =
DATE=E2=80=9D.
> =20
> Then other people raised other points, e.g only updating the revision =
date if the YANG has changed, distinguishing between the document and =
the YANG contained therein, and distinguishing between YANG in IDs and =
YANG created by other SDOs. My proposed new text tries to address all of =
these:
> =20
> NEW:
>=20
> It is not required to keep the full revision history of draft versions =
(e.g., modules contained within Internet-Drafts). That is, within a =
sequence of draft versions, only the most recent revision need be =
recorded in the module. However, if the module has changed, the revision =
date of the most recent revision MUST be updated to a later date =
whenever a new version is made available (e.g., via a new version of an =
Internet-Draft).
> =20
> =E2=80=94=E2=80=94
> =20
> I believe that this retains the original intent in a way that resolves =
the original ambiguity and addresses the other points that were raised. =
It it=E2=80=99s =E2=80=9Cworse=E2=80=9D, how is it worse (apart from =
being longer, on which point mea culpa)?
> =20
> Thanks,
> William
> =20
> On 19 Aug 2016, at 15:42, Andy Bierman > wrote:
> =20
> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley > wrote:
> Andy Bierman > writes:
> > An Internet-Draft is NOT a means of "publishing" a specification;
>=20
> As I said, that's the theory, but practice is considerably different.
> =20
> Anybody that implements a work-in-progress knows they are taking a =
risk
> on an unstable document.  The guideline already says MUST update
> the revision date.
> =20
> Not sure what more you want to guidelines document to do.
> =20
> Dale
> =20
> Andy


--Apple-Mail=_32A5E666-B8CE-4781-93B0-40DA55B29797
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

I like this. In particular I like the clean use of =
=E2=80=9Cversion=E2=80=9D and =E2=80=9Crevision=E2=80=9D. Editorial nit: =
add a comma after =E2=80=9Ci.e.=E2=80=9D because that=E2=80=99s the =
style used for =E2=80=9Ce.g.=E2=80=9D. Tx, W.

On =
31 Aug 2016, at 11:56, Jonathan Hansford <jonathan@hansfords.net> wrote:

How about:
 
NEW:
 
It is not required to keep the full revision history of draft =
versions (e.g., modules contained within Internet-Drafts). That is, =
within a sequence of draft versions, only the most recent revision need =
be recorded in the module. However, whenever a new (i.e. changed) =
version is made available (e.g., via a new version of an =
Internet-Draft), the revision date of that new version MUST be updated =
to a date later than that of the previous version.
 
Jonathan
 
From: William Lupton
Sent: 29 August 2016 15:20
To: Andy Bierman
Cc: netmod@ietf.org
Subject: Re: [netmod] RFC =
6087bis guidance re use of revision statements indrafts
 
Andy,
 
This thread started with discussion of an =
apparent ambiguity in the current text:
 
OLD
 
It is acceptable to =
reuse the same revision statement within unpublished versions (i.e., =
Internet-Drafts), but the revision date MUST be updated to a higher =
value each time the Internet-Draft is re-posted.
 
=E2=80=94=E2=80=94 =
;
 
It became clear from =
the subsequent discussion (thanks Randy!) that the above text isn=E2=80=99=
t intended to mean =E2=80=9Creuse the identical revision statement, =
INCLUDING THE REVISION DATE=E2=80=9D but to mean =E2=80=9Creuse the =
revision statement, UPDATING THE REVISION DATE=E2=80=9D.
 
Then other people =
raised other points, e.g only updating the revision date if the YANG has =
changed, distinguishing between the document and the YANG contained =
therein, and distinguishing between YANG in IDs and YANG created by =
other SDOs. My proposed new text tries to address all of these:
 
NEW:

It is not required to keep the full revision history of draft =
versions (e.g., modules contained within Internet-Drafts). That is, =
within a sequence of draft versions, only the most recent revision need =
be recorded in the module. However, if the module has changed, the =
revision date of the most recent revision MUST be updated to a later =
date whenever a new version is made available (e.g., via a new =
version of an Internet-Draft).
 
=E2=80=94=E2=80=94
 
I believe that this =
retains the original intent in a way that resolves the original =
ambiguity and addresses the other points that were raised. It it=E2=80=99s=
 =E2=80=9Cworse=E2=80=9D, how is it worse (apart from being longer, on =
which point mea culpa)?
 
Thanks,
William
 
On 19 Aug 2016, at 15:42, Andy Bierman <andy@yumaworks.com> =
wrote:
 
On Fri, Aug 19, 2016 =
at 7:13 AM, Dale R. Worley <worley@ariadne.com> wrote:
Andy Bierman <andy@yumaworks.com> writes:
> An =
Internet-Draft is NOT a means of "publishing" a specification;

As I said, that's the theory, but practice is =
considerably different.
 
Anybody that =
implements a work-in-progress knows they are taking a risk
on an unstable document.  The guideline =
already says MUST update
the revision =
date.
 
Not sure what more =
you want to guidelines document to do.
 
Dale
 
<=
/div>
Andy

=

--Apple-Mail=_32A5E666-B8CE-4781-93B0-40DA55B29797--


From nobody Wed Aug 31 04:59:28 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 1BDD612DB1A for ; Wed, 31 Aug 2016 04:59:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 CsPoFJYvVlTC for ; Wed, 31 Aug 2016 04:59:23 -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 6E61C12DB13 for ; Wed, 31 Aug 2016 04:59:23 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:8061:38d1:960b:57f6] (unknown [IPv6:2001:718:1a02:1:8061:38d1:960b:57f6]) by mail.nic.cz (Postfix) with ESMTPSA id F3F926110C; Wed, 31 Aug 2016 13:59:21 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1472644762; bh=NTRh0qGYCgbPn9QdjkOVtWh5d0AQza/FXeYUvUGJ7Fo=; h=From:Date:To; b=CpePuodKd10i3csBPW7FwLlvhYZksyQDrDtcRcui12W4l8zcn0cZqF79X/p4WpYHg nGFsCjE/y/MxMsjWpo55j2qEYIVJ+R/l3QGjaiavH2EDxSUJidYwAJsm9LblBrqG6I q9ZfwYhm53GiZYyQLlWoiKAUx6d1ybfMMGr6Bd1E=
Content-Type: text/plain; charset=windows-1252
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Wed, 31 Aug 2016 13:59:26 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <6D0164DD-D9D7-49F8-9DFF-34BFF89244D1@nic.cz>
References:  <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com> <79de91b0-7084-401c-6967-23519b511c4a@ericsson.com> <57C69F18.7000006@transpacket.com>  
To: Balazs Lengyel 
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] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 11:59:26 -0000

> On 31 Aug 2016, at 13:10, Balazs Lengyel  =
wrote:
>=20
> Hello,
>=20
> The problem is not just about identities. It can be a value range. =
Sometimes we have a generic module like iana-interface type that

A value range is IMO a good candidate for a deviation.

>  list a lot of identities, and I don't want to have one YAM file per =
identity, to allow a fine control. Also sadly it is not possible to have =
a deviation removing identities. IMHO would be needed.

What you can do is to bundle the identity in the same module with config =
and state data corresponding to that identity. This is what the routing =
model does with address families: "ipv4-unicast" identity is defined in =
"ietf-ipv4-unicast-routing", and "ipv6-unicast" identity is defined in =
"ietf-ipv6-unicast-routing". This is IMO far better than mirroring

=
http://www.iana.org/assignments/address-family-numbers/address-family-numb=
ers.xhtml

in a module.

>=20
> I would be more interested in having an extension saying static-data. =
This would state that that part of config is set by the system, and can =
not be modified by the user. So I could have conditions based on it, but =
the user might not modify it.

This is something like system-controlled interfaces, no?

Lada

>=20
> regards Balazs
>=20
>=20
> On 2016-08-31 12:38, Ladislav Lhotka wrote:
>>> On 31 Aug 2016, at 11:10, Vladimir Vassilev =
 wrote:
>>>=20
>>> If you design your models using identityref and define the =
identities in separate modules e.g. compression-zip.yang, =
compression-gzip.yang, etc. you can just chose not to load the =
particular YANG models containing the identities not supported when your =
device starts.
>> Right, and I have proposed this approach several times in the past. =
However, some people prefer that the modules defining identities mirror =
IANA and similar registries. In the case of iana-interface-types it also =
means that implementations have to deal with obsolete, obscure and =
experimental interface types that happen to be in the IANA registry but =
nobody will ever want to use.
>>=20
>> Lada
>>=20
>>> If you absolutely can not define your identities in separate YANG =
files (better modularity is indeed the edge YANG has over other modeling =
languages and it should be used) you can use feature with some =
limitations e.g. instead of leaf of type enumeration you will have a =
choice with each case containing if-feature and presence container for =
example.
>>>=20
>>> If you can not change the model to be modular and your =
implementation does not support it 100% then you are not supporting the =
model and you are free to be creative with the workaround but then YANG =
is not the problem.
>>>=20
>>> I also see alternative discussion value in the subject line. Lets =
say one would like to specify in a standard way a list of values =
supported by a device as valid /interface/interface/name values e.g. =
("ge0", "ge1", .... "xe0", "xe1", "me0"). This can be useful in many =
ways e.g. tab completion. Also the supported types for each of the =
interface names and so on further reducing the entropy. Does anyone else =
see value in that?
>>>=20
>>> On 08/31/2016 09:35 AM, Balazs Lengyel wrote:
>>>> Hello Jan,
>>>>=20
>>>> This may be the best solution we have, but nacm rules may be =
changed, and then device limits might be edited by the operator, and =
then we have a problem.
>>>>=20
>>>> The good solution would be to indicate that this is read-only =
static data, and allow must, leafref towards it. However I don't see a =
way to do this in YANG at the moment short of an ericsson-extension.
>>>>=20
>>>> regards Balazs
>>>>=20
>>>>=20
>>>> On 2016-08-30 15:14, Jan Lindblad wrote:
>>>>> Balazs,
>>>>>=20
>>>>>> We have the following design pattern.
>>>>>>=20
>>>>>> 1) An enumeration or a set of identities are defined that define =
a set of options generally supported by Ericsson products.  (e.g. =
supported compression algorithms)
>>>>>> 2) The specific node sets in run-time a leaf-list indicating the =
set of values that this specific node supports (e.g. =
nodes-supported-compression-types: zip, gzip, bz)
>>>>>> 3) For some function the user has to select a specific option =
value (e.g. leaf file-compression for transferring backup files)
>>>>>>=20
>>>>>> Problem: how do you restrict values for (3) - file-compression so =
that it is one of the nodes-supported-compression-types. The natural =
solution would be to use a must expression or a leaf-ref, but as =
nodes-supported-compression-types is config-false data, it is not =
allowed to constrain the config=3Dtrue leaf, file-compression, with it.
>>>>>>=20
>>>>>> It would be perfectly reasonable because the =
nodes-supported-compression-types only change during upgrade, but YANG =
does not allow this.
>>>>>>=20
>>>>>> I would still like to have some modeled solution, not just plain =
English stating the constraint. Any idea how to do it?
>>>>> I have seen this use case many times. I usually solve this by =
making a container with device specific limits, lists of supported =
values, etc, which is config true but with nacm rules preventing =
everyone from making changes. Then I have a device specific database =
initialization file with the correct settings for this device, which is =
loaded into the database at first boot.
>>>>>=20
>>>>> /jan
>>>>>=20
>>> Vladimir
>>>=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
>>=20
>=20
> --=20
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: =
Balazs.Lengyel@ericsson.com

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





From nobody Wed Aug 31 05:00:06 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 BD11512DB13 for ; Wed, 31 Aug 2016 05:00:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 Vx8wmpYlUzyt for ; Wed, 31 Aug 2016 05:00:00 -0700 (PDT)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CAC1212DB19 for ; Wed, 31 Aug 2016 04:59:59 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:8061:38d1:960b:57f6] (unknown [IPv6:2001:718:1a02:1:8061:38d1:960b:57f6]) by mail.nic.cz (Postfix) with ESMTPSA id 765696110C; Wed, 31 Aug 2016 13:59:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1472644798; bh=0bxRv1EyrjW6bRUpiAQBEZvA8454Jnbxo8hhzUMoYt8=; h=From:Date:To; b=eJZV9uo6IbFYkeedM4sYLJtp+f0qZZ/ytFAHhs1s8DH5jaSF+G0a5QFVdecvS0BCJ QC1wdHjOoOnitKACzSs2sVbindGpxVDJkFTRblX2HuX79rqgf03LSsvsP0r6ufpezj qyy71ky4iqgwuZAQC7NgZEwQoayq+4LC4ryxEX2A=
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
Content-Type: text/plain; charset=utf-8
From: Ladislav Lhotka 
X-Priority: 3
In-Reply-To: <8954A825-D818-4888-BBE7-A66CA388EFE7@broadband-forum.org>
Date: Wed, 31 Aug 2016 14:00:03 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: <51D56099-9C3D-4873-B830-B73FD4734189@nic.cz>
References:  <87pop4x2vu.fsf@hobgoblin.ariadne.com>   <20160831105106.CFADA1E5A07@c8a.amsl.com> <8954A825-D818-4888-BBE7-A66CA388EFE7@broadband-forum.org>
To: William Lupton 
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] RFC 6087bis guidance re use of revision statements indrafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 12:00:05 -0000

> On 31 Aug 2016, at 13:17, William Lupton  =
wrote:
>=20
> I like this. In particular I like the clean use of =E2=80=9Cversion=E2=80=
=9D and =E2=80=9Crevision=E2=80=9D. Editorial nit: add a comma after =
=E2=80=9Ci.e.=E2=80=9D because that=E2=80=99s the style used for =
=E2=80=9Ce.g.=E2=80=9D. Tx, W.

+1

Lada

>=20
>> On 31 Aug 2016, at 11:56, Jonathan Hansford  =
wrote:
>>=20
>> How about:
>> =20
>> NEW:
>> =20
>> It is not required to keep the full revision history of draft =
versions (e.g., modules contained within Internet-Drafts). That is, =
within a sequence of draft versions, only the most recent revision need =
be recorded in the module. However, whenever a new (i.e. changed) =
version is made available (e.g., via a new version of an =
Internet-Draft), the revision date of that new version MUST be updated =
to a date later than that of the previous version.
>> =20
>> Jonathan
>> =20
>> From: William Lupton
>> Sent: 29 August 2016 15:20
>> To: Andy Bierman
>> Cc: netmod@ietf.org
>> Subject: Re: [netmod] RFC 6087bis guidance re use of revision =
statements indrafts
>> =20
>> Andy,
>> =20
>> This thread started with discussion of an apparent ambiguity in the =
current text:
>> =20
>> OLD
>> =20
>> It is acceptable to reuse the same revision statement within =
unpublished versions (i.e., Internet-Drafts), but the revision date MUST =
be updated to a higher value each time the Internet-Draft is re-posted.
>> =20
>> =E2=80=94=E2=80=94=20
>> =20
>> It became clear from the subsequent discussion (thanks Randy!) that =
the above text isn=E2=80=99t intended to mean =E2=80=9Creuse the =
identical revision statement, INCLUDING THE REVISION DATE=E2=80=9D but =
to mean =E2=80=9Creuse the revision statement, UPDATING THE REVISION =
DATE=E2=80=9D.
>> =20
>> Then other people raised other points, e.g only updating the revision =
date if the YANG has changed, distinguishing between the document and =
the YANG contained therein, and distinguishing between YANG in IDs and =
YANG created by other SDOs. My proposed new text tries to address all of =
these:
>> =20
>> NEW:
>>=20
>> It is not required to keep the full revision history of draft =
versions (e.g., modules contained within Internet-Drafts). That is, =
within a sequence of draft versions, only the most recent revision need =
be recorded in the module. However, if the module has changed, the =
revision date of the most recent revision MUST be updated to a later =
date whenever a new version is made available (e.g., via a new version =
of an Internet-Draft).
>> =20
>> =E2=80=94=E2=80=94
>> =20
>> I believe that this retains the original intent in a way that =
resolves the original ambiguity and addresses the other points that were =
raised. It it=E2=80=99s =E2=80=9Cworse=E2=80=9D, how is it worse (apart =
from being longer, on which point mea culpa)?
>> =20
>> Thanks,
>> William
>> =20
>> On 19 Aug 2016, at 15:42, Andy Bierman  wrote:
>> =20
>> On Fri, Aug 19, 2016 at 7:13 AM, Dale R. Worley  =
wrote:
>> Andy Bierman  writes:
>> > An Internet-Draft is NOT a means of "publishing" a specification;
>>=20
>> As I said, that's the theory, but practice is considerably different.
>> =20
>> Anybody that implements a work-in-progress knows they are taking a =
risk
>> on an unstable document.  The guideline already says MUST update
>> the revision date.
>> =20
>> Not sure what more you want to guidelines document to do.
>> =20
>> Dale
>> =20
>> Andy
>=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 Aug 31 05:14: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 42CB412DB29 for ; Wed, 31 Aug 2016 05:14:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.069
X-Spam-Level: 
X-Spam-Status: No, score=-15.069 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.548, 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 hMR_W6IMOr_2 for ; Wed, 31 Aug 2016 05:14:52 -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 6BF2D12DB2C for ; Wed, 31 Aug 2016 05:14:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5802; q=dns/txt; s=iport; t=1472645692; x=1473855292; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=STfq32DSI0Pi+N9SK7vbHZkA0Jwx+w1nF/4i26Sos1A=; b=EZVMfEGLhCAgRsEgZZRCXsxWdRRI/ZjGRhcV2vce1dGac4IVtF336CWK F3qUxUOfKOayEineE3M7uw0b1DfbHb1TPk46AG+lC23xPMfysWoUB+Qhm aJKMYerbwEnbWKfLOyeZiQNnRfchYiV9t5JxgCyLZwmzC5p3TqTGcn21n I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAgBDycZX/5JdJa1cg00BAQEBAR5Xf?= =?us-ascii?q?AeDQLRgggEkhS9KAhyBNTgUAQIBAQEBAQEBXieEYQEBBAEBASEROgsQAgEGAhE?= =?us-ascii?q?EAQEBAgImAgICJQsVCAgCBAENBYg+CA6RIJ0jjyEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEXBYEFiHSBA4E5gweDAoJaAQSZUAGPL4FtjWqGcIVYg3gBHjaCRw0OgU1?= =?us-ascii?q?whW1/AQEB?=
X-IronPort-AV: E=Sophos;i="5.30,261,1470700800"; d="scan'208";a="143737644"
Received: from rcdn-core-10.cisco.com ([173.37.93.146]) by rcdn-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 31 Aug 2016 12:14:51 +0000
Received: from XCH-RTP-011.cisco.com (xch-rtp-011.cisco.com [64.101.220.151]) by rcdn-core-10.cisco.com (8.14.5/8.14.5) with ESMTP id u7VCEpj3004781 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 31 Aug 2016 12:14:51 GMT
Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-011.cisco.com (64.101.220.151) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Wed, 31 Aug 2016 08:14:50 -0400
Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1210.000; Wed, 31 Aug 2016 08:14:50 -0400
From: "Acee Lindem (acee)" 
To: Ladislav Lhotka , William Lupton 
Thread-Topic: [netmod] RFC 6087bis guidance re use of revision statements indrafts
Thread-Index: AQHSA3lcO0a5E/6cDEGnt1fL75aK5KBjOoWA///BDgA=
Date: Wed, 31 Aug 2016 12:14:50 +0000
Message-ID: 
References:  <87pop4x2vu.fsf@hobgoblin.ariadne.com>   <20160831105106.CFADA1E5A07@c8a.amsl.com> <8954A825-D818-4888-BBE7-A66CA388EFE7@broadband-forum.org> <51D56099-9C3D-4873-B830-B73FD4734189@nic.cz>
In-Reply-To: <51D56099-9C3D-4873-B830-B73FD4734189@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.198]
Content-Type: text/plain; charset="utf-8"
Content-ID: <09C13BBC1EC4A3449A43BA458BC7EDCA@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements indrafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 12:14:54 -0000

DQoNCk9uIDgvMzEvMTYsIDg6MDAgQU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIExhZGlzbGF2IExo
b3RrYSINCjxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2YgbGhvdGthQG5pYy5j
ej4gd3JvdGU6DQoNCj4NCj4+IE9uIDMxIEF1ZyAyMDE2LCBhdCAxMzoxNywgV2lsbGlhbSBMdXB0
b24gPHdsdXB0b25AYnJvYWRiYW5kLWZvcnVtLm9yZz4NCj4+d3JvdGU6DQo+PiANCj4+IEkgbGlr
ZSB0aGlzLiBJbiBwYXJ0aWN1bGFyIEkgbGlrZSB0aGUgY2xlYW4gdXNlIG9mIOKAnHZlcnNpb27i
gJ0gYW5kDQo+PuKAnHJldmlzaW9u4oCdLiBFZGl0b3JpYWwgbml0OiBhZGQgYSBjb21tYSBhZnRl
ciDigJxpLmUu4oCdIGJlY2F1c2UgdGhhdOKAmXMgdGhlDQo+PnN0eWxlIHVzZWQgZm9yIOKAnGUu
Zy7igJ0uIFR4LCBXLg0KPg0KPisxDQo+DQo+TGFkYQ0KDQpJIGxpa2UgdGhpcyB0ZXh0IGFzIHdl
bGwuIEtlZXBpbmcgYSBjb21wbGV0ZSByZXZpc2lvbiBoaXN0b3J5IGluIHRoZSBtb2RlbA0KY2Fu
IGJlY29tZSB1bndpZWxkeS4gQmVzaWRlcywgZ2l0IGRvZXMgYSBNVUNIIGJldHRlciBqb2Igb2Yg
dGhpcy4NCg0KVGhhbmtzLA0KQWNlZQ0KDQoNCg0KDQoNCj4NCj4+IA0KPj4+IE9uIDMxIEF1ZyAy
MDE2LCBhdCAxMTo1NiwgSm9uYXRoYW4gSGFuc2ZvcmQgPGpvbmF0aGFuQGhhbnNmb3Jkcy5uZXQ+
DQo+Pj53cm90ZToNCj4+PiANCj4+PiBIb3cgYWJvdXQ6DQo+Pj4gIA0KPj4+IE5FVzoNCj4+PiAg
DQo+Pj4gSXQgaXMgbm90IHJlcXVpcmVkIHRvIGtlZXAgdGhlIGZ1bGwgcmV2aXNpb24gaGlzdG9y
eSBvZiBkcmFmdCB2ZXJzaW9ucw0KPj4+KGUuZy4sIG1vZHVsZXMgY29udGFpbmVkIHdpdGhpbiBJ
bnRlcm5ldC1EcmFmdHMpLiBUaGF0IGlzLCB3aXRoaW4gYQ0KPj4+c2VxdWVuY2Ugb2YgZHJhZnQg
dmVyc2lvbnMsIG9ubHkgdGhlIG1vc3QgcmVjZW50IHJldmlzaW9uIG5lZWQgYmUNCj4+PnJlY29y
ZGVkIGluIHRoZSBtb2R1bGUuIEhvd2V2ZXIsIHdoZW5ldmVyIGEgbmV3IChpLmUuIGNoYW5nZWQp
IHZlcnNpb24NCj4+PmlzIG1hZGUgYXZhaWxhYmxlIChlLmcuLCB2aWEgYSBuZXcgdmVyc2lvbiBv
ZiBhbiBJbnRlcm5ldC1EcmFmdCksIHRoZQ0KPj4+cmV2aXNpb24gZGF0ZSBvZiB0aGF0IG5ldyB2
ZXJzaW9uIE1VU1QgYmUgdXBkYXRlZCB0byBhIGRhdGUgbGF0ZXIgdGhhbg0KPj4+dGhhdCBvZiB0
aGUgcHJldmlvdXMgdmVyc2lvbi4NCj4+PiAgDQo+Pj4gSm9uYXRoYW4NCj4+PiAgDQo+Pj4gRnJv
bTogV2lsbGlhbSBMdXB0b24NCj4+PiBTZW50OiAyOSBBdWd1c3QgMjAxNiAxNToyMA0KPj4+IFRv
OiBBbmR5IEJpZXJtYW4NCj4+PiBDYzogbmV0bW9kQGlldGYub3JnDQo+Pj4gU3ViamVjdDogUmU6
IFtuZXRtb2RdIFJGQyA2MDg3YmlzIGd1aWRhbmNlIHJlIHVzZSBvZiByZXZpc2lvbg0KPj4+c3Rh
dGVtZW50cyBpbmRyYWZ0cw0KPj4+ICANCj4+PiBBbmR5LA0KPj4+ICANCj4+PiBUaGlzIHRocmVh
ZCBzdGFydGVkIHdpdGggZGlzY3Vzc2lvbiBvZiBhbiBhcHBhcmVudCBhbWJpZ3VpdHkgaW4gdGhl
DQo+Pj5jdXJyZW50IHRleHQ6DQo+Pj4gIA0KPj4+IE9MRA0KPj4+ICANCj4+PiBJdCBpcyBhY2Nl
cHRhYmxlIHRvIHJldXNlIHRoZSBzYW1lIHJldmlzaW9uIHN0YXRlbWVudCB3aXRoaW4NCj4+PnVu
cHVibGlzaGVkIHZlcnNpb25zIChpLmUuLCBJbnRlcm5ldC1EcmFmdHMpLCBidXQgdGhlIHJldmlz
aW9uIGRhdGUNCj4+Pk1VU1QgYmUgdXBkYXRlZCB0byBhIGhpZ2hlciB2YWx1ZSBlYWNoIHRpbWUg
dGhlIEludGVybmV0LURyYWZ0IGlzDQo+Pj5yZS1wb3N0ZWQuDQo+Pj4gIA0KPj4+IOKAlOKAlCAN
Cj4+PiAgDQo+Pj4gSXQgYmVjYW1lIGNsZWFyIGZyb20gdGhlIHN1YnNlcXVlbnQgZGlzY3Vzc2lv
biAodGhhbmtzIFJhbmR5ISkgdGhhdA0KPj4+dGhlIGFib3ZlIHRleHQgaXNu4oCZdCBpbnRlbmRl
ZCB0byBtZWFuIOKAnHJldXNlIHRoZSBpZGVudGljYWwgcmV2aXNpb24NCj4+PnN0YXRlbWVudCwg
SU5DTFVESU5HIFRIRSBSRVZJU0lPTiBEQVRF4oCdIGJ1dCB0byBtZWFuIOKAnHJldXNlIHRoZSBy
ZXZpc2lvbg0KPj4+c3RhdGVtZW50LCBVUERBVElORyBUSEUgUkVWSVNJT04gREFUReKAnS4NCj4+
PiAgDQo+Pj4gVGhlbiBvdGhlciBwZW9wbGUgcmFpc2VkIG90aGVyIHBvaW50cywgZS5nIG9ubHkg
dXBkYXRpbmcgdGhlIHJldmlzaW9uDQo+Pj5kYXRlIGlmIHRoZSBZQU5HIGhhcyBjaGFuZ2VkLCBk
aXN0aW5ndWlzaGluZyBiZXR3ZWVuIHRoZSBkb2N1bWVudCBhbmQNCj4+PnRoZSBZQU5HIGNvbnRh
aW5lZCB0aGVyZWluLCBhbmQgZGlzdGluZ3Vpc2hpbmcgYmV0d2VlbiBZQU5HIGluIElEcyBhbmQN
Cj4+PllBTkcgY3JlYXRlZCBieSBvdGhlciBTRE9zLiBNeSBwcm9wb3NlZCBuZXcgdGV4dCB0cmll
cyB0byBhZGRyZXNzIGFsbA0KPj4+b2YgdGhlc2U6DQo+Pj4gIA0KPj4+IE5FVzoNCj4+PiANCj4+
PiBJdCBpcyBub3QgcmVxdWlyZWQgdG8ga2VlcCB0aGUgZnVsbCByZXZpc2lvbiBoaXN0b3J5IG9m
IGRyYWZ0IHZlcnNpb25zDQo+Pj4oZS5nLiwgbW9kdWxlcyBjb250YWluZWQgd2l0aGluIEludGVy
bmV0LURyYWZ0cykuIFRoYXQgaXMsIHdpdGhpbiBhDQo+Pj5zZXF1ZW5jZSBvZiBkcmFmdCB2ZXJz
aW9ucywgb25seSB0aGUgbW9zdCByZWNlbnQgcmV2aXNpb24gbmVlZCBiZQ0KPj4+cmVjb3JkZWQg
aW4gdGhlIG1vZHVsZS4gSG93ZXZlciwgaWYgdGhlIG1vZHVsZSBoYXMgY2hhbmdlZCwgdGhlDQo+
Pj5yZXZpc2lvbiBkYXRlIG9mIHRoZSBtb3N0IHJlY2VudCByZXZpc2lvbiBNVVNUIGJlIHVwZGF0
ZWQgdG8gYSBsYXRlcg0KPj4+ZGF0ZSB3aGVuZXZlciBhIG5ldyB2ZXJzaW9uIGlzIG1hZGUgYXZh
aWxhYmxlIChlLmcuLCB2aWEgYSBuZXcgdmVyc2lvbg0KPj4+b2YgYW4gSW50ZXJuZXQtRHJhZnQp
Lg0KPj4+ICANCj4+PiDigJTigJQNCj4+PiAgDQo+Pj4gSSBiZWxpZXZlIHRoYXQgdGhpcyByZXRh
aW5zIHRoZSBvcmlnaW5hbCBpbnRlbnQgaW4gYSB3YXkgdGhhdCByZXNvbHZlcw0KPj4+dGhlIG9y
aWdpbmFsIGFtYmlndWl0eSBhbmQgYWRkcmVzc2VzIHRoZSBvdGhlciBwb2ludHMgdGhhdCB3ZXJl
IHJhaXNlZC4NCj4+Pkl0IGl04oCZcyDigJx3b3JzZeKAnSwgaG93IGlzIGl0IHdvcnNlIChhcGFy
dCBmcm9tIGJlaW5nIGxvbmdlciwgb24gd2hpY2gNCj4+PnBvaW50IG1lYSBjdWxwYSk/DQo+Pj4g
IA0KPj4+IFRoYW5rcywNCj4+PiBXaWxsaWFtDQo+Pj4gIA0KPj4+IE9uIDE5IEF1ZyAyMDE2LCBh
dCAxNTo0MiwgQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPj4+ICAN
Cj4+PiBPbiBGcmksIEF1ZyAxOSwgMjAxNiBhdCA3OjEzIEFNLCBEYWxlIFIuIFdvcmxleSA8d29y
bGV5QGFyaWFkbmUuY29tPg0KPj4+d3JvdGU6DQo+Pj4gQW5keSBCaWVybWFuIDxhbmR5QHl1bWF3
b3Jrcy5jb20+IHdyaXRlczoNCj4+PiA+IEFuIEludGVybmV0LURyYWZ0IGlzIE5PVCBhIG1lYW5z
IG9mICJwdWJsaXNoaW5nIiBhIHNwZWNpZmljYXRpb247DQo+Pj4gDQo+Pj4gQXMgSSBzYWlkLCB0
aGF0J3MgdGhlIHRoZW9yeSwgYnV0IHByYWN0aWNlIGlzIGNvbnNpZGVyYWJseSBkaWZmZXJlbnQu
DQo+Pj4gIA0KPj4+IEFueWJvZHkgdGhhdCBpbXBsZW1lbnRzIGEgd29yay1pbi1wcm9ncmVzcyBr
bm93cyB0aGV5IGFyZSB0YWtpbmcgYSByaXNrDQo+Pj4gb24gYW4gdW5zdGFibGUgZG9jdW1lbnQu
ICBUaGUgZ3VpZGVsaW5lIGFscmVhZHkgc2F5cyBNVVNUIHVwZGF0ZQ0KPj4+IHRoZSByZXZpc2lv
biBkYXRlLg0KPj4+ICANCj4+PiBOb3Qgc3VyZSB3aGF0IG1vcmUgeW91IHdhbnQgdG8gZ3VpZGVs
aW5lcyBkb2N1bWVudCB0byBkby4NCj4+PiAgDQo+Pj4gRGFsZQ0KPj4+ICANCj4+PiBBbmR5DQo+
PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+
PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+PiBuZXRtb2RAaWV0Zi5vcmcNCj4+IGh0dHBzOi8vd3d3
LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQo+DQo+LS0NCj5MYWRpc2xhdiBMaG90
a2EsIENaLk5JQyBMYWJzDQo+UEdQIEtleSBJRDogRTc0RThDMEMNCj4NCj4NCj4NCj4NCj5fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPm5ldG1vZCBtYWls
aW5nIGxpc3QNCj5uZXRtb2RAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFu
L2xpc3RpbmZvL25ldG1vZA0KDQo=


From nobody Wed Aug 31 05:16: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 13E6112B029 for ; Wed, 31 Aug 2016 05:16:03 -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 ZlHuGybmGgb3 for ; Wed, 31 Aug 2016 05:16:01 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5BA8F12D0BB for ; Wed, 31 Aug 2016 05:16:01 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 801ED1422757; Wed, 31 Aug 2016 14:15:59 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id m4wWr16dTbyz; Wed, 31 Aug 2016 14:15:59 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 5C1341422756; Wed, 31 Aug 2016 14:15:59 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id QYyxLnhZE2pS; Wed, 31 Aug 2016 14:15:59 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id 34F2D1422754; Wed, 31 Aug 2016 14:15:59 +0200 (CEST)
Message-ID: <57C6CA8E.4030101@transpacket.com>
Date: Wed, 31 Aug 2016 14:16:14 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Ladislav Lhotka , netmod@ietf.org
References:  <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com> <79de91b0-7084-401c-6967-23519b511c4a@ericsson.com> <57C69F18.7000006@transpacket.com> 
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 12:16:03 -0000

On 08/31/2016 12:38 PM, Ladislav Lhotka wrote:
>> On 31 Aug 2016, at 11:10, Vladimir Vassilev  wrote:
>>
>> If you design your models using identityref and define the identities in separate modules e.g. compression-zip.yang, compression-gzip.yang, etc. you can just chose not to load the particular YANG models containing the identities not supported when your device starts.
> Right, and I have proposed this approach several times in the past. However, some people prefer that the modules defining identities mirror IANA and similar registries. In the case of iana-interface-types it also means that implementations have to deal with obsolete, obscure and experimental interface types that happen to be in the IANA registry but nobody will ever want to use.
>
> Lada
+1

The 275 identities defined in iana-if-type.yang appearing as possible 
/interfaces/interface/type tab completion options in a YANG aware cli or 
drop-down menu in gui is annoying and stands out as an obvious problem.

It is not late to split the file. No standard RFC YANG model includes 
iana-if-type.yang yet. The actually referenced identities in current 
drafts is less then 16 (grep-ing in my known YANG model archive) 
{ethernetCsmacd, l2vlan, ieee8023adLag, ifPwType, pos, atm, 
atmSubInterface, sonet, otnOtu, frameRelay, bridge, macSecControlledIF, 
fastdsl}

If not single instance per file maybe dividing the file into categories 
so if your device is atm aware you import iana-if-type-atm.yang and get 
{atm, atmSubInterface}.

However we can probably agree the iana-if-type.yang exception is not a 
valid excuse for new models like the one in the example where there are 
3 compression methods to not modularize the identity definitions into 
separate files and not load identities the implementation does not 
support but instead resolve to workaround solutions.

Vladimir


From nobody Wed Aug 31 06:51: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 AB71512DBE7 for ; Wed, 31 Aug 2016 06:51: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, 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 FCvqa-kKlLK7 for ; Wed, 31 Aug 2016 06:51:27 -0700 (PDT)
Received: from mail.transpacket.com (s91205186171.blix.com [91.205.186.171]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EF42712DBAE for ; Wed, 31 Aug 2016 06:41:10 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 00909142279B; Wed, 31 Aug 2016 15:41:09 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id ZVBRDVZKvuu2; Wed, 31 Aug 2016 15:41:08 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id CE6F3142279A; Wed, 31 Aug 2016 15:41:08 +0200 (CEST)
Received: from mail.transpacket.com ([127.0.0.1]) by localhost (mail.transpacket.com [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id iLrO1EjjUTiP; Wed, 31 Aug 2016 15:41:08 +0200 (CEST)
Received: from [192.168.209.141] (s1853520235.blix.com [185.35.202.35]) by mail.transpacket.com (Postfix) with ESMTPSA id AAE181422799; Wed, 31 Aug 2016 15:41:08 +0200 (CEST)
Message-ID: <57C6DE85.6070705@transpacket.com>
Date: Wed, 31 Aug 2016 15:41:25 +0200
From: Vladimir Vassilev 
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Icedove/31.7.0
MIME-Version: 1.0
To: Balazs Lengyel , netmod@ietf.org
References:  <251BF209-A065-4208-8085-A2A1726FFB27@tail-f.com> <79de91b0-7084-401c-6967-23519b511c4a@ericsson.com> <57C69F18.7000006@transpacket.com>  
In-Reply-To: 
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] How to constrain a leaf to a read-only list of supported values?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 13:51:34 -0000

On 08/31/2016 01:10 PM, Balazs Lengyel wrote:
> Hello,
>
> The problem is not just about identities. It can be a value range.
If your example was about value range then a deviation would be a 
solution. Then we have the same case for modularization. YANG files 
defining deviations loaded when the deviation is relevant and not loaded 
otherwise.
> Sometimes we have a generic module like iana-interface type that list 
> a lot of identities, and I don't want to have one YAM file per 
> identity, to allow a fine control. Also sadly it is not possible to 
> have a deviation removing identities. IMHO would be needed.
Well the biggest problem modularizing your identity definitions is you 
will have more YANG files proportional to the flexibility you want. I 
would have chosen that in the example you provide.
>
> I would be more interested in having an extension saying static-data. 
> This would state that that part of config is set by the system, and 
> can not be modified by the user. So I could have conditions based on 
> it, but the user might not modify it.
That is still not as good as modularization of your model and using 
optionally loadable YANG 'deviation's and 'identity' definitions. Even 
if you have "static-data tree" you will be able to use must statements 
to not allow certain range based on that "static data tree" it will 
still be the range defined in the type from the model that will be shown 
to the user editing the configuration in YANG aware CLI or GUI. It is 
still a workaround even if the must statement will fail upon commit.


From nobody Wed Aug 31 08:46: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 8151412B074 for ; Wed, 31 Aug 2016 08:46:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.922
X-Spam-Level: 
X-Spam-Status: No, score=-1.922 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d8dVAdJu9tcT for ; Wed, 31 Aug 2016 08:46:36 -0700 (PDT)
Received: from NAM01-BN3-obe.outbound.protection.outlook.com (mail-bn3nam01on0127.outbound.protection.outlook.com [104.47.33.127]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D623A12DB96 for ; Wed, 31 Aug 2016 08:30:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=yQ1hWR/bL+Q5+QafsbRa0266+F7ybRjFjfqD6mYMZHw=; b=JAI5jzIKTJZsUPFN9KT7ikpr5Tr1t66pWRDLYd0ALZrb5mqUOjx6d4JCX7oUkurTdvJbHKYH/en6fiInSGzEtN09XrDmTysO+xLjwMyIQxqsiyuU64hRpoW5hX98wC5GldY+pxzX+++c/rzDOd2h4SAa+wSK4uoRIHbcuGFAvYM=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1449.namprd05.prod.outlook.com (10.160.148.155) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.599.8; Wed, 31 Aug 2016 15:30:14 +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.0609.002; Wed, 31 Aug 2016 15:30:14 +0000
From: Kent Watsen 
To: "Acee Lindem (acee)" , Ladislav Lhotka , William Lupton 
Thread-Topic: [netmod] RFC 6087bis guidance re use of revision statements indrafts
Thread-Index: AQHSA3lWn/4p5jiM0UqpbTBWCiCLIqBi93eAgAAEIQD///OKAA==
Date: Wed, 31 Aug 2016 15:30:14 +0000
Message-ID: <09C31680-316E-4AC6-A353-1FAF481EA61C@juniper.net>
References:  <87pop4x2vu.fsf@hobgoblin.ariadne.com>   <20160831105106.CFADA1E5A07@c8a.amsl.com> <8954A825-D818-4888-BBE7-A66CA388EFE7@broadband-forum.org> <51D56099-9C3D-4873-B830-B73FD4734189@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/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [137.118.194.116]
x-ms-office365-filtering-correlation-id: 34699fc8-ddaf-439d-bea6-08d3d1b3b433
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1449; 6:f0ocRSLkcQ8w90bNH9pgt5Z5oYB7Lh/ehWZRjp2uD89lxJMtVrFmzTZCebgmCxh/fnz02PbKvHb7isyr/FhJ29+19alIjmJoNw1boBgeBhw2DFTaFtt8zssr0MrOMAgSdMOyotsB/UI1CCxTBmPowJEyBIfrBN9y8kd8Ypkkq4ko3N/ZrPb3GwH1HSegkumphHNlh37QyLxMvoW2sESlFfw3rvBOTlaIOWLlzdMzsvC13G/fYasTyQ+afw298ftiWQhi936Dlhr/EDj+5lSNvqhWvfguLk0pp8vT0Ktcw14lodfW6iap78+by49159/zqtOxAiqGSNJ0R/PJR5HCnA==; 5:M/lI3Rde2NpE4IgpB/ZWT2kQ55a7siY93Vpi4ohrBNv7CvdutDCv7X77Kt2O+CH1dWDAahErHQOQwk3am+NdxLabCDWiK5CLR54WTh7+11mBVvohmxHAqH+brzOxD73UNgPiHom1cDe39L4nAxzHcw==; 24:wxqPEomHbQZxCaQFQ1cqahrNG4d7e0nC3Morc0UctbdlsXdORvxBvcOwr19eyhWSE1yDpwtdI3kwuAzAEGWaLC9bfbkhcdBBy9VCrwevl1Q=; 7:6wp67ivXiyak40oAihGxplvbMMglaLyB8d//ibm3kQFa2IHdnY3mgjrzOcpGmw/2Ln/5nw4xhcbom1FEDr8DfMGYLNH176yaJ/UAXSLqrmqzUxOrce664LpmB7EcfuoAwtMqSxs/5+aN7T1MRZbBvMfcxyCjU+J2n1YIIswxtThFtwGEiVMRFn7YBO4IzNvZ8taPEPuQiJAYKuKM1qP9upL8TpwqQ7/xKBfWzaDYGAC4qQfmWzq1L6JjixPzdvLz
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1449;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1449; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1449; 
x-forefront-prvs: 00514A2FE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(377454003)(24454002)(189002)(199003)(5002640100001)(106356001)(87936001)(106116001)(7846002)(4001350100001)(3900700001)(105586002)(7736002)(3660700001)(97736004)(93886004)(77096005)(305945005)(2950100001)(68736007)(19580395003)(10400500002)(101416001)(92566002)(189998001)(36756003)(11100500001)(3280700002)(54356999)(4326007)(66066001)(83506001)(8936002)(99286002)(3846002)(82746002)(102836003)(33656002)(122556002)(19580405001)(2900100001)(5660300001)(6116002)(2906002)(76176999)(586003)(575784001)(50986999)(86362001)(15975445007)(81156014)(5001770100001)(8676002)(81166006)(83716003)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1449; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <02896F77A8F6A249B9095098D9804A7D@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 15:30:14.1192 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR0501MB1449
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] RFC 6087bis guidance re use of revision statements indrafts
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 15:46:39 -0000

SSBsaWtlIEpvbmF0aGFu4oCZcyBwcm9wb3NlZCB0ZXh0IGFzIHdlbGwuDQoNCktlbnQgLy8gYXMg
YSBjb250cmlidXRvcg0KDQoNCk9uIDgvMzEvMTYsIDg6MTQgQU0sICJuZXRtb2Qgb24gYmVoYWxm
IG9mIEFjZWUgTGluZGVtIChhY2VlKSIgPG5ldG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFs
ZiBvZiBhY2VlQGNpc2NvLmNvbT4gd3JvdGU6DQoNCiAgICANCiAgICANCiAgICBPbiA4LzMxLzE2
LCA4OjAwIEFNLCAibmV0bW9kIG9uIGJlaGFsZiBvZiBMYWRpc2xhdiBMaG90a2EiDQogICAgPG5l
dG1vZC1ib3VuY2VzQGlldGYub3JnIG9uIGJlaGFsZiBvZiBsaG90a2FAbmljLmN6PiB3cm90ZToN
CiAgICANCiAgICA+DQogICAgPj4gT24gMzEgQXVnIDIwMTYsIGF0IDEzOjE3LCBXaWxsaWFtIEx1
cHRvbiA8d2x1cHRvbkBicm9hZGJhbmQtZm9ydW0ub3JnPg0KICAgID4+d3JvdGU6DQogICAgPj4g
DQogICAgPj4gSSBsaWtlIHRoaXMuIEluIHBhcnRpY3VsYXIgSSBsaWtlIHRoZSBjbGVhbiB1c2Ug
b2Yg4oCcdmVyc2lvbuKAnSBhbmQNCiAgICA+PuKAnHJldmlzaW9u4oCdLiBFZGl0b3JpYWwgbml0
OiBhZGQgYSBjb21tYSBhZnRlciDigJxpLmUu4oCdIGJlY2F1c2UgdGhhdOKAmXMgdGhlDQogICAg
Pj5zdHlsZSB1c2VkIGZvciDigJxlLmcu4oCdLiBUeCwgVy4NCiAgICA+DQogICAgPisxDQogICAg
Pg0KICAgID5MYWRhDQogICAgDQogICAgSSBsaWtlIHRoaXMgdGV4dCBhcyB3ZWxsLiBLZWVwaW5n
IGEgY29tcGxldGUgcmV2aXNpb24gaGlzdG9yeSBpbiB0aGUgbW9kZWwNCiAgICBjYW4gYmVjb21l
IHVud2llbGR5LiBCZXNpZGVzLCBnaXQgZG9lcyBhIE1VQ0ggYmV0dGVyIGpvYiBvZiB0aGlzLg0K
ICAgIA0KICAgIFRoYW5rcywNCiAgICBBY2VlDQogICAgDQogICAgDQogICAgDQogICAgDQogICAg
DQogICAgPg0KICAgID4+IA0KICAgID4+PiBPbiAzMSBBdWcgMjAxNiwgYXQgMTE6NTYsIEpvbmF0
aGFuIEhhbnNmb3JkIDxqb25hdGhhbkBoYW5zZm9yZHMubmV0Pg0KICAgID4+Pndyb3RlOg0KICAg
ID4+PiANCiAgICA+Pj4gSG93IGFib3V0Og0KICAgID4+PiAgDQogICAgPj4+IE5FVzoNCiAgICA+
Pj4gIA0KICAgID4+PiBJdCBpcyBub3QgcmVxdWlyZWQgdG8ga2VlcCB0aGUgZnVsbCByZXZpc2lv
biBoaXN0b3J5IG9mIGRyYWZ0IHZlcnNpb25zDQogICAgPj4+KGUuZy4sIG1vZHVsZXMgY29udGFp
bmVkIHdpdGhpbiBJbnRlcm5ldC1EcmFmdHMpLiBUaGF0IGlzLCB3aXRoaW4gYQ0KICAgID4+PnNl
cXVlbmNlIG9mIGRyYWZ0IHZlcnNpb25zLCBvbmx5IHRoZSBtb3N0IHJlY2VudCByZXZpc2lvbiBu
ZWVkIGJlDQogICAgPj4+cmVjb3JkZWQgaW4gdGhlIG1vZHVsZS4gSG93ZXZlciwgd2hlbmV2ZXIg
YSBuZXcgKGkuZS4gY2hhbmdlZCkgdmVyc2lvbg0KICAgID4+PmlzIG1hZGUgYXZhaWxhYmxlIChl
LmcuLCB2aWEgYSBuZXcgdmVyc2lvbiBvZiBhbiBJbnRlcm5ldC1EcmFmdCksIHRoZQ0KICAgID4+
PnJldmlzaW9uIGRhdGUgb2YgdGhhdCBuZXcgdmVyc2lvbiBNVVNUIGJlIHVwZGF0ZWQgdG8gYSBk
YXRlIGxhdGVyIHRoYW4NCiAgICA+Pj50aGF0IG9mIHRoZSBwcmV2aW91cyB2ZXJzaW9uLg0KICAg
ID4+PiAgDQogICAgPj4+IEpvbmF0aGFuDQogICAgPj4+ICANCiAgICA+Pj4gRnJvbTogV2lsbGlh
bSBMdXB0b24NCiAgICA+Pj4gU2VudDogMjkgQXVndXN0IDIwMTYgMTU6MjANCiAgICA+Pj4gVG86
IEFuZHkgQmllcm1hbg0KICAgID4+PiBDYzogbmV0bW9kQGlldGYub3JnDQogICAgPj4+IFN1Ympl
Y3Q6IFJlOiBbbmV0bW9kXSBSRkMgNjA4N2JpcyBndWlkYW5jZSByZSB1c2Ugb2YgcmV2aXNpb24N
CiAgICA+Pj5zdGF0ZW1lbnRzIGluZHJhZnRzDQogICAgPj4+ICANCiAgICA+Pj4gQW5keSwNCiAg
ICA+Pj4gIA0KICAgID4+PiBUaGlzIHRocmVhZCBzdGFydGVkIHdpdGggZGlzY3Vzc2lvbiBvZiBh
biBhcHBhcmVudCBhbWJpZ3VpdHkgaW4gdGhlDQogICAgPj4+Y3VycmVudCB0ZXh0Og0KICAgID4+
PiAgDQogICAgPj4+IE9MRA0KICAgID4+PiAgDQogICAgPj4+IEl0IGlzIGFjY2VwdGFibGUgdG8g
cmV1c2UgdGhlIHNhbWUgcmV2aXNpb24gc3RhdGVtZW50IHdpdGhpbg0KICAgID4+PnVucHVibGlz
aGVkIHZlcnNpb25zIChpLmUuLCBJbnRlcm5ldC1EcmFmdHMpLCBidXQgdGhlIHJldmlzaW9uIGRh
dGUNCiAgICA+Pj5NVVNUIGJlIHVwZGF0ZWQgdG8gYSBoaWdoZXIgdmFsdWUgZWFjaCB0aW1lIHRo
ZSBJbnRlcm5ldC1EcmFmdCBpcw0KICAgID4+PnJlLXBvc3RlZC4NCiAgICA+Pj4gIA0KICAgID4+
PiDigJTigJQgDQogICAgPj4+ICANCiAgICA+Pj4gSXQgYmVjYW1lIGNsZWFyIGZyb20gdGhlIHN1
YnNlcXVlbnQgZGlzY3Vzc2lvbiAodGhhbmtzIFJhbmR5ISkgdGhhdA0KICAgID4+PnRoZSBhYm92
ZSB0ZXh0IGlzbuKAmXQgaW50ZW5kZWQgdG8gbWVhbiDigJxyZXVzZSB0aGUgaWRlbnRpY2FsIHJl
dmlzaW9uDQogICAgPj4+c3RhdGVtZW50LCBJTkNMVURJTkcgVEhFIFJFVklTSU9OIERBVEXigJ0g
YnV0IHRvIG1lYW4g4oCccmV1c2UgdGhlIHJldmlzaW9uDQogICAgPj4+c3RhdGVtZW50LCBVUERB
VElORyBUSEUgUkVWSVNJT04gREFUReKAnS4NCiAgICA+Pj4gIA0KICAgID4+PiBUaGVuIG90aGVy
IHBlb3BsZSByYWlzZWQgb3RoZXIgcG9pbnRzLCBlLmcgb25seSB1cGRhdGluZyB0aGUgcmV2aXNp
b24NCiAgICA+Pj5kYXRlIGlmIHRoZSBZQU5HIGhhcyBjaGFuZ2VkLCBkaXN0aW5ndWlzaGluZyBi
ZXR3ZWVuIHRoZSBkb2N1bWVudCBhbmQNCiAgICA+Pj50aGUgWUFORyBjb250YWluZWQgdGhlcmVp
biwgYW5kIGRpc3Rpbmd1aXNoaW5nIGJldHdlZW4gWUFORyBpbiBJRHMgYW5kDQogICAgPj4+WUFO
RyBjcmVhdGVkIGJ5IG90aGVyIFNET3MuIE15IHByb3Bvc2VkIG5ldyB0ZXh0IHRyaWVzIHRvIGFk
ZHJlc3MgYWxsDQogICAgPj4+b2YgdGhlc2U6DQogICAgPj4+ICANCiAgICA+Pj4gTkVXOg0KICAg
ID4+PiANCiAgICA+Pj4gSXQgaXMgbm90IHJlcXVpcmVkIHRvIGtlZXAgdGhlIGZ1bGwgcmV2aXNp
b24gaGlzdG9yeSBvZiBkcmFmdCB2ZXJzaW9ucw0KICAgID4+PihlLmcuLCBtb2R1bGVzIGNvbnRh
aW5lZCB3aXRoaW4gSW50ZXJuZXQtRHJhZnRzKS4gVGhhdCBpcywgd2l0aGluIGENCiAgICA+Pj5z
ZXF1ZW5jZSBvZiBkcmFmdCB2ZXJzaW9ucywgb25seSB0aGUgbW9zdCByZWNlbnQgcmV2aXNpb24g
bmVlZCBiZQ0KICAgID4+PnJlY29yZGVkIGluIHRoZSBtb2R1bGUuIEhvd2V2ZXIsIGlmIHRoZSBt
b2R1bGUgaGFzIGNoYW5nZWQsIHRoZQ0KICAgID4+PnJldmlzaW9uIGRhdGUgb2YgdGhlIG1vc3Qg
cmVjZW50IHJldmlzaW9uIE1VU1QgYmUgdXBkYXRlZCB0byBhIGxhdGVyDQogICAgPj4+ZGF0ZSB3
aGVuZXZlciBhIG5ldyB2ZXJzaW9uIGlzIG1hZGUgYXZhaWxhYmxlIChlLmcuLCB2aWEgYSBuZXcg
dmVyc2lvbg0KICAgID4+Pm9mIGFuIEludGVybmV0LURyYWZ0KS4NCiAgICA+Pj4gIA0KICAgID4+
PiDigJTigJQNCiAgICA+Pj4gIA0KICAgID4+PiBJIGJlbGlldmUgdGhhdCB0aGlzIHJldGFpbnMg
dGhlIG9yaWdpbmFsIGludGVudCBpbiBhIHdheSB0aGF0IHJlc29sdmVzDQogICAgPj4+dGhlIG9y
aWdpbmFsIGFtYmlndWl0eSBhbmQgYWRkcmVzc2VzIHRoZSBvdGhlciBwb2ludHMgdGhhdCB3ZXJl
IHJhaXNlZC4NCiAgICA+Pj5JdCBpdOKAmXMg4oCcd29yc2XigJ0sIGhvdyBpcyBpdCB3b3JzZSAo
YXBhcnQgZnJvbSBiZWluZyBsb25nZXIsIG9uIHdoaWNoDQogICAgPj4+cG9pbnQgbWVhIGN1bHBh
KT8NCiAgICA+Pj4gIA0KICAgID4+PiBUaGFua3MsDQogICAgPj4+IFdpbGxpYW0NCiAgICA+Pj4g
IA0KICAgID4+PiBPbiAxOSBBdWcgMjAxNiwgYXQgMTU6NDIsIEFuZHkgQmllcm1hbiA8YW5keUB5
dW1hd29ya3MuY29tPiB3cm90ZToNCiAgICA+Pj4gIA0KICAgID4+PiBPbiBGcmksIEF1ZyAxOSwg
MjAxNiBhdCA3OjEzIEFNLCBEYWxlIFIuIFdvcmxleSA8d29ybGV5QGFyaWFkbmUuY29tPg0KICAg
ID4+Pndyb3RlOg0KICAgID4+PiBBbmR5IEJpZXJtYW4gPGFuZHlAeXVtYXdvcmtzLmNvbT4gd3Jp
dGVzOg0KICAgID4+PiA+IEFuIEludGVybmV0LURyYWZ0IGlzIE5PVCBhIG1lYW5zIG9mICJwdWJs
aXNoaW5nIiBhIHNwZWNpZmljYXRpb247DQogICAgPj4+IA0KICAgID4+PiBBcyBJIHNhaWQsIHRo
YXQncyB0aGUgdGhlb3J5LCBidXQgcHJhY3RpY2UgaXMgY29uc2lkZXJhYmx5IGRpZmZlcmVudC4N
CiAgICA+Pj4gIA0KICAgID4+PiBBbnlib2R5IHRoYXQgaW1wbGVtZW50cyBhIHdvcmstaW4tcHJv
Z3Jlc3Mga25vd3MgdGhleSBhcmUgdGFraW5nIGEgcmlzaw0KICAgID4+PiBvbiBhbiB1bnN0YWJs
ZSBkb2N1bWVudC4gIFRoZSBndWlkZWxpbmUgYWxyZWFkeSBzYXlzIE1VU1QgdXBkYXRlDQogICAg
Pj4+IHRoZSByZXZpc2lvbiBkYXRlLg0KICAgID4+PiAgDQogICAgPj4+IE5vdCBzdXJlIHdoYXQg
bW9yZSB5b3Ugd2FudCB0byBndWlkZWxpbmVzIGRvY3VtZW50IHRvIGRvLg0KICAgID4+PiAgDQog
ICAgPj4+IERhbGUNCiAgICA+Pj4gIA0KICAgID4+PiBBbmR5DQogICAgPj4gDQogICAgPj4gX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAgICA+PiBuZXRt
b2QgbWFpbGluZyBsaXN0DQogICAgPj4gbmV0bW9kQGlldGYub3JnDQogICAgPj4gaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICA+DQogICAgPi0tDQogICAg
PkxhZGlzbGF2IExob3RrYSwgQ1ouTklDIExhYnMNCiAgICA+UEdQIEtleSBJRDogRTc0RThDMEMN
CiAgICA+DQogICAgPg0KICAgID4NCiAgICA+DQogICAgPl9fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fDQogICAgPm5ldG1vZCBtYWlsaW5nIGxpc3QNCiAgICA+
bmV0bW9kQGlldGYub3JnDQogICAgPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGlu
Zm8vbmV0bW9kDQogICAgDQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCiAgICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgbmV0bW9kQGlldGYub3Jn
DQogICAgaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICAN
Cg0K


From nobody Wed Aug 31 08:53: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 26B1812D57B for ; Wed, 31 Aug 2016 08:53:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.934
X-Spam-Level: 
X-Spam-Status: No, score=-1.934 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_SOFTFAIL=0.665] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZeHtevvr1ZRL for ; Wed, 31 Aug 2016 08:53:41 -0700 (PDT)
Received: from resqmta-ch2-12v.sys.comcast.net (resqmta-ch2-12v.sys.comcast.net [IPv6:2001:558:fe21:29:69:252:207:44]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7FA1012D5CA for ; Wed, 31 Aug 2016 08:44:28 -0700 (PDT)
Received: from resomta-ch2-19v.sys.comcast.net ([69.252.207.115]) by resqmta-ch2-12v.sys.comcast.net with SMTP id f7fKbuaekxBKTf7ghbfNoh; Wed, 31 Aug 2016 15:44:27 +0000
Received: from hobgoblin.ariadne.com ([73.100.16.189]) by resomta-ch2-19v.sys.comcast.net with SMTP id f7ggbsQXrg3APf7ghbxNiL; Wed, 31 Aug 2016 15:44:27 +0000
Received: from hobgoblin.ariadne.com (hobgoblin.ariadne.com [127.0.0.1]) by hobgoblin.ariadne.com (8.14.7/8.14.7) with ESMTP id u7VFiRqn006972; Wed, 31 Aug 2016 11:44:27 -0400
Received: (from worley@localhost) by hobgoblin.ariadne.com (8.14.7/8.14.7/Submit) id u7VFiQLI006969; Wed, 31 Aug 2016 11:44:26 -0400
X-Authentication-Warning: hobgoblin.ariadne.com: worley set sender to worley@alum.mit.edu using -f
From: worley@ariadne.com (Dale R. Worley)
To: "Sterne\, Jason \(Nokia - CA\)" 
In-Reply-To:  (jason.sterne@nokia.com)
Sender: worley@ariadne.com (Dale R. Worley)
Date: Wed, 31 Aug 2016 11:44:26 -0400
Message-ID: <87fupl9c4l.fsf@hobgoblin.ariadne.com>
X-CMAE-Envelope: MS4wfFHEgwu2nSSzmAZILVjTiDXUJ2VWg6qrEEvQA/syrdmoG6jhkjFXo1xNx0gl+p9Fzkpr+GaNmsYtwJrN88bpheq9Cx/ElR4domRf2lNpLG7Wja/nMunf 16h8cmINIWdaN0+wgqzGPhwetqYHX8pzvfwT52t0QXNaa2Yi5iUVJNk84Kaw1yyJkQc3Op3N9295GrnbXQgZQjXPzpAcpBuRmtc=
Archived-At: 
Cc: netmod@ietf.org
Subject: Re: [netmod] Using an empty type in a list key
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 15:53:45 -0000

"Sterne, Jason (Nokia - CA)"  writes:
> I saw the addition of empty types in list keys in YANG 1.1 but had
> troubles finding more details in the NETMOD list.  Is it discussed in
> the YANG 1.1 issues page (and if so, where is that now ?  I tried an
> old link and it didn't work) ?

> Doesn't the empty type have two states and the absence/presence of the
> leaf/tag indicates those states ?

The empty type has two states in the fullest sense, but remember that
missing values are not treated as first-class values.  In particular, if
a leaf is a key for a list, the leaf element must be present in all list
elements:

   7.8.2.  The list's key Statement

   The combined values of all the leafs specified in the key are used to
   uniquely identify a list entry.  All key leafs MUST be given values
   when a list entry is created.  Thus, any default values in the key
   leafs or their types are ignored.  It also implies that any mandatory
   statement in the key leafs are ignored.

So a leaf with empty type can be included in the key, but since it
always has the same value, it has no effect.

Dale


From nobody Wed Aug 31 11:11: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 E32C512D5FB for ; Wed, 31 Aug 2016 11:11:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hrek69wiqPtP for ; Wed, 31 Aug 2016 11:11:20 -0700 (PDT)
Received: from NAM03-DM3-obe.outbound.protection.outlook.com (mail-dm3nam03on0129.outbound.protection.outlook.com [104.47.41.129]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF9D12D624 for ; Wed, 31 Aug 2016 11:11:17 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=5g2F2leczT3NocsfzucH5ICf6ViVKlyK9D7AFKUTEYs=; b=JyQm0eoF8nnbvybjKWZK/pxeaXVZOqC5cN6Ciez2KiGegQ+Nj4B+VE7C0lWjdpM3ddrBWu3JcxnkAvmryEfK6WhkIUhu03DPKABP5Fdv1fujqow+bczbhavlgm1Tq31Pd/K6xPRHCA7k0U64tvzQuI5zNDW8fHha1rk+kKt3Qo8=
Received: from CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) by CY1PR0501MB1450.namprd05.prod.outlook.com (10.160.149.11) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.1.609.3; Wed, 31 Aug 2016 18:11:14 +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.0609.002; Wed, 31 Aug 2016 18:11:14 +0000
From: Kent Watsen 
To: "netmod@ietf.org" 
Thread-Topic: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)
Thread-Index: AQHR/8LivjdTqPfoxUWmbjRsB+ww7aBjI4mA
Date: Wed, 31 Aug 2016 18:11:14 +0000
Message-ID: <4CF2F47E-ABF2-4368-8793-64E81AA02375@juniper.net>
References: <08A2A580-BEA2-4AF0-9FFB-0F995B9DC778@juniper.net>
In-Reply-To: <08A2A580-BEA2-4AF0-9FFB-0F995B9DC778@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.18.0.160709
authentication-results: spf=none (sender IP is ) smtp.mailfrom=kwatsen@juniper.net; 
x-ms-exchange-messagesentrepresentingtype: 1
x-originating-ip: [66.129.241.14]
x-ms-office365-filtering-correlation-id: c35c7a6b-06dd-4c61-7151-08d3d1ca3258
x-microsoft-exchange-diagnostics: 1; CY1PR0501MB1450; 6:40p6o28yzdn2sRjrV0PEiTc6Nd7X5NfLT54wBuaJcPV5rhz5mlpagmXZv5gI4bMQ+JYGiKym2GmPTolFRmATGuDNShElePTjTUHXE+GM2TYrrLwAVV3815IW4Pl6FCH434zdIviYZJ2MJebkjfNZfDPa5sHeWzx+I6r7/YImxIxqephnPemcxXXgrjZk+qKdW6DlL9OdH48tf0zY+nEJoF2kJQFC7nuRBmFPBMEz4DUdrmimogN5wlVvk0scsdru6q3oZczOzb7ZDeYADHP3YWRiuKNgiPQ92Cfn2HbqIEED90JoAFJaDGf020YeBb9I/9b+y7huAaYzu6Gm0YQ0KQ==; 5:7sIquxELI3lhRkHv34nRZfrzJxv3/ag/1KYVMrx8mFFnPKKJqb9HgFqdz4VMXeLzkHUc5caIsExATNSmQOqhoysq+TdUbxohV8RB/oyuXlO2M/yduys9YxbLvind755cf8lRd665dE+IT+9OnhHFXw==; 24:zhpRQ+nfT270u2e4d81UPh1J7zZN18xnNJGZBYIErmBx/E5dJ/Azva4i6jCrrks6hRvEgRuVUlWUT10MrB+WCM1O33ysod/8+M+53awMmbA=; 7:uyD7du0i0QsuGWI51W7IRDuzvI5HLvo1X47dmaKmj3wL2yBy09sr9tSU++Bn4aUyd20+H+HmRg5IFaztYqtU7sdfsajWPhFU8PKrex62tIJeHpktekG8aTHXoRkRYNgdawdzNHN8oPt60jtF9kvO6smdd8tYmXUgNKkNETVkmSLKrYRt+pa3/jeBaVa/25XWRYEr4LBnAT/L3HaSb3J1DVRHflxs9DZg/s1Kz1UHKYZz32Ki/Q8t7uqBIke/ApL+
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR0501MB1450;
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(20558992708506)(138986009662008)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040176)(601004)(2401047)(8121501046)(5005006)(10201501046)(3002001)(6055026); SRVR:CY1PR0501MB1450; BCL:0; PCL:0; RULEID:; SRVR:CY1PR0501MB1450; 
x-forefront-prvs: 00514A2FE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(7916002)(199003)(189002)(377454003)(102836003)(2501003)(86362001)(4001350100001)(81156014)(8936002)(3280700002)(68736007)(3660700001)(11100500001)(7846002)(36756003)(106116001)(106356001)(1730700003)(7736002)(5640700001)(50986999)(2906002)(19625215002)(83716003)(2351001)(6116002)(54356999)(2900100001)(82746002)(76176999)(450100001)(99286002)(105586002)(77096005)(2950100001)(110136002)(15975445007)(101416001)(3846002)(5660300001)(107886002)(189998001)(97736004)(16236675004)(19580395003)(586003)(92566002)(66066001)(230783001)(83506001)(19580405001)(33656002)(81166006)(10400500002)(87936001)(19300405004)(5002640100001)(122556002)(8676002)(104396002); DIR:OUT; SFP:1102; SCL:1; SRVR:CY1PR0501MB1450; H:CY1PR0501MB1450.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_4CF2F47EABF24368879364E81AA02375junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-originalarrivaltime: 31 Aug 2016 18:11:14.6927 (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: 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 31 Aug 2016 18:11:23 -0000

--_000_4CF2F47EABF24368879364E81AA02375junipernet_
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64

W2FzIGEgY29udHJpYnV0b3JdDQoNCk15IG9ubHkgY29tbWVudCBvbiB0aGlzIGRyYWZ0IGlzIHRo
YXQgSeKAmWQgcHJlZmVyIGl0IGlmIHRoZSDigJxyb3V0aW5nLXN0YXRl4oCdIHRyZWUgd2VyZSBt
b3ZlZCBpbnRvIGFub3RoZXIgWUFORyBtb2R1bGUsIHNvIHRoYXQgaXQgY291bGQgYmUgbW9yZSBl
YXNpbHkgZGVwcmVjYXRlZCB3aGVuIHRoZSBvcHN0YXRlIHNvbHV0aW9uIGNvbWVzLiAgIEkgc3Vn
Z2VzdGVkIHRoaXMgYmVmb3JlLCB3aXRoIHJlZ2FyZHMgdG8gcmZjNjA4N2JpcyBTZWN0aW9uIDUu
MjMsIGJ1dCB0aGF0IHRocmVhZCBzZWVtZWQgdG8gaGF2ZSBwZXRlcmVkIG91dCwgYnV0IG5vdyBo
ZXJlIHdlIGFyZSBhbmQgbXkgb3BpbmlvbiByZW1haW5zIHRoZSBzYW1lLg0KDQpUaGFua3MsDQpL
ZW50DQoNCkZyb206IG5ldG1vZCA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv
ZiBLZW50IFdhdHNlbiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4NCkRhdGU6IEZyaWRheSwgQXVndXN0
IDI2LCAyMDE2IGF0IDE6NTQgUE0NClRvOiAibmV0bW9kQGlldGYub3JnIiA8bmV0bW9kQGlldGYu
b3JnPg0KU3ViamVjdDogW25ldG1vZF0gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLW5ldG1v
ZC1yb3V0aW5nLWNmZy0yMyAodW50aWwgU2VwIDksIDIwMTYpDQoNCg0KVGhpcyBpcyBhIG5vdGlj
ZSB0byBzdGFydCBhIHR3by13ZWVrIE5FVE1PRCBXRyBsYXN0IGNhbGwgZm9yIHRoZSBkb2N1bWVu
dDoNCg0KICAgICAgICAgICAgICAgIEEgWUFORyBEYXRhIE1vZGVsIGZvciBSb3V0aW5nIE1hbmFn
ZW1lbnQNCiAgICAgICAgICAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt
aWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMjMNCg0KUGxlYXNlIGluZGljYXRlIHlvdXIgc3VwcG9y
dCBvciBjb25jZXJucyBieSBUaHVyc2RheSBTZXB0ZW1iZXIgOSwgMjAxNi4NCg0KV2UgYXJlIG5v
dCBvbmx5IGludGVyZXN0ZWQgaW4gcmVjZWl2aW5nIGRlZmVjdCByZXBvcnRzLCB3ZSBhcmUgZXF1
YWxseSBpbnRlcmVzdGVkIGluIHN0YXRlbWVudHMgb2YgdGhlIGZvcm06DQoNCiAgKiBJIGhhdmUg
cmV2aWV3ZWQgZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMjMgYW5kIEkgZm91bmQgbm8g
aXNzdWVzDQogICogSSBoYXZlIGltcGxlbWVudGVkIHRoZSBkYXRhIG1vZGVsIGluIGRyYWZ0LWll
dGYtbmV0bW9kLXJvdXRpbmctY2ZnLTIzDQogICogSSBhbSBpbXBsZW1lbnRpbmcgdGhlIGRhdGEg
bW9kZWwgaW4gZHJhZnQtaWV0Zi1uZXRtb2Qtcm91dGluZy1jZmctMjMNCiAgKiBJIGFtIGNvbnNp
ZGVyaW5nIHRvIGltcGxlbWVudCB0aGUgZGF0YSBtb2RlbCBpbiBkcmFmdC1pZXRmLW5ldG1vZC1y
b3V0aW5nLWNmZy0yMw0KDQpPZiBjb3Vyc2UsIHRoZXNlIGFyZSBtZXJlbHkgc3VnZ2VzdGlvbnMs
IGZvbGtzIGNhbiBwcm92aWRlIGNvbW1lbnRzIGluIGFueSBmb3JtIHRoYXQgc3VpdHMgdGhlbS4N
Cg0KDQpUaGFuayB5b3UsDQoNCk5FVE1PRCBXRyBDaGFpcnMNCg0KDQo=

--_000_4CF2F47EABF24368879364E81AA02375junipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0
IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJ
cGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8N
CnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBpbjsN
CgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEyLjBwdDsNCglmb250LWZhbWls
eTpDYWxpYnJpO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXByaW9y
aXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQph
OnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9yaXR5
Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpwLk1z
b1BsYWluVGV4dCwgbGkuTXNvUGxhaW5UZXh0LCBkaXYuTXNvUGxhaW5UZXh0DQoJe21zby1zdHls
ZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoiUGxhaW4gVGV4dCBDaGFyIjsNCgltYXJn
aW46MGluOw0KCW1hcmdpbi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZv
bnQtZmFtaWx5OkNhbGlicmk7fQ0Kc3Bhbi5QbGFpblRleHRDaGFyDQoJe21zby1zdHlsZS1uYW1l
OiJQbGFpbiBUZXh0IENoYXIiOw0KCW1zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUt
bGluazoiUGxhaW4gVGV4dCI7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTt9DQpzcGFuLkVtYWlsU3R5
bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbDsNCglmb250LWZhbWlseTpDYWxpYnJpOw0K
CWNvbG9yOndpbmRvd3RleHQ7fQ0Kc3Bhbi5FbWFpbFN0eWxlMjANCgl7bXNvLXN0eWxlLXR5cGU6
cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCgljb2xvcjp3aW5kb3d0ZXh0
O30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHls
ZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQou
TXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6
MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJn
aW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldv
cmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUi
IGxhbmc9IkVOLVVTIiBsaW5rPSIjMDU2M0MxIiB2bGluaz0iIzk1NEY3MiI+DQo8ZGl2IGNsYXNz
PSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPlthcyBhIGNvbnRyaWJ1dG9yXTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij48bzpwPiZu
YnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjExLjBwdCI+TXkgb25seSBjb21tZW50IG9uIHRoaXMgZHJhZnQgaXMgdGhhdCBJ
4oCZZCBwcmVmZXIgaXQgaWYgdGhlIOKAnHJvdXRpbmctc3RhdGXigJ0gdHJlZSB3ZXJlIG1vdmVk
IGludG8gYW5vdGhlciBZQU5HIG1vZHVsZSwgc28gdGhhdCBpdCBjb3VsZCBiZSBtb3JlIGVhc2ls
eSBkZXByZWNhdGVkIHdoZW4gdGhlIG9wc3RhdGUgc29sdXRpb24gY29tZXMuJm5ic3A7Jm5ic3A7
IEkgc3VnZ2VzdGVkDQogdGhpcyBiZWZvcmUsIHdpdGggcmVnYXJkcyB0byByZmM2MDg3YmlzIFNl
Y3Rpb24gNS4yMywgYnV0IHRoYXQgdGhyZWFkIHNlZW1lZCB0byBoYXZlIHBldGVyZWQgb3V0LCBi
dXQgbm93IGhlcmUgd2UgYXJlIGFuZCBteSBvcGluaW9uIHJlbWFpbnMgdGhlIHNhbWUuPG86cD48
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZToxMS4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij5UaGFua3MsPG86cD48L286cD48
L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9w
Pg0KPGRpdiBzdHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjQjVDNERGIDEuMHB0
O3BhZGRpbmc6My4wcHQgMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNw
YW4gc3R5bGU9ImNvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJjb2xv
cjpibGFjayI+bmV0bW9kICZsdDtuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyZndDsgb24gYmVoYWxm
IG9mIEtlbnQgV2F0c2VuICZsdDtrd2F0c2VuQGp1bmlwZXIubmV0Jmd0Ozxicj4NCjxiPkRhdGU6
IDwvYj5GcmlkYXksIEF1Z3VzdCAyNiwgMjAxNiBhdCAxOjU0IFBNPGJyPg0KPGI+VG86IDwvYj4m
cXVvdDtuZXRtb2RAaWV0Zi5vcmcmcXVvdDsgJmx0O25ldG1vZEBpZXRmLm9yZyZndDs8YnI+DQo8
Yj5TdWJqZWN0OiA8L2I+W25ldG1vZF0gV0cgTGFzdCBDYWxsIGZvciBkcmFmdC1pZXRmLW5ldG1v
ZC1yb3V0aW5nLWNmZy0yMyAodW50aWwgU2VwIDksIDIwMTYpPG86cD48L286cD48L3NwYW4+PC9w
Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OiZxdW90O1RpbWVzIE5ldyBSb21hbiZxdW90OyI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTEuMHB0Ij4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+VGhpcyBp
cyBhIG5vdGljZSB0byBzdGFydCBhIHR3by13ZWVrIE5FVE1PRCBXRyBsYXN0IGNhbGwgZm9yIHRo
ZSBkb2N1bWVudDo8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBBIFlBTkcgRGF0YSBNb2RlbCBmb3IgUm91
dGluZyBNYW5hZ2VtZW50PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtaWV0Zi1uZXRtb2Qt
cm91dGluZy1jZmctMjM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQi
PlBsZWFzZSBpbmRpY2F0ZSB5b3VyIHN1cHBvcnQgb3IgY29uY2VybnMgYnkgVGh1cnNkYXkgU2Vw
dGVtYmVyIDksIDIwMTYuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTEuMHB0
Ij5XZSBhcmUgbm90IG9ubHkgaW50ZXJlc3RlZCBpbiByZWNlaXZpbmcgZGVmZWN0IHJlcG9ydHMs
IHdlIGFyZSBlcXVhbGx5IGludGVyZXN0ZWQgaW4gc3RhdGVtZW50cyBvZiB0aGUgZm9ybTo8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAqIEkgaGF2ZSBy
ZXZpZXdlZCBkcmFmdC1pZXRmLW5ldG1vZC1yb3V0aW5nLWNmZy0yMyBhbmQgSSBmb3VuZCBubyBp
c3N1ZXM8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjExLjBwdCI+Jm5ic3A7ICogSSBoYXZlIGltcGxlbWVudGVkIHRoZSBk
YXRhIG1vZGVsIGluIGRyYWZ0LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTIzPC9zcGFuPjxvOnA+
PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTox
MS4wcHQiPiZuYnNwOyAqIEkgYW0gaW1wbGVtZW50aW5nIHRoZSBkYXRhIG1vZGVsIGluIGRyYWZ0
LWlldGYtbmV0bW9kLXJvdXRpbmctY2ZnLTIzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOyAqIEkg
YW0gY29uc2lkZXJpbmcgdG8gaW1wbGVtZW50IHRoZSBkYXRhIG1vZGVsIGluIGRyYWZ0LWlldGYt
bmV0bW9kLXJvdXRpbmctY2ZnLTIzPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMS4wcHQiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6
MTEuMHB0Ij5PZiBjb3Vyc2UsIHRoZXNlIGFyZSBtZXJlbHkgc3VnZ2VzdGlvbnMsIGZvbGtzIGNh
biBwcm92aWRlIGNvbW1lbnRzIGluIGFueSBmb3JtIHRoYXQgc3VpdHMgdGhlbS48L3NwYW4+PG86
cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjExLjBwdCI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWlu
VGV4dCI+VGhhbmsgeW91LDxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb1BsYWluVGV4dCI+
TkVUTU9EIFdHIENoYWlyczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_4CF2F47EABF24368879364E81AA02375junipernet_--


From nobody Wed Aug 31 11:40: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 99CD512D66C for ; Wed, 31 Aug 2016 11:40:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 2ma34G8pi2jV for ; Wed, 31 Aug 2016 11:40: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 9504E12D669 for ; Wed, 31 Aug 2016 11:40:47 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id CDB3CA45; Wed, 31 Aug 2016 20:40:45 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id VRFk7jD8n4qi; Wed, 31 Aug 2016 20:40:32 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS; Wed, 31 Aug 2016 20:40:44 +0200 (CEST)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id AD306200A5; Wed, 31 Aug 2016 20:40:44 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IKNuwhGgKpmY; Wed, 31 Aug 2016 20:40:43 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0FC8A200A6; Wed, 31 Aug 2016 20:40:43 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id 46DE73C55C1E; Wed, 31 Aug 2016 20:40:41 +0200 (CEST)
Date: Wed, 31 Aug 2016 20:40:40 +0200
From: Juergen Schoenwaelder 
To: Kent Watsen 
Message-ID: <20160831184040.GA4834@elstar.local>
Mail-Followup-To: Kent Watsen , "netmod@ietf.org" 
References: <08A2A580-BEA2-4AF0-9FFB-0F995B9DC778@juniper.net> <4CF2F47E-ABF2-4368-8793-64E81AA02375@juniper.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <4CF2F47E-ABF2-4368-8793-64E81AA02375@juniper.net>
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Cc: "netmod@ietf.org" 
Subject: Re: [netmod] WG Last Call for draft-ietf-netmod-routing-cfg-23 (until Sep 9, 2016)
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, 31 Aug 2016 18:40:49 -0000

On Wed, Aug 31, 2016 at 06:11:14PM +0000, Kent Watsen wrote:
> [as a contributor]
> 
> My only comment on this draft is that I’d prefer it if the “routing-state” tree were moved into another YANG module, so that it could be more easily deprecated when the opstate solution comes.   I suggested this before, with regards to rfc6087bis Section 5.23, but that thread seemed to have petered out, but now here we are and my opinion remains the same.
>

We already have foo:/foo /foo:foo-state modules and while we can now
start a series of foo:/foo and foo-state:/foo-state modules in the
hope that this will eventually 'easier' in the future, it might also
be that we just create more variation and confusion.

/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 Aug 31 18:38: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 1F0A512D7E0; Wed, 31 Aug 2016 18:38:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.17
X-Spam-Level: 
X-Spam-Status: No, score=-103.17 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, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 6AOl3gLho_7v; Wed, 31 Aug 2016 18:38:36 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BD9712D7E8; Wed, 31 Aug 2016 18:37:58 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 13A44B80D1E; Wed, 31 Aug 2016 18:37:58 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20160901013758.13A44B80D1E@rfc-editor.org>
Date: Wed, 31 Aug 2016 18:37:58 -0700 (PDT)
Archived-At: 
Cc: drafts-update-ref@iana.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] RFC 7950 on The YANG 1.1 Data Modeling Language
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 01 Sep 2016 01:38:39 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7950

        Title:      The YANG 1.1 Data Modeling Language 
        Author:     M. Bjorklund, Ed.
        Status:     Standards Track
        Stream:     IETF
        Date:       August 2016
        Mailbox:    mbj@tail-f.com
        Pages:      217
        Characters: 393155
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-netmod-rfc6020bis-14.txt

        URL:        https://www.rfc-editor.org/info/rfc7950

        DOI:        http://dx.doi.org/10.17487/RFC7950

YANG is a data modeling language used to model configuration data,
state data, Remote Procedure Calls, and notifications for network
management protocols.  This document describes the syntax and
semantics of version 1.1 of the YANG language.  YANG version 1.1 is a
maintenance release of the YANG language, addressing ambiguities and
defects in the original specification.  There are a small number of
backward incompatibilities from YANG version 1.  This document also
specifies the YANG mappings to the Network Configuration Protocol
(NETCONF).

This document is a product of the NETCONF Data Modeling Language Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Wed Aug 31 18:38: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 9C38012D7EF; Wed, 31 Aug 2016 18:38:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.17
X-Spam-Level: 
X-Spam-Status: No, score=-103.17 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, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 Gp1dVxRFbPsk; Wed, 31 Aug 2016 18:38:40 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89D0012D80F; Wed, 31 Aug 2016 18:38:14 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 5D1FBB80D21; Wed, 31 Aug 2016 18:38:14 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20160901013814.5D1FBB80D21@rfc-editor.org>
Date: Wed, 31 Aug 2016 18:38:14 -0700 (PDT)
Archived-At: 
Cc: drafts-update-ref@iana.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] RFC 7951 on JSON Encoding of Data Modeled with 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, 01 Sep 2016 01:38:41 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7951

        Title:      JSON Encoding of Data Modeled with YANG 
        Author:     L. Lhotka
        Status:     Standards Track
        Stream:     IETF
        Date:       August 2016
        Mailbox:    lhotka@nic.cz
        Pages:      20
        Characters: 32316
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-netmod-yang-json-10.txt

        URL:        https://www.rfc-editor.org/info/rfc7951

        DOI:        http://dx.doi.org/10.17487/RFC7951

This document defines encoding rules for representing configuration
data, state data, parameters of Remote Procedure Call (RPC)
operations or actions, and notifications defined using YANG as
JavaScript Object Notation (JSON) text.

This document is a product of the NETCONF Data Modeling Language Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Wed Aug 31 18:39: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 ACDFF12D860; Wed, 31 Aug 2016 18:39:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -103.17
X-Spam-Level: 
X-Spam-Status: No, score=-103.17 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, RP_MATCHES_RCVD=-0.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] 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 r6lE7Ep0LVIf; Wed, 31 Aug 2016 18:39:20 -0700 (PDT)
Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11DE512D7E9; Wed, 31 Aug 2016 18:38:33 -0700 (PDT)
Received: by rfc-editor.org (Postfix, from userid 30) id 04802B80D2C; Wed, 31 Aug 2016 18:38:33 -0700 (PDT)
To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org
X-PHP-Originating-Script: 1005:ams_util_lib.php
From: rfc-editor@rfc-editor.org
Message-Id: <20160901013833.04802B80D2C@rfc-editor.org>
Date: Wed, 31 Aug 2016 18:38:33 -0700 (PDT)
Archived-At: 
Cc: drafts-update-ref@iana.org, netmod@ietf.org, rfc-editor@rfc-editor.org
Subject: [netmod] RFC 7952 on Defining and Using Metadata with 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, 01 Sep 2016 01:39:23 -0000

A new Request for Comments is now available in online RFC libraries.

        
        RFC 7952

        Title:      Defining and Using Metadata with YANG 
        Author:     L. Lhotka
        Status:     Standards Track
        Stream:     IETF
        Date:       August 2016
        Mailbox:    lhotka@nic.cz
        Pages:      21
        Characters: 35394
        Updates:    RFC 6110

        I-D Tag:    draft-ietf-netmod-yang-metadata-07.txt

        URL:        https://www.rfc-editor.org/info/rfc7952

        DOI:        http://dx.doi.org/10.17487/RFC7952

This document defines a YANG extension 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.

This document is a product of the NETCONF Data Modeling Language Working Group of the IETF.

This is now a Proposed Standard.

STANDARDS TRACK: This document specifies an Internet Standards Track
protocol for the Internet community, and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Official
Internet Protocol Standards (https://www.rfc-editor.org/standards) for the 
standardization state and status of this protocol.  Distribution of this 
memo is unlimited.

This announcement is sent to the IETF-Announce and rfc-dist lists.
To subscribe or unsubscribe, see
  https://www.ietf.org/mailman/listinfo/ietf-announce
  https://mailman.rfc-editor.org/mailman/listinfo/rfc-dist

For searching the RFC series, see https://www.rfc-editor.org/search
For downloading RFCs, see https://www.rfc-editor.org/retrieve/bulk

Requests for special distribution should be addressed to either the
author of the RFC in question, or to rfc-editor@rfc-editor.org.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.


The RFC Editor Team
Association Management Solutions, LLC



From nobody Wed Aug 31 19:57: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 61CA012B051 for ; Wed, 31 Aug 2016 19:57:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ci9OsGDReoS8 for ; Wed, 31 Aug 2016 19:57:18 -0700 (PDT)
Received: from mail-ua0-x231.google.com (mail-ua0-x231.google.com [IPv6:2607:f8b0:400c:c08::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 2D946126FDC for ; Wed, 31 Aug 2016 19:57:18 -0700 (PDT)
Received: by mail-ua0-x231.google.com with SMTP id m60so122509616uam.3 for ; Wed, 31 Aug 2016 19:57:18 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=EbMBoTXkSLs/xZjkAd6kT7V2UtyIhMEoBbgL2kpAGNU=; b=Z7cmCDibeNLTkylNvRniYx9sVBG29eMbryxLquzrCtbpIFhgf74J/KIxnAdgtXwWSs lmeYsnPbhakE5VO27X920kCP7FORXH2htNN+LGIAYNvrosnD/ldNdM2kcp61YEmH7Lw4 zXyZybg8dYer84WKblsJtzGFxfYZqLJ4WPTbSy9XiSazWjDrkvQPxOIFvpnI5npAvAfi DwPfErrVUvrAN9aolwL8i45+3QXibaQnztO1zFPFUwrl/O3mM/ncZ+8tw1hi/twqPJXk WgSBEPDGObeg8WLgmxbTWU+GRRnSUWwIOrWjJPqujZQ8ohFGryEUSNtPTNyR4H6fJakn p70w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=EbMBoTXkSLs/xZjkAd6kT7V2UtyIhMEoBbgL2kpAGNU=; b=dWYINlQYofJBcbJVpFxlBJlJvBAxwuzrGb1NtjcLmszB3uYoY3G9uu59pwx7OCUoqQ lM5gtGZAyAw8X3HudguCmBEymgzH36clvfon4F2WVK12EfND7gcGlu8TjE2YjVrigjJf IwLDQYD65Uc3C1jsXHgiq+IX5jVVq7eB6y0hEcjXO/0wAki1qH9pJIIGsFSba7IHoKDU GWD7fdzZqZao6k6aPpJNDEJSWLwxAIdw2dnjslca77wscgwKKUYRam+TE9XqKUPOWowc xbw2LAtc7A9hdJLWWCW8aZfkKTuHglMihmXMu385Gchy/mVmO1Cft4kWjSIGl6NXUBsF 9QKA==
X-Gm-Message-State: AE9vXwPESqXkTdxbF5JnGlGDe1tge6mKUMtCLMVhEbF8Ot5YOWoXoCP9yPKrxFEY/Ao8H6cusY2cPZethiZiGA==
X-Received: by 10.176.6.74 with SMTP id f68mr7818780uaf.55.1472698636966; Wed, 31 Aug 2016 19:57:16 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.103.4.134 with HTTP; Wed, 31 Aug 2016 19:57:16 -0700 (PDT)
From: Andy Bierman 
Date: Wed, 31 Aug 2016 19:57:16 -0700
Message-ID: 
To: "netmod@ietf.org" 
Content-Type: multipart/alternative; boundary=94eb2c122e341e4ebd053b695fe7
Archived-At: 
Subject: [netmod] 3 RFCs in 1 day!
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 01 Sep 2016 02:57:19 -0000

--94eb2c122e341e4ebd053b695fe7
Content-Type: text/plain; charset=UTF-8

Hi,

I get to be the first to thank Martin and Lada for all the work
that went into these RFCs. YANG 1.1 is finally done!

Now I hope we start seeing lots of implementations of these RFCs.


Andy

--94eb2c122e341e4ebd053b695fe7
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable


Hi,

I get to be the first to thank Mart=
in and Lada for all the work
that went into these RFCs. YANG 1.1 =
is finally done!

Now I hope we start seeing lots o=
f implementations of these RFCs.


An=
dy






--94eb2c122e341e4ebd053b695fe7--


From nobody Wed Aug 31 22:54: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 61AC912D08F for ; Wed, 31 Aug 2016 22:54:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.748
X-Spam-Level: 
X-Spam-Status: No, score=-4.748 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.548] 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 Tz9equN3NQq4 for ; Wed, 31 Aug 2016 22:54:39 -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 20BB512B01A for ; Wed, 31 Aug 2016 22:54:39 -0700 (PDT)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas3.jacobs-university.de (Postfix) with ESMTP id 9C086102C for ; Thu,  1 Sep 2016 07:54:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas3.jacobs-university.de ([10.70.0.205]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10030) with ESMTP id 6Bl6YyquWOXi for ; Thu,  1 Sep 2016 07:54:22 +0200 (CEST)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas3.jacobs-university.de (Postfix) with ESMTPS for ; Thu,  1 Sep 2016 07:54:37 +0200 (CEST)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 00802200A7 for ; Thu,  1 Sep 2016 07:54:37 +0200 (CEST)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rsXv7ZZu-oN7; Thu,  1 Sep 2016 07:54:36 +0200 (CEST)
Received: from elstar.local (elstar.jacobs.jacobs-university.de [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 020C9200A6; Thu,  1 Sep 2016 07:54:35 +0200 (CEST)
Received: by elstar.local (Postfix, from userid 501) id C435E3C56804; Thu,  1 Sep 2016 07:54:33 +0200 (CEST)
Date: Thu, 1 Sep 2016 07:54:32 +0200
From: Juergen Schoenwaelder 
To: "netmod@ietf.org" 
Message-ID: <20160901055432.GA5626@elstar.local>
Mail-Followup-To: "netmod@ietf.org" 
References: 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: Mutt/1.6.0 (2016-04-01)
Archived-At: 
Subject: Re: [netmod] 3 RFCs in 1 day!
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, 01 Sep 2016 05:54:41 -0000

With the publication of these three RFCs a major milestone has been
reached - a big thank you to Martin and Lada and everybody who
contributed to the development of these specifications over the last
two years. This work involved 1 interim meeting, 22 virtual interim
meetings and the resolution of 60 tracked issues, and countless
messages on the mailing list. Lets have a virtual celebration today!

/js

On Wed, Aug 31, 2016 at 07:57:16PM -0700, Andy Bierman wrote:
> Hi,
> 
> I get to be the first to thank Martin and Lada for all the work
> that went into these RFCs. YANG 1.1 is finally done!
> 
> Now I hope we start seeing lots of implementations of these RFCs.
> 
> 
> Andy

> _______________________________________________
> 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 Wed Aug 31 23:15: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 288D612B026 for ; Wed, 31 Aug 2016 23:15:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.548
X-Spam-Level: 
X-Spam-Status: No, score=-7.548 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.548] 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 oXTX22-KpqJt for ; Wed, 31 Aug 2016 23:15:42 -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 07D6612B032 for ; Wed, 31 Aug 2016 23:15:42 -0700 (PDT)
Received: from [IPv6:2001:718:1a02:1:e555:9862:879b:28de] (unknown [IPv6:2001:718:1a02:1:e555:9862:879b:28de]) by mail.nic.cz (Postfix) with ESMTPSA id 7A56461D22; Thu,  1 Sep 2016 08:15:40 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1472710540; bh=qwuYh+2OfxxFjN5Mp5enp4XWq2vHVUsSLkXOdhTlBjg=; h=From:Date:To; b=AOq5Z71Lok4yK1zckiv9QnK2k9bdtgqOJ8qhl/tdIkA5pFG5Vop0kZpsjxoQxbqCh 62Wk0BvyD9Yabquk506V1Iivw/5v/VdLXtjHgLora9WxT6YJDZo0R6zp4JpNO1E6kB g+iqpmmT/UAVsfQjYkBoKYlCB/xTSCn+i5pP7XBs=
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\))
From: Ladislav Lhotka 
In-Reply-To: 
Date: Thu, 1 Sep 2016 08:15:47 +0200
Content-Transfer-Encoding: quoted-printable
Message-Id: 
References: 
To: Andy Bierman 
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] 3 RFCs in 1 day!
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 01 Sep 2016 06:15:44 -0000

> On 01 Sep 2016, at 04:57, Andy Bierman  wrote:
>=20
> Hi,
>=20
> I get to be the first to thank Martin and Lada for all the work
> that went into these RFCs. YANG 1.1 is finally done!

And big thanks to you and all others who contributed. J=C3=BCrgen also =
did an amazing job in organizing the work on YANG 1.1.

Cheers, Lada

>=20
> Now I hope we start seeing lots of implementations of these RFCs.
>=20
>=20
> Andy
>=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 Wed Aug 31 23:37: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 E44D512D091 for ; Wed, 31 Aug 2016 23:36:58 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.07
X-Spam-Level: 
X-Spam-Status: No, score=-15.07 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.548, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ICYOVUt7odMt for ; Wed, 31 Aug 2016 23:36:57 -0700 (PDT)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 11BB412B037 for ; Wed, 31 Aug 2016 23:36:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=952; q=dns/txt; s=iport; t=1472711817; x=1473921417; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=roZT4jKsFarhea1ddWku7IUKKNG4BSaHF+FDy/21qE0=; b=FBBWMdH8IxzBwMuyydnWANdMBSIeq8h7AR7lKCC1cJRUDuut4QCvXzxA 3TbldnfFpD6bEJptCDuxHjg2Y8FuG+IE4TmhxeeMh/GcTO3kQBch0o60o mykQYh3fyQs86JOwbWZqE4LFVSCO/hFbOL8DM8mq1IY3/ofWdJ/bTUZtW g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AeCwDyy8dX/xbLJq1dg1ABAQEBAXUqU?= =?us-ascii?q?rgoggEkhS5KAoICEwECAQEBAQEBAV4cC4RiAQUBATY2GwsYLicwBg0GAgEBiEQ?= =?us-ascii?q?OunoBAQEBAQEBAwEBAQEBAQEbBYYvgXiCVYocAQSZUI8xiVuFfIh8g0yDeR8BN?= =?us-ascii?q?IQzOjSGbAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.30,265,1470700800"; d="scan'208";a="645822341"
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; 01 Sep 2016 06:36:55 +0000
Received: from [10.60.67.84] (ams-bclaise-8913.cisco.com [10.60.67.84]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id u816asvI003621 for ; Thu, 1 Sep 2016 06:36:55 GMT
To: "netmod@ietf.org" 
References:  <20160901055432.GA5626@elstar.local>
From: Benoit Claise 
Message-ID: 
Date: Thu, 1 Sep 2016 08:36:44 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0
MIME-Version: 1.0
In-Reply-To: <20160901055432.GA5626@elstar.local>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] 3 RFCs in 1 day!
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 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, 01 Sep 2016 06:36:59 -0000

Indeed, great achievement.
Thanks to everybody involved.

Regards, Benoit.
> With the publication of these three RFCs a major milestone has been
> reached - a big thank you to Martin and Lada and everybody who
> contributed to the development of these specifications over the last
> two years. This work involved 1 interim meeting, 22 virtual interim
> meetings and the resolution of 60 tracked issues, and countless
> messages on the mailing list. Lets have a virtual celebration today!
>
> /js
>
> On Wed, Aug 31, 2016 at 07:57:16PM -0700, Andy Bierman wrote:
>> Hi,
>>
>> I get to be the first to thank Martin and Lada for all the work
>> that went into these RFCs. YANG 1.1 is finally done!
>>
>> Now I hope we start seeing lots of implementations of these RFCs.
>>
>>
>> Andy
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>