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 fi