From nobody Thu Feb 1 06:49:45 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C660F12E894; Thu, 1 Feb 2018 06:49:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KecoCKFESYDU; Thu, 1 Feb 2018 06:49:41 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 996CF129511; Thu, 1 Feb 2018 06:49:41 -0800 (PST) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 4D3551AE0118; Thu, 1 Feb 2018 15:49:40 +0100 (CET) Date: Thu, 01 Feb 2018 15:49:39 +0100 (CET) Message-Id: <20180201.154939.1718400022372996691.mbj@tail-f.com> To: stig@venaas.com Cc: rtg-ads@ietf.org, rtg-dir@ietf.org, draft-ietf-netmod-yang-tree-diagrams.all@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] RtgDir review: Review of draft-ietf-netmod-yang-tree-diagrams-05.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 14:49:44 -0000 Hi Stig, Thank you for your review! Comments inline. Stig Venaas wrote: > Hello, > > I have been selected as the Routing Directorate reviewer for this > draft. The Routing Directorate seeks to review all routing or > routing-related drafts as they pass through IETF last call and IESG > review, and sometimes on special request. The purpose of the review is > to provide assistance to the Routing ADs. For more information about > the Routing Directorate, please see > http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir > > Although these comments are primarily for the use of the Routing ADs, > it would be helpful if you could consider them along with any other > IETF Last Call comments that you receive, and strive to resolve them > through discussion or by updating the draft. > > Document: draft-ietf-netmod-yang-tree-diagrams-05.txt > Reviewer: Stig Venaas > Review Date: 2018-01-29 > IETF LC End Date: 2018-02-07 > Intended Status: Best Current Practice > > Summary: > This document is basically ready for publication, but has nits that > should be considered prior to publication. > > Comments: > The draft is well written and ready for publication except for perhaps > two nits. My YANG skills are a bit limited though, so it is possible > that I may have missed issues. > > Major Issues: > No major issues found. > > Minor Issues: > No minor issues found. > > Nits: > In the introduction it says: > Today's common practice is to include the definition of the syntax > used to represent a YANG module in every document that provides a > tree diagram. This practice has several disadvantages and the > purpose of the document is to provide a single location for this > ^^^^ > definition. It is not the intent of this document to restrict future > changes, but rather to ensure such changes are easily identified and > suitably agreed upon. > > It would be better to say "this document". Thanks, fixed in the source! > In section 2 it says: > A module is identified by "module:" followed the module-name. > > In the introduction [RFC7223] Section 3 is given as an example > tree diagram, but this does not start with "module:". Would > another example be better? First of all, the example is legal since the text says: Module trees may be included in a document as a whole, by one or more sections, or even subsets of nodes. I also think the example is fine, since it is in the introduction, and, well, just an example of what current trees look like. > It might also be good to have a > richer example that makes use of most of the defined symbols. I'm not sure what example we would use for this. We believe that the current examples in the document are "good enough". /martin > > Otherwise the document looks great to me. > > Stig > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Feb 1 09:22:21 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 58A5D12EAAD; Thu, 1 Feb 2018 09:22:15 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KqKmYMk_kmU6; Thu, 1 Feb 2018 09:22:12 -0800 (PST) Received: from mail-io0-x232.google.com (mail-io0-x232.google.com [IPv6:2607:f8b0:4001:c06::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 19FB212DA22; Thu, 1 Feb 2018 09:22:12 -0800 (PST) Received: by mail-io0-x232.google.com with SMTP id 72so19951927iom.10; Thu, 01 Feb 2018 09:22:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=9HdgcS2Nm2fbKZ+XJbTq8VQ4WK1/aBgJKZQe7UAuu2k=; b=q9VWKQArm9raAlumYtaJcMpx9zub1kRuTe+puMnTGlQzgVDZPtntm5ER7xx3sITN4o 6YeCVxzyWlT1uxQ/q7x0iGbJ7P2eBj6SdqhapHvJvzAZgQ6dji+ctQA5YVxf1b55091a W8rYtQRN+yKLvQ+KoTIM8zJFXsLV72dekhKkdMDHmLqeyfQjoAL8zhLtiON3m1IS3l1W dWLe3OCouZw9Vq0d5aZw7gYrkThMKX8VtGrQPP+O4FbWzpqjLt2kywNcKLU41a7kU9z7 kEbo3TvMTiCb2rXoYbyCNJIlycYmI4yWPSz/Fu7jYrgnf1dM1ZF8G5bkPizVDFOyE857 YYOw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=9HdgcS2Nm2fbKZ+XJbTq8VQ4WK1/aBgJKZQe7UAuu2k=; b=F8oM/pe5A03lq5WOlA8wInCpDHbZRajA2ct71syVxY2YG78AGIis+g+7Nr2R23/Jp9 sIMjJF1NxXbcZtZqdpMQFJpE43dj9bRbkpp0pNW2jWgtNN/oiVUN83l6JFsTpJMm9DlX YIoH23IETIw3HwxECdZKBG/GIzZ9VsaX8cbKikxwsyRpjsEoGFAKgAoQoqYpVNKJVGNb Ej7+rIDcgQoqr/NIWjLkCntcHpPLi+NVAEgkMo5Z/8Q6Fc0b04NUp+4apDUDDA5gDFkS DgF7r4XudgFRBGUFdeJ6ONZ9gXIqqvU4l2VO2LOJxVjwLrss1wYMa5xfonL/cnJJUizc Imlg== X-Gm-Message-State: AKwxyteFjwk4iH+4MUsb/y1brIBRxXUkvojJXLGOmSdOIUBKo5DIy/Vy j/NKpnQt45fiMKz1TdX3EXZfL9QlaBE= X-Google-Smtp-Source: AH8x2261gfWTr0E5QXjN4FtOkArx5Qk7jVXNjc5iQtByjGX5KsIBPAnrlrsX2Hm8sndWI+FCHwwC8w== X-Received: by 10.107.17.27 with SMTP id z27mr41053420ioi.254.1517505730978; Thu, 01 Feb 2018 09:22:10 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:5073:6ca:e0f4:a48e]) by smtp.gmail.com with ESMTPSA id d65sm215092itd.19.2018.02.01.09.22.08 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 09:22:09 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_051BDD45-D990-4921-95E0-4765A5CD7F43" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 1 Feb 2018 09:22:07 -0800 In-Reply-To: <20180131181619.ziqdv5peqdeeuhl4@elstar.local> Cc: NETMOD Working Group To: netconf References: <20180131081118.uqxivaxbkbbzzmji@elstar.local> <7634f6d2-2bac-cacb-10af-474b7ced5db4@cisco.com> <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com> <20180131181619.ziqdv5peqdeeuhl4@elstar.local> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 17:22:15 -0000 --Apple-Mail=_051BDD45-D990-4921-95E0-4765A5CD7F43 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 This closes the LC for the two NDMA drafts for NETCONF and RESTCONF. As part of the LC, there were a couple of comments/questions raised. In = particular - Vladmir reported an error, which Martin said is fixed in his local = copy. - Robert suggested that =E2=80=9C/yang-library/checksum=E2=80=9D should = be a reference. Juergen supported that comment, so I am assuming that = that will be incorporated into the draft. - Andy had questions around datastore set to =E2=80=9Cconventional=E2=80=9D= , about origin filter limited to 1 source and the behavior of = with-defaults. I see some discussion around it with the authors agreeing = that some of them need some text clarifying the position. Can the = authors please post the suggested text/additions for the WG to review. - Anything else?? Once an updated draft has been posted, I will do a writeup on the drafts = and send it to IESG.=20 Thanks. > On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder = wrote: >=20 > On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote: >>=20 >> I do have one additional thought below on = draft-ietf-netmod-revised-datastores section 5.3 default handling = process. See in-line... >>=20 >=20 > Well, this document is with the RFC editor now. I do not think it = needs > clarification. It already has text in 5.3 such as: >=20 > Requests to retrieve nodes from always return the = value > in use if the node exists, regardless of any default value specified > in the YANG module. If no value is returned for a given node, then > this implies that the node is not used by the device. >=20 > /js >=20 >> From: Robert Wilton -X, January 31, 2018 6:31 AM >>=20 >>=20 >> Hi Andy, >>=20 >> On 31/01/2018 09:22, Andy Bierman wrote: >>=20 >>=20 >> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder = >> wrote: >> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: >>> Hi, >>>=20 >>> I have some questions about these drafts. >>>=20 >>> 1) what if datastore set to "conventional"? >>> There are many places where a datastore-ref type is used. >>> However, "conventional" is valid for base "datastore", even = though >>> it is ambiguous as a datastore selector. >>=20 >> We can add explicit text that an identity that does not resolve to a >> datastore implemented by the server results in an invalid value = error. >>=20 >>=20 >> OK >>=20 >>=20 >>> 2) origin filter is limited to 1 source >>> This filtering seems rather limited. A client must retrieve >>> and check >>> all the values in use, then make repeated requests for each = source as a >>> different >>> leaf >>=20 >> If the client does , then it has all origin information >> and it can filter locally. That said, we could make origin-filter a >> leaf-list which is logically ORed so that one can retrieve >> origin-filter=3Dor:system or origin-filter=3Dor:learned in one = request. >>=20 >>=20 >> OK >>=20 >>> 3) with-defaults broken >>> The operational datastore does not support with-defaults. >>> Instead, the client must use origin-filter=3Dor:default or = with-origin >>> and check all the origin attributes. Since a client needs to = use >>> with-defaults for other datastores, this special handling of >>> >>> seems unhelpful. >>=20 >> I think the with-defaults semantics for conventional configuration >> datastores are much more complicated than necessary for the >> operational state datastore. Note that that the operational state >> datastore reports in-use values not really defaults: >>=20 >> foo >>=20 >> This reports that the value 'foo' is in use and that it originates >> from a default value. Note that this could also be >>=20 >> foo >>=20 >> in case the intended configuration datastore configured the value >> 'foo' (despite this value matching the default). The with-defaults >> solution is pretty complex because it tries to handle how different >> systems deal with configuration defaults. The idea is to not carry >> this complexity over to in-use values in the operational state >> datastore. >>=20 >>=20 >> Before NMDA, the client could decide if it wanted to retrieve default = nodes or not. >> This client-choice has been removed from NMDA, which is a problem. >> We tried to reach a sensible compromise on the data returned from = operational (defined in section 5.3 of the NMDA architecture): >> - it should return explicit values for everything that is affecting = the actual running state of the device (regardless of whether the = operational value matches a schema default value). >> - it does not need to, and should not, return operational values for = stuff that isn't actually in use, i.e. don't return needless and = unwanted data. >>=20 >> In particular, if no value is returned from a particular data node in = then, barring mgmt protocol errors, a client can assume = that any functionality associated with that data node is off (i.e. not = in use). >>=20 >> Some examples to illustrate the behavior: >>=20 >> (i) If a protocol, e.g. OSPF, is not enabled/running then = does not need to return any data for it. It would be = reasonable to return a flag to indicate that OSPF is not = enabled/running. >>=20 >> (ii) If you have some funky widget on an interface that defaults to = being off and isn't being used then don't need to return = any data for it. >>=20 >> (iii) But, if you have some funky widget on an interface that = defaults to being on, then the server should return data for it. If it = is actually enabled, then it would indicate that it is on and return any = associated values with its operational state, or if it is disabled then = it should explicitly report that it is off. >>=20 >> (iv) I would regard that all applied configuration is "in use" by the = system, even if it matches the default value, and hence it should be = reported. >>=20 >>=20 >> This behavior for is obviously slightly different from = the existing with-default handling that is supported for configuration = datastores. As I recall, there were a couple of reasons that we decided = to have a different behavior for : >> (a) to have consistent semantics for all servers, rather than = different servers supporting different with-defaults behaviors (which = makes life harder for clients because they must cope with all variants). >> (b) to remove any potential ambiguity if data isn't returned. I.e. = with the existing with-defaults semantics it is not clear to me that = servers will always return an explicit value to indicate that a = particular widget is off if the schema defines that the default it that = is enabled. If the server doesn't support a given widget at all, it is = quite plausible that it will just return no data for it. In theory = features/deviations should handle this, but those don't work so well if = different linecards have different capabilities. Hence being explicit = about stuff that is in use seems more robust. >>=20 >> These are good examples. It would be great if section 5.3 = could be tweaked to make clearer the relationship between running = datastore defaults and other operational datastore defaults for the same = tree. >>=20 >> For example, let=E2=80=99s say I create a configured subscription, = and the default transport protocol is NETCONF. NETCONF will be used for = that subscription even though the node might not be populated. In this = case, the object would not appear in the running datastore, but MUST* = appear in the operational datastore with the default origin (as it is = in-use). >>=20 >> This to me is the desired behavior as it doesn=E2=80=99t incorrectly = add information to the running datastore, but shows what is in-use = within operational. I suspect other such relationships for other = operational tree defaults could be asserted, perhaps based on the = origin. >>=20 >> (* Maybe =E2=80=98MUST eventually=E2=80=99, as obviously there is a = temporal relationship between the two datastores.) >>=20 >> Eric >>=20 >> Thanks, >> Rob >>=20 >>=20 >>=20 >>=20 >>=20 >>=20 >> /js >>=20 >> Andy >>=20 >> -- >> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | = Germany >> Fax: +49 421 200 3103 >>=20 >>=20 >>=20 >>=20 >>=20 >> _______________________________________________ >>=20 >> netmod mailing list >>=20 >> netmod@ietf.org > >>=20 >> https://www.ietf.org/mailman/listinfo/netmod = >>=20 >=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod = >=20 >=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 = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_051BDD45-D990-4921-95E0-4765A5CD7F43 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8
This closes the LC for the = two NDMA drafts for NETCONF and RESTCONF.

As part of the LC, there were a couple = of comments/questions raised. In particular

- Vladmir reported an error, which = Martin said is fixed in his local copy.
- Robert = suggested that =E2=80=9C/yang-library/checksum=E2=80=9D should be a = reference. Juergen supported that comment, so I am assuming that that = will be incorporated into the draft.
- Andy had = questions around datastore set to =E2=80=9Cconventional=E2=80=9D, about = origin filter limited to 1 source and the behavior of with-defaults. I = see some discussion around it with the authors agreeing that some of = them need some text clarifying the position. Can the authors please post = the suggested text/additions for the WG to review.
- = Anything else??

Once an updated draft has been posted, I will do a writeup on = the drafts and send it to IESG. 

Thanks.

On Jan = 31, 2018, at 10:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:

On Wed, Jan 31, 2018 at = 04:53:48PM +0000, Eric Voit (evoit) wrote:

I do have one = additional thought below on draft-ietf-netmod-revised-datastores section = 5.3 default handling process.  See in-line...


Well, this document is with the RFC = editor now. I do not think it needs
clarification. It already has = text in 5.3 such as:

  Requests to retrieve nodes from = <operational> always return the value
  in use if the node exists, = regardless of any default value specified
  in the YANG module. =  If no value is returned for a given node, then
  this implies that the node is not = used by the device.

/js

From: Robert Wilton -X, = January 31, 2018 6:31 AM


Hi = Andy,

On 31/01/2018 09:22, Andy Bierman = wrote:


On Wed, Jan 31, 2018 = at 12:11 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de<mailto:j.schoenwaelder@jacobs-university.de>> = wrote:
On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy = Bierman wrote:
Hi,

I have some questions about these drafts.

1) what if datastore set to "conventional"?
   There are many places where a datastore-ref = type is used.
   However, "conventional" is = valid for base "datastore", even though
   it= is ambiguous as a datastore selector.

We can add explicit text that an identity that does not = resolve to a
datastore implemented by the server results = in an invalid value error.


OK


2) origin filter is limited to 1 source
  This filtering seems rather limited.  A = client must retrieve
<with-origin> and check
   all the values in use, then make repeated = requests for each source as a
different
   <origin-filter> leaf

If the client does = <with-origin>, then it has all origin information
and = it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=3Dor:system or origin-filter=3Dor:learned in = one request.


OK

3) = with-defaults broken
   The operational = datastore does not support with-defaults.
    Instead, the client must use = origin-filter=3Dor:default or with-origin
    and check all the origin attributes. =  Since a client needs to use
    with-defaults for other datastores, = this special handling of
<operational>
    seems unhelpful.

I think the with-defaults = semantics for conventional configuration
datastores are = much more complicated than necessary for the
operational = state datastore. Note that that the operational state
datastore reports in-use values not really defaults:

 <leaf = or:origin=3D'default'>foo</leaf>

This reports that the value 'foo' is in use and that it = originates
from a default value. Note that this could also = be

 <leaf = or:origin=3D'intended'>foo</leaf>

in= case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The = with-defaults
solution is pretty complex because it tries = to handle how different
systems deal with configuration = defaults. The idea is to not carry
this complexity over to = in-use values in the operational state
datastore.


Before NMDA, the client could = decide if it wanted to retrieve default nodes or not.
This = client-choice has been removed from NMDA, which is a problem.
We tried to reach a sensible compromise on the data returned = from operational (defined in section 5.3 of the NMDA architecture):
- it should return explicit values for everything that is = affecting the actual running state of the device (regardless of whether = the operational value matches a schema default value).
- = it does not need to, and should not, return operational values for stuff = that isn't actually in use, i.e. don't return needless and unwanted = data.

In particular, if no value is = returned from a particular data node in <operational> then, = barring mgmt protocol errors, a client can assume that any functionality = associated with that data node is off (i.e. not in use).
Some examples to illustrate the behavior:

(i) If a protocol, e.g. OSPF,  is not enabled/running = then <operational> does not need to return any data for it. =  It would be reasonable to return a flag to indicate that OSPF is = not enabled/running.

(ii) If you have some = funky widget on an interface that defaults to being off and isn't being = used then <operational> don't need to return any data for it.

(iii) But, if you have some funky widget on an = interface that defaults to being on, then the server should return data = for it. If it is actually enabled, then it would indicate that it is on = and return any associated values with its operational state, or if it is = disabled then it should explicitly report that it is off.

(iv) I would regard that all applied = configuration is "in use" by the system, even if it matches the default = value, and hence it should be reported.


This behavior for <operational> is obviously slightly = different from the existing with-default handling that is supported for = configuration datastores.  As I recall, there were a couple of = reasons that we decided to have a different behavior for = <operational>:
(a) to have consistent semantics for = all servers, rather than different servers supporting different = with-defaults behaviors (which makes life harder for clients because = they must cope with all variants).
(b) to remove any = potential ambiguity if data isn't returned.  I.e. with the existing = with-defaults semantics it is not clear to me that servers will always = return an explicit value to indicate that a particular widget is off if = the schema defines that the default it that is enabled.  If the = server doesn't support a given widget at all, it is quite plausible that = it will just return no data for it.  In theory features/deviations = should handle this, but those don't work so well if different linecards = have different capabilities.  Hence being explicit about stuff that = is in use seems more robust.

<eric> = These are good examples.  It would be great if section 5.3 could be = tweaked to make clearer the relationship between running datastore = defaults and other operational datastore defaults for the same tree.

For example, let=E2=80=99s say I create a = configured subscription, and the default transport protocol is NETCONF. =  NETCONF will be used for that subscription even though the node = might not be populated.  In this case, the object would not appear = in the running datastore, but MUST* appear in the operational datastore = with the default origin (as it is in-use).

This to me is the desired behavior as it doesn=E2=80=99t = incorrectly add information to the running datastore, but shows what is = in-use within operational.   I suspect other such = relationships for other operational tree defaults could be asserted, = perhaps based on the origin.

(* Maybe = =E2=80=98MUST eventually=E2=80=99, as obviously there is a temporal = relationship between the two datastores.)

Eric

Thanks,
Rob





/js

Andy

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





_______________________________________________

netmod mailing list

netmod@ietf.org<mailto:netmod@ietf.org>

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


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


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

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_051BDD45-D990-4921-95E0-4765A5CD7F43-- From nobody Thu Feb 1 09:30:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 22881126FDC for ; Thu, 1 Feb 2018 09:30:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c5KfYwmveAV5 for ; Thu, 1 Feb 2018 09:30:51 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 467C912EBA4 for ; Thu, 1 Feb 2018 09:30:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2436; q=dns/txt; s=iport; t=1517506250; x=1518715850; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=+S6gG98vQjLNA+amkdctcP+2MCk6K0x329/ROWp1Q3A=; b=QsNunFhOvTGjBiEgTtMoh0v+pj0uBkQ+vqTc3w8MRQYwIRIaa1RYCF52 x571ikCvZ0xzpkAyabHkhJeN54fXjrJJotgnPxblnz7xiiwGMTUtGTTgO /+9S4jO9o6tRHobFaGABb/lG70Ld+Tx4Sr4HT2LHuCOfSAIE1LNY+J8Pp Y=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DGAQBCTnNa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodSiDYIsYjxMnl12CAgcDGAuESU8CgwkUAQEBAQEBAQECayi?= =?us-ascii?q?FJAEBAQMBASFLGwsOCioCAicwBgEMBgIBAYoxEKtXgieKZAEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAREKBYRphVQpDIJ5gy8BAQKBPAESAYM2gmUFpCOEYoIyjlqCHoYjg3G?= =?us-ascii?q?Hf5drgTw2ImBwMxoIGxU9giqEeEA3ig2CPAEBAQ?= X-IronPort-AV: E=Sophos; i="5.46,444,1511827200"; d="asc'?scan'208"; a="1746128" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Feb 2018 17:30:48 +0000 Received: from [10.61.243.57] ([10.61.243.57]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w11HUlP5009991; Thu, 1 Feb 2018 17:30:48 GMT To: Kent Watsen , "netmod@ietf.org" References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> From: Eliot Lear Message-ID: <65ce196a-6c12-5f96-6204-989d09a2051b@cisco.com> Date: Thu, 1 Feb 2018 18:30:45 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wMQMoOX4EvLKvAG2Suolp3BF4QIVvKNFB" Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 17:30:55 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --wMQMoOX4EvLKvAG2Suolp3BF4QIVvKNFB Content-Type: multipart/mixed; boundary="fbPrvp7kg09jeXKqrH2lvr1nkqerLIXqt"; protected-headers="v1" From: Eliot Lear To: Kent Watsen , "netmod@ietf.org" Message-ID: <65ce196a-6c12-5f96-6204-989d09a2051b@cisco.com> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> In-Reply-To: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> --fbPrvp7kg09jeXKqrH2lvr1nkqerLIXqt Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Kent, In the Department of Moving Things Along, I think I counted two comments that Mahesh addressed during WGLC.=C2=A0 What are next steps? Eliot On 17.01.18 22:55, Kent Watsen wrote: > All, > > This starts a two-week working group last call on > draft-ietf-netmod-acl-model-15. > > This working group last call ends on January 31st. > Please send your comments to the NETMOD mailing list. > > Positive comments, e.g., "I've reviewed this document > and believe it is ready for publication", are welcome! > This is useful and important, even from authors. > > Also, could the authors, explicitly CC-ed on this email, > please confirm at this time that they are unaware of > any IPR related to this draft. > > Thank you, > NETMOD Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > --fbPrvp7kg09jeXKqrH2lvr1nkqerLIXqt-- --wMQMoOX4EvLKvAG2Suolp3BF4QIVvKNFB Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlpzTsUACgkQh7ZrRtnS ejPK9Qf/dboXvfxEPcRsjalW2lIb2jZOxPZ6HKrtO6ht/ReZE3MOeGYFou3iGz3M qkBk5zqxqzXYLQ3gDTsc7TeeXNWIlx2CnotnT8V3rWzNWoO3XXpBEPy4P2OkPSJm 17YVEjtLcNfEe2XwHZHUepiX9e/ivPF8syRXOtBjup7rim4Q3UgeFA83ks5PRgK0 FXnWY71UNqvv9EdhsEd6P1PF9bhG4i0nJplnEThMXZYP8sE5Tn44aD/TmGn3t1Za +DpcKA9dYjrmdGa6cem/XETU+IiXCZ9erctbv9OYkSLH87n6DPoYnXixO2FnXGnA uTvLftv9ZEn+Gco4s7rX9R+FdBDgdg== =XHo7 -----END PGP SIGNATURE----- --wMQMoOX4EvLKvAG2Suolp3BF4QIVvKNFB-- From nobody Thu Feb 1 10:59:59 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2D2B12D574; Thu, 1 Feb 2018 10:59:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WMFjhV8NHpmX; Thu, 1 Feb 2018 10:59:50 -0800 (PST) Received: from mail-io0-x234.google.com (mail-io0-x234.google.com [IPv6:2607:f8b0:4001:c06::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 B092F12AAB6; Thu, 1 Feb 2018 10:59:50 -0800 (PST) Received: by mail-io0-x234.google.com with SMTP id 72so20268724iom.10; Thu, 01 Feb 2018 10:59:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:mime-version:subject:message-id:date:cc:to; bh=z3UZLTM8lbe7TQhVjSH+1EUULgzLpVbc3DxPjI8fOiM=; b=Z2H+BPdu1uAD8BQT4CvfwWGl9z2Bo2zp8rBqILz6iKZU6Qk4pvmFITO1uv4FabnUrU Afz4fOrhzL0pmVbxvxxx3vrVx/d//jjeQkF0PnqAIbW1f3vfqlVAdKWK0mW45f2aEj9Y POWfb2H4ItTsnLFSk9WgX/AyQfgU6LlPsiZE3pgKtrMxSNw5chpbumYvZMDg8yoJ0dU6 ZLprblAKOIN+9vHV8PBwBv9CEmukXgmkzHvAfPP6U+lfqpJCRHSWgReV6GpVUuUL0R1w SNjWy/672VjoXbth7UI2TXe5yg+ExnYEmPCFxpEx1bF9gQXHvSnqYb5qCn00hR/fBdJC BL4g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:mime-version:subject:message-id:date:cc:to; bh=z3UZLTM8lbe7TQhVjSH+1EUULgzLpVbc3DxPjI8fOiM=; b=CjxR9ZAz96sEhDsqZD0ENoqagvuFWKNI7QT/LUNWmZgWAUGye249p0hXRRRRYGbrNe wetacin0zq4/O6n2B8wHZXBA5I3l86hyu85OuuqVcj5zk2z6z8qpY4I8z0TJI12lckPl wwLyLFBj7XEYF30z0EwBOS4ygCbtCi9zu0PwkVAn9mE8TKfCFd3JXNDOQkLS57Ux6Uuo 5p3/yJ9nH3tRjin+ZiKofI7iIvcTVAlHLhCE4MbQVVGm1qNINliBmNOQuGIRPrMmBOwn x4f7w8RvMRDSqrgWHaEBjvWcVYx63HxKQRFbjcOe+0tWsZvLHprMt4OW4NWud+veVzH8 46uw== X-Gm-Message-State: AKwxytepFRCKfDTAtNnUgbdaWET8Q1sUCw8+qAqH6IQLyGfT0hCZFZ3i jh0GUlmz4S5p2IkxMXx88Tj3UhEWKcI= X-Google-Smtp-Source: AH8x227+srafh5uqOial7Xcj1f4a52duXvRrsFfLExMTYAyIPeZB5MJS7/1N7D7xysWEW5LjALTk3Q== X-Received: by 10.107.12.36 with SMTP id w36mr40354150ioi.132.1517511589947; Thu, 01 Feb 2018 10:59:49 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:58b4:2eaa:9592:1df1]) by smtp.gmail.com with ESMTPSA id u32sm124844ioi.29.2018.02.01.10.59.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 01 Feb 2018 10:59:49 -0800 (PST) From: Mahesh Jethanandani Content-Type: multipart/alternative; boundary="Apple-Mail=_9CA80D59-9712-4083-9E1C-6CCD09E25496" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Message-Id: Date: Thu, 1 Feb 2018 10:59:47 -0800 Cc: NETMOD WG To: NETCONF WG X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: [netmod] LC on YANG Library (bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 18:59:53 -0000 --Apple-Mail=_9CA80D59-9712-4083-9E1C-6CCD09E25496 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=us-ascii WG, The authors of rfc7895bis have indicated that they believe the document = is ready for LC[1]. This starts a two week LC on the draft = . The LC = will end on February 15.=20 Please send your comments on this thread. Reviews of the document, and = statement of support are particularly helpful to the authors. If you = have concerns about the document, please state those too. Authors please indicate if you are aware of any IPR on the document. Thanks. [1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html = Mahesh & Kent --Apple-Mail=_9CA80D59-9712-4083-9E1C-6CCD09E25496 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=us-ascii WG,

The = authors of rfc7895bis have indicated that they believe the document is = ready for LC[1].

This starts a two week LC on the draft. The LC will end on February 15. 

Please send your = comments on this thread. Reviews of the document, and statement of = support are particularly helpful to the authors. If you have concerns = about the document, please state those too.

Authors please indicate if you are = aware of any IPR on the document.

Thanks.

[1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.= html

Mahesh & Kent

= --Apple-Mail=_9CA80D59-9712-4083-9E1C-6CCD09E25496-- From nobody Thu Feb 1 11:42:43 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A871612EC87; Thu, 1 Feb 2018 11:42:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8uehfpdJOZRp; Thu, 1 Feb 2018 11:42:34 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D13B12EC3A; Thu, 1 Feb 2018 11:42:34 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 0AA35679; Thu, 1 Feb 2018 20:42:33 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id A56l3eeqWADA; Thu, 1 Feb 2018 20:42:31 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 1 Feb 2018 20:42:32 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8E4920153; Thu, 1 Feb 2018 20:42:32 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id juAOV3Tkj5cd; Thu, 1 Feb 2018 20:42:32 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 366C820152; Thu, 1 Feb 2018 20:42:32 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AD3C2423492F; Thu, 1 Feb 2018 20:42:31 +0100 (CET) Date: Thu, 1 Feb 2018 20:42:31 +0100 From: Juergen Schoenwaelder To: Mahesh Jethanandani Cc: NETCONF WG , NETMOD WG Message-ID: <20180201194231.witzh5vs5jra675w@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Mahesh Jethanandani , NETCONF WG , NETMOD WG References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] [Netconf] LC on YANG Library (bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 19:42:37 -0000 On Thu, Feb 01, 2018 at 10:59:47AM -0800, Mahesh Jethanandani wrote: > > Authors please indicate if you are aware of any IPR on the document. > I am not. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 1 11:56:19 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C237B124BFA; Thu, 1 Feb 2018 11:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3z4wA47rKGs7; Thu, 1 Feb 2018 11:56:12 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C47781243F3; Thu, 1 Feb 2018 11:56:11 -0800 (PST) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 71E051AE0118; Thu, 1 Feb 2018 20:56:10 +0100 (CET) Date: Thu, 01 Feb 2018 20:56:10 +0100 (CET) Message-Id: <20180201.205610.306855531844685397.mbj@tail-f.com> To: mjethanandani@gmail.com Cc: netconf@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] [Netconf] LC on YANG Library (bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 19:56:14 -0000 Mahesh Jethanandani wrote: > WG, > > The authors of rfc7895bis have indicated that they believe the > document is ready for LC[1]. > > This starts a two week LC on the draft > . The LC > will end on February 15. > > Please send your comments on this thread. Reviews of the document, and > statement of support are particularly helpful to the authors. If you > have concerns about the document, please state those too. > > Authors please indicate if you are aware of any IPR on the document. I am not aware of any IPR related to this document. /martin From nobody Thu Feb 1 12:18:29 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1E0BC12D84E for ; Thu, 1 Feb 2018 12:18:24 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4gT9xC4uhsQK for ; Thu, 1 Feb 2018 12:18:22 -0800 (PST) Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 CA67D12D77B for ; Thu, 1 Feb 2018 12:18:21 -0800 (PST) Received: by mail-lf0-x235.google.com with SMTP id t79so28155037lfe.3 for ; Thu, 01 Feb 2018 12:18:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=1125Szwkfxw1uenPwmyhyY1RebZAGBMUEEE9kOjeZIU=; b=OwwXg6JQO+3HgS2f/gw1VhUuTgt+nVXPyd6XDs4dEa8kjvVJE4svob+GHK+MDkuQnc HgYD07zuJo7lTSDaYRSyv4JRxl9zi/2m1odlSlqiRrgLhLb0NzI+CqZZpVMjUHp/Ftdh zooozUUq0xTDqL0nBjpLnJbFWYaw6viVqqd5CPT2wujS1bhEfDrbifqUoN3xTmDTTkN1 4rlmBRuabaH4SxBQsYP4EWp2UzO10OzDbXRBWjgGJelic11sq4rcXbJ5TuH4EP+NEe9I fcZufNs9bQ4t1MCziafQw1jQm18LHjp+Pc0maZ7XQWSuBgHIsYScMYxlgyOckp0w2kFG a1xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=1125Szwkfxw1uenPwmyhyY1RebZAGBMUEEE9kOjeZIU=; b=fw9l0OUjKsvKWN7b1YcQznEqsxYwVDec0G0k1fWcqpbD5aMAXR+dYb8ZEcwyZ6tNV9 9KVSzZBOVOVO8vURXl6H8UdPbsPcUiyf7wK/j8+8FaeYurno7Ttj3luxMPkYqaQglRjN TNAUgQsdwxB5HDEM5xs3A9Nm0JRJgJ7sD/YYjFdrAXV+j6WN8UKfaLcSefAM6PSl/SNM 0fEk2Eie+IHPuWOYwxvtHghAnwvxQzuQ4D3bSNTlkFOXvhvDQPoc4sgVcgiJF4sUtFd0 ERIlhOixz1mobmIa3ZL8yHjCNePsSAjIQ5AMmhH9HQsrI/l7JteCVl43QiRnkL5NtOSk /zxw== X-Gm-Message-State: AKwxytcTEhfNTTcN9LCZ6XhhDSU64+bftyjkb6Ee0JfQrCJDRr9momoz XvRDbesGmwZKX7kclclYdqamZWU27jlBS6KiBpZLEA== X-Google-Smtp-Source: AH8x227YGH9jBWPblThHV8my7sQKWChH7muJJ1nvMMXbtZOVKFiZDynYQ5vLphdTp/VEFltINe2Hrevu5K3twWDHzLg= X-Received: by 10.25.228.13 with SMTP id b13mr23280538lfh.61.1517516300015; Thu, 01 Feb 2018 12:18:20 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.143.6 with HTTP; Thu, 1 Feb 2018 12:18:19 -0800 (PST) In-Reply-To: References: From: Andy Bierman Date: Thu, 1 Feb 2018 12:18:19 -0800 Message-ID: To: Mahesh Jethanandani Cc: NETCONF WG , NETMOD WG Content-Type: multipart/alternative; boundary="94eb2c0d905000f18805642c4c8b" Archived-At: Subject: Re: [netmod] [Netconf] LC on YANG Library (bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 01 Feb 2018 20:18:24 -0000 --94eb2c0d905000f18805642c4c8b Content-Type: text/plain; charset="UTF-8" On Thu, Feb 1, 2018 at 10:59 AM, Mahesh Jethanandani < mjethanandani@gmail.com> wrote: > WG, > > The authors of rfc7895bis have indicated that they believe the document is > ready for LC[1]. > > This starts a two week LC on the draft > . The LC > will end on February 15. > > Please send your comments on this thread. Reviews of the document, and > statement of support are particularly helpful to the authors. If you have > concerns about the document, please state those too. > > Authors please indicate if you are aware of any IPR on the document. > > I am not aware of any IPR related to this document. > Thanks. > > [1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html > > Mahesh & Kent > > Andy > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > --94eb2c0d905000f18805642c4c8b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 1, 2018 at 10:59 AM, Mahesh Jethanandani = <mjethanand= ani@gmail.com> wrote:
WG,

Th= e authors of rfc7895bis have indicated that they believe the document is re= ady for LC[1].

This starts a two week LC on the=C2= =A0draft. The LC will end on February 15.=C2=A0

Please send your comments on this thread. Reviews of the = document, and statement of support are particularly helpful to the authors.= If you have concerns about the document, please state those too.

Authors please indicate if you are aware of any IPR on the = document.


I am not aware of any IPR related to this docume= nt.

=C2=A0


Andy
<= div>=C2=A0

___________________________= ____________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= br>

--94eb2c0d905000f18805642c4c8b-- From nobody Thu Feb 1 23:44:22 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CE2FB127601 for ; Thu, 1 Feb 2018 23:44:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UkG4dZkM74Lp for ; Thu, 1 Feb 2018 23:44:17 -0800 (PST) Received: from Mail2.SpriteLink.NET (Mail2.spritelink.net [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id 3977F12EAEA for ; Thu, 1 Feb 2018 23:44:17 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id 657222618E4 for ; Fri, 2 Feb 2018 08:44:19 +0100 (CET) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id giFP5QkACs9v for ; Fri, 2 Feb 2018 08:44:17 +0100 (CET) Received: from Kristians-MacBook-Pro.local (c-1789e455.014-82-73746f13.cust.bredbandsbolaget.se [85.228.137.23]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 665622619D1 for ; Fri, 2 Feb 2018 08:44:17 +0100 (CET) To: netmod@ietf.org References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local> <4EB04703-CD66-43D3-8653-BFC62B2C0FA1@gmail.com> <788291A3-8BB6-494A-A7CF-D68B3FC70F98@gmail.com> <543B7D01-A491-4BFB-B74B-786002F31022@juniper.net> From: Kristian Larsson Message-ID: <5cdb95e6-35ab-8120-7f35-4d6d8df0274c@spritelink.net> Date: Fri, 2 Feb 2018 08:44:13 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <543B7D01-A491-4BFB-B74B-786002F31022@juniper.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 07:44:20 -0000 Mahesh, I've reviewed this model, I think I largely caused the last couple of updates to it late last year. Overall I think it is a good model. Placement of feature-statements could be debated - no clear answers. object groupings is something I would like to see in the model but it was always deferred. On 2018-01-22 16:50, Kent Watsen wrote: > Hi Mahesh, > > Thanks, it doesn't get much more concrete then a pull request  ;) > > Okay, so from a chair/shepherd perspective, can folks please consider > this update to -15 as the LC solution to removing the open issue Juergen > found in the draft? > > As a contributor, I don't think the name of the groupings or their > description statements should allude to something that doesn't exist > yet.  Rather than e.g. "source-or-group", could it be instead something > like "source-type"? +1 > Also, the update seems to be for both when > specifying networks as well as when specifying port-ranges, but the > original issue (see below) only mentioned addresses - is the > pull-request actually what's needed and the description of the issue in > Section 8 is incomplete? > >     8.  Open Issues > >        o  The current model does not support the concept of "containers" > >             used to contain multiple addresses per rule entry. Object groupings are useful whenever there are many of something. There are usually more address entries than ports, so perhaps more useful for addresses, but it can still be useful to say "NFS-PORTS" and mean all the ports that NFS use (god knows what they are). Other have mentioned scale ACL and that it can be solved in other ways. To me, this sort of object-groupings is not about optimising things for the hardware but rather making it easy for me to write rules. I think it is paramount for security that ACLs can be easily read and understood. If we do not understand them, then we cannot say they are effective and secure. Object groupings greatly improves the readability of ACLs and thus makes it easier to write secure ACLs. I understand the authors wishes to get the first version out the door but I can't help but wonder if it isn't just easier to add in object groupings now. It's not that damn complicated (they are just lists). If not, I'm happy to work with them on the next version which could include object groupings. As for the PR to add choices, there seems to be an extra container inserted. I also made a comment on GitHub. At the very least, I think it would be best if this PR is fixed and merged before we proceed. kll From nobody Thu Feb 1 23:48:27 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74F3127601 for ; Thu, 1 Feb 2018 23:48:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M_6-SZxOwh2P for ; Thu, 1 Feb 2018 23:48:23 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 187D512EC18 for ; Thu, 1 Feb 2018 23:48:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5163; q=dns/txt; s=iport; t=1517557703; x=1518767303; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=FYtGXHhNNGDJaKneN0GVqiK/geYZ0u0QGOxYeJ4pWlc=; b=NCn6Rpnr8Ww8565UAQKuDCclm8Fo4oyPR52g2lcoGIuio5hLXQfoIsjW ALs22Uu5bsm3sEZ86L7139SltVV4Rb7HILGBAhEJRKVeWJU/FZisplBbd SAjdmtOm1z4FdubeJRf/xhvdPJjh4eq3WqVDoMV54RxLYVaAZxHNnlVrG A=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAQAeF3Ra/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodSiDYIsYjxUnmV8HAxgLhElPAoMJFQEBAQEBAQEBAmsohSM?= =?us-ascii?q?BAQEDAQEBIUsbCQIYKgICJzAGAQwGAgEBF4oSCBCQX510gieKYwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQ4KBYRphX0MgnmDLwEBAoUGgmUFkkWRXoRigjKOW4IehiO?= =?us-ascii?q?DcSaHWYsJjGWBPDUjgVAzGggbFT2CKoR4QDeMMAEBAQ?= X-IronPort-AV: E=Sophos; i="5.46,447,1511827200"; d="asc'?scan'208"; a="1755725" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2018 07:48:19 +0000 Received: from [10.61.98.215] (dhcp-10-61-98-215.cisco.com [10.61.98.215]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w127mItf011671; Fri, 2 Feb 2018 07:48:19 GMT To: Kristian Larsson , netmod@ietf.org References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local> <4EB04703-CD66-43D3-8653-BFC62B2C0FA1@gmail.com> <788291A3-8BB6-494A-A7CF-D68B3FC70F98@gmail.com> <543B7D01-A491-4BFB-B74B-786002F31022@juniper.net> <5cdb95e6-35ab-8120-7f35-4d6d8df0274c@spritelink.net> From: Eliot Lear Message-ID: <34e50e66-1522-4d77-be26-27284a91d7e9@cisco.com> Date: Fri, 2 Feb 2018 08:48:16 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <5cdb95e6-35ab-8120-7f35-4d6d8df0274c@spritelink.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="lMce1jcIR3bgKI0BPCassgkC5UUCVX1PO" Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 07:48:26 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --lMce1jcIR3bgKI0BPCassgkC5UUCVX1PO Content-Type: multipart/mixed; boundary="iuxF4dUfxJSpCuXWH6fUlMKCn0xLnF879"; protected-headers="v1" From: Eliot Lear To: Kristian Larsson , netmod@ietf.org Message-ID: <34e50e66-1522-4d77-be26-27284a91d7e9@cisco.com> Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local> <4EB04703-CD66-43D3-8653-BFC62B2C0FA1@gmail.com> <788291A3-8BB6-494A-A7CF-D68B3FC70F98@gmail.com> <543B7D01-A491-4BFB-B74B-786002F31022@juniper.net> <5cdb95e6-35ab-8120-7f35-4d6d8df0274c@spritelink.net> In-Reply-To: <5cdb95e6-35ab-8120-7f35-4d6d8df0274c@spritelink.net> --iuxF4dUfxJSpCuXWH6fUlMKCn0xLnF879 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US Hi Kristian, On 02.02.18 08:44, Kristian Larsson wrote: > Mahesh, > > I've reviewed this model, I think I largely caused the last couple of > updates to it late last year. Overall I think it is a good model. > Placement of feature-statements could be debated - no clear answers. > object groupings is something I would like to see in the model but it > was always deferred. > > > On 2018-01-22 16:50, Kent Watsen wrote: >> Hi Mahesh, >> >> Thanks, it doesn't get much more concrete then a pull request=C2=A0 ;)= >> >> Okay, so from a chair/shepherd perspective, can folks please consider >> this update to -15 as the LC solution to removing the open issue >> Juergen found in the draft? >> >> As a contributor, I don't think the name of the groupings or their >> description statements should allude to something that doesn't exist >> yet.=C2=A0 Rather than e.g. "source-or-group", could it be instead >> something like "source-type"? > > +1 > >> Also, the update seems to be for both when specifying networks as >> well as when specifying port-ranges, but the original issue (see >> below) only mentioned addresses - is the pull-request actually what's >> needed and the description of the issue in Section 8 is incomplete? >> >> =C2=A0=C2=A0=C2=A0=C2=A0 8.=C2=A0 Open Issues >> >> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0o=C2=A0 The current model d= oes not support the concept of >> "containers" >> >> =C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0used to contain multiple addresses per rule entry. > > Object groupings are useful whenever there are many of something. > There are usually more address entries than ports, so perhaps more > useful for addresses, but it can still be useful to say "NFS-PORTS" > and mean all the ports that NFS use (god knows what they are). > > Other have mentioned scale ACL and that it can be solved in other > ways. To me, this sort of object-groupings is not about optimising > things for the hardware but rather making it easy for me to write > rules. I think it is paramount for security that ACLs can be easily > read and understood. If we do not understand them, then we cannot say > they are effective and secure. Object groupings greatly improves the > readability of ACLs and thus makes it easier to write secure ACLs. > > I understand the authors wishes to get the first version out the door > but I can't help but wonder if it isn't just easier to add in object > groupings now. It's not that damn complicated (they are just lists). > If not, I'm happy to work with them on the next version which could > include object groupings. Please let's aim for the next version.=C2=A0 This document just completed= what I think is its FIFTH last call, which to me is nothing short of insa= ne. Eliot > > As for the PR to add choices, there seems to be an extra container > inserted. I also made a comment on GitHub. > At the very least, I think it would be best if this PR is fixed and > merged before we proceed. > > =C2=A0=C2=A0 kll > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --iuxF4dUfxJSpCuXWH6fUlMKCn0xLnF879-- --lMce1jcIR3bgKI0BPCassgkC5UUCVX1PO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlp0F8AACgkQh7ZrRtnS ejN5swgAmF6hSTWMqgSIZ1QeKN7vsaVUMN+pqMXIs3JJcUtayLM1H401N+j2mGVV +I2WI6Gvf3iBNN2LVBrRRTE8j0D6ROBymKdjA44QRfId0BsT8leKv3uJ2LRtnq58 aiqXAaCEOPH8ZkOp4cASq7uVi2iEZYV+A6+LlcAqH/YCueRrBc5lkAAovRpwQkRd aMdCHkOCfeAwPKwi9ztbncyF3/0N2j1FIP2LyLUf3o2wIbUiOnM22F/ghD76qziH o8fM8ZhqrhtCqy+50+joyfA6vZAt0iud1odc+tLPmVkUVVSO0WvK0dfOspGs6qLs M50BwzZ7D3eoDUOW9JbSac+Sf6APmA== =W5K8 -----END PGP SIGNATURE----- --lMce1jcIR3bgKI0BPCassgkC5UUCVX1PO-- From nobody Fri Feb 2 01:30:30 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EECC12FA96; Fri, 2 Feb 2018 01:30:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5cKKuHaEy0LG; Fri, 2 Feb 2018 01:30:21 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7F96812FA9D; Fri, 2 Feb 2018 01:30:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3761; q=dns/txt; s=iport; t=1517563815; x=1518773415; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=5OgYnYhCni7+byK74b43Q6kbGHsQUPTib5ARGar8GSw=; b=Tg0WchV14N7qifQDmZx8Xpk88N0AMYhyMQR+QAOOjHVxCgkbov4ssaVD w+dPwCS29OR+TRrm2dKpZ5WVfR+w0zXgH6lU1rd+kPEXmuxGMxW7RtC8a AMfzeP+E/zMMM4ec1mQ+gw2zRKLzp7TOApkyFUjurGjR6XJDDjB07BCrw g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQDfLnRa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQodSiOeI88kXOHbAoYAQqESU8CgwsUAQEBAQEBAQECayiFJAE?= =?us-ascii?q?BBAEBbAsQCwQKCi4nMAYBDAYCAQGKMRCwJCaKPwEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBARgFhGmDbIIRgwWDLwEBAQEBgU4BAYYaBZocigeIGY1Wgh6GI4Nxh3+NaoF?= =?us-ascii?q?tiBeBPDYigVAzGggbFT2CKoR3QTcBiXOCPAEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,448,1511827200"; d="scan'208,217";a="1810318" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2018 09:30:12 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w129UB9C009913; Fri, 2 Feb 2018 09:30:11 GMT To: Mahesh Jethanandani , NETCONF WG Cc: NETMOD WG References: From: Robert Wilton Message-ID: <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> Date: Fri, 2 Feb 2018 09:30:11 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------56F9AD3BCDDCA248B7B97DE6" Content-Language: en-US Archived-At: Subject: Re: [netmod] [Netconf] LC on YANG Library (bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 09:30:24 -0000 This is a multi-part message in MIME format. --------------56F9AD3BCDDCA248B7B97DE6 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit I am not aware of any IPR related to this document. Thanks, Rob On 01/02/2018 18:59, Mahesh Jethanandani wrote: > WG, > > The authors of rfc7895bis have indicated that they believe the > document is ready for LC[1]. > > This starts a two week LC on the draft > . The LC > will end on February 15. > > Please send your comments on this thread. Reviews of the document, and > statement of support are particularly helpful to the authors. If you > have concerns about the document, please state those too. > > Authors please indicate if you are aware of any IPR on the document. > > Thanks. > > [1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html > > Mahesh & Kent > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------56F9AD3BCDDCA248B7B97DE6 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: 8bit I am not aware of any IPR related to this document.

Thanks,
Rob


On 01/02/2018 18:59, Mahesh Jethanandani wrote:
WG,

The authors of rfc7895bis have indicated that they believe the document is ready for LC[1].

This starts a two week LC on the draft. The LC will end on February 15. 

Please send your comments on this thread. Reviews of the document, and statement of support are particularly helpful to the authors. If you have concerns about the document, please state those too.

Authors please indicate if you are aware of any IPR on the document.

Thanks.


Mahesh & Kent



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

--------------56F9AD3BCDDCA248B7B97DE6-- From nobody Fri Feb 2 01:53:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B138112FA97 for ; Fri, 2 Feb 2018 01:53:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MYRxgQAqSw1X for ; Fri, 2 Feb 2018 01:53:08 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B8AE4127873 for ; Fri, 2 Feb 2018 01:53:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3155; q=dns/txt; s=iport; t=1517565187; x=1518774787; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Hb9inp3yIAnRGg1zexPAPoqsYeVklBF2dQLL2xmEySQ=; b=T0zzQzrOW33orpN8wQ+aGWTUdeIMh24yoUg59+zdpiQ5IOtXtj7zuGKi BSE58MrGyNICukJqB7qTfgg9NAjKqNsKz+4iDv2vJzhO9iTJ42VZaC5b4 rfKDDWUnvveNuDX6hzSDUKrEwWUuSC+rUUmdUA56XSqMBUyeMSsNCW3oE w=; X-IronPort-AV: E=Sophos;i="5.46,448,1511827200"; d="scan'208";a="1809756" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Feb 2018 09:53:06 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w129r5UP012750; Fri, 2 Feb 2018 09:53:05 GMT To: Eliot Lear , Kristian Larsson , netmod@ietf.org References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local> <4EB04703-CD66-43D3-8653-BFC62B2C0FA1@gmail.com> <788291A3-8BB6-494A-A7CF-D68B3FC70F98@gmail.com> <543B7D01-A491-4BFB-B74B-786002F31022@juniper.net> <5cdb95e6-35ab-8120-7f35-4d6d8df0274c@spritelink.net> <34e50e66-1522-4d77-be26-27284a91d7e9@cisco.com> From: Robert Wilton Message-ID: <0440ec8a-d2d5-9c53-c695-f9d46f5694d1@cisco.com> Date: Fri, 2 Feb 2018 09:53:05 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <34e50e66-1522-4d77-be26-27284a91d7e9@cisco.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 09:53:10 -0000 On 02/02/2018 07:48, Eliot Lear wrote: > Hi Kristian, > > > On 02.02.18 08:44, Kristian Larsson wrote: >> Mahesh, >> >> I've reviewed this model, I think I largely caused the last couple of >> updates to it late last year. Overall I think it is a good model. >> Placement of feature-statements could be debated - no clear answers. >> object groupings is something I would like to see in the model but it >> was always deferred. >> >> >> On 2018-01-22 16:50, Kent Watsen wrote: >>> Hi Mahesh, >>> >>> Thanks, it doesn't get much more concrete then a pull request  ;) >>> >>> Okay, so from a chair/shepherd perspective, can folks please consider >>> this update to -15 as the LC solution to removing the open issue >>> Juergen found in the draft? >>> >>> As a contributor, I don't think the name of the groupings or their >>> description statements should allude to something that doesn't exist >>> yet.  Rather than e.g. "source-or-group", could it be instead >>> something like "source-type"? >> +1 >> >>> Also, the update seems to be for both when specifying networks as >>> well as when specifying port-ranges, but the original issue (see >>> below) only mentioned addresses - is the pull-request actually what's >>> needed and the description of the issue in Section 8 is incomplete? >>> >>>      8.  Open Issues >>> >>>         o  The current model does not support the concept of >>> "containers" >>> >>>              used to contain multiple addresses per rule entry. >> Object groupings are useful whenever there are many of something. >> There are usually more address entries than ports, so perhaps more >> useful for addresses, but it can still be useful to say "NFS-PORTS" >> and mean all the ports that NFS use (god knows what they are). >> >> Other have mentioned scale ACL and that it can be solved in other >> ways. To me, this sort of object-groupings is not about optimising >> things for the hardware but rather making it easy for me to write >> rules. I think it is paramount for security that ACLs can be easily >> read and understood. If we do not understand them, then we cannot say >> they are effective and secure. Object groupings greatly improves the >> readability of ACLs and thus makes it easier to write secure ACLs. >> >> I understand the authors wishes to get the first version out the door >> but I can't help but wonder if it isn't just easier to add in object >> groupings now. It's not that damn complicated (they are just lists). >> If not, I'm happy to work with them on the next version which could >> include object groupings. > Please let's aim for the next version.  This document just completed > what I think is its FIFTH last call, which to me is nothing short of insane. +1 for publishing the draft now. If there are further bells and whistles that need to be added then ideally they would be covered by an ACL-extensions model that augments the base ACL model.  If tweaks are required to the base model to achieve it then I think that creating a v2 version of the ACL model is also OK. Thanks, Rob From nobody Fri Feb 2 04:59:52 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A00BF12D810 for ; Fri, 2 Feb 2018 04:59:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.911 X-Spam-Level: X-Spam-Status: No, score=-2.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sHUpz2jYvaO9 for ; Fri, 2 Feb 2018 04:59:48 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0118.outbound.protection.outlook.com [104.47.1.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FF9B127522 for ; Fri, 2 Feb 2018 04:59:48 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=Lap/Pu9TpbacYt2RJ/HRC8/Ph6eJ8ky+BCG/3O+07f0=; b=QP5YJxHBKIcnMoSv0+xrfQ2ZM5aG83R70ajuYuA3Ao1vkLfk8qFicQW7g9+hmlGqKsRq7p/5fHbxDZtxy183J3cheoJpn9dqF7YqcXsliN7nrOfGQqJ72DivCcyn9Ja5wjaZ9FC/jFpdcjS4KN/xMnT2JfYLFstAxjeJ+9Z39mw= Received: from pc6 (86.169.153.236) by HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Fri, 2 Feb 2018 12:59:45 +0000 Message-ID: <036201d39c25$7bb5a060$4001a8c0@gateway.2wire.net> From: "t.petch" To: "NETMOD Working Group" , "Benoit Claise" References: <26131545-049c-9a1a-eb2b-cdad6fce3190@cisco.com> Date: Fri, 2 Feb 2018 12:58:03 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: DB3PR0102CA0014.eurprd01.prod.exchangelabs.com (2603:10a6:8::27) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 99329229-f31f-4e57-c13b-08d56a3cd5a5 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:E0gIdgH8XMK6/mPi8faHAbFdWF2SxtHAHlXrhk7meV6bhXU0ccn/OqjM13tmlKzdPjMT4a9boNG3eMJ9kCCiEcanFQuFBn9dElqGDQbm/AhzX67e0BH9jeflefaZmNAWSjQuVj8ycfknKB0e1ftZ+IW4MQFYGjMFT4BpmCuxE53czUzJ3uE8YqJZiDLlQNqL3er+mVRx54gP6DCSLP8kXT6bTKI12SJp/k0BcVKjAWZPp64IT1i+3nhnyTZ6yS9K; 25:KPs/7lWVKERY4fBJt5wlxE7P9XHbjC8Z1HmQCQnn2F+/e+csZcrTYdQ/nba2DD/Cujn0Y7I5JmX8X5TluV0Y6TD9NRyqkz8s8Z59jm+pWAQtG880hortBwwl08B+CznfMxpLNIRZ1un+L3Yamusq4d8NjCUcPeHPShBRdYw1udYXdyT2pzuOmut8CoaoUiRRoCRdJz7sDj9Sr3pc+BWNvb/o1VPF9Or0yo90GP3SgXdq6UmfNu6LjlCdERq3sfjMY7EZWAZua5x9KC4cS6+GdgxSZkZ1Bp+ZpVAVHgvsz0bOiX4M/iqq3qaX8kXOJZCrYOzifwAEhy5P9CikqCOPTg==; 31:pWu9cL1sIAYfryidjSs2DF/Z78yW1eChsC0nZU/Q/OS0xtygqmKZx/961LTCulzSvfiCiDAq1StxP8yyTlgPZiYQ/SwYaYxT6J98xVVbVWl+aCwMb08pC97Wo9dH497ru0J8bMNR8sHAVPwdNcMK0pH3pJ5Z9QAbB7Pbwl1mXzK6ENC4USs82AKRwJSldooc63II41qhom65KMezE303kgw5ojdrg9/xDz4dPPWtbsY= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002: Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(10201501046)(3002001)(3231101)(2400082)(944501161)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 4:dQpQBo+thVzZBHTaoam3mgVQqTa357f5roW5p4MVtElQ1BRjt3rlNM8xiwrKCELwwOdXj55mtKZM6K/TT5LM3nH46QJuXkbnfhwiEPf4BUnbPPEVYf6KdRhx7typx7RSELFB1IVQtF9O9RR+AQ7M4b/pgmuUzoDmSHVvKwrqmKvr37uSHTGrpB/oZkVgdPFBsLgFljZT0Zi5C0dvVu90aiVcCJyjt7gjBOzPTvgJ2mUapO2bF9JIkZpwWHMbKMTbHPFqzEOD4bjq6QQG+Gt0lw== X-Forefront-PRVS: 05715BE7FD X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(366004)(39860400002)(376002)(396003)(51444003)(189003)(199004)(86362001)(25786009)(6116002)(3846002)(6666003)(4720700003)(386003)(61296003)(97736004)(1556002)(68736007)(26005)(105586002)(44736005)(6486002)(106356001)(6496006)(50226002)(3480700004)(81686011)(50466002)(478600001)(110136005)(33896004)(8936002)(53936002)(76176011)(5660300001)(81816011)(7116003)(186003)(23756003)(9686003)(16526019)(230700001)(62236002)(44716002)(14496001)(47776003)(221733001)(66066001)(52116002)(316002)(2906002)(7736002)(81156014)(81166006)(305945005)(84392002)(8676002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3002; 23:v6WCaJvPWNZDIfKzmVhH0i5mYUT3Yb03uYWnu?= =?iso-8859-1?Q?hIAKojtAYa2iFJbhi7kWAUHumkuwWegMqfBv/poms1nPJHJQVbuA76WQVM?= =?iso-8859-1?Q?Dz5xSgl+Svstmb/4nZtC8x7wx4Vf79B/oLDqN697Jow2TUTRmmcOW1FZ4b?= =?iso-8859-1?Q?RPkjLaEj+bWFZJ668Izx4IVLytZCjKz5wGAqeI09tW+uA2mF9e1WEpf70c?= =?iso-8859-1?Q?jNWP/l66ofE8yxaJx+JtgKNAqTm7gSC4z8XvhSUs2c7aU7vv0bQ5q4hoCF?= =?iso-8859-1?Q?FAoUU0fYgF7OM6gqpj0cailIVDepfG8m8W6LE5pOf/1FDUCabg4fmI1OG/?= =?iso-8859-1?Q?39LMrl4AY5gH8OgX/AwKzpF301HvPG8HmWKBRzuWfrQAriKDDMGOfP/lF1?= =?iso-8859-1?Q?nuizMdTS6nkHr+lISDqa9zuVt+1MvN3By+DcLb5hAOJWtXt1XapgB3cweO?= =?iso-8859-1?Q?Xn0ZZ770LHKBUayZ0R5xViglofxMpbEO5H8y/D12CopIztInnzWTwfP60J?= =?iso-8859-1?Q?MeA24bAXShW9BI5up4NjOuV2ejMRHSefzTp4wnQQ8hTN78rIkMqbginXkH?= =?iso-8859-1?Q?x621Vi3oX7AxMVRJIIkpJ3v49LyHmhAi5Mbe3S8MKKi8J7rcWwdyMqapom?= =?iso-8859-1?Q?DXfzb2hbNyPKoDFgxf6Kxe6Xj3ggtYKxhUvnpirI+fSRCQNHr/xvxfTDdo?= =?iso-8859-1?Q?hAHRb5JkojRPF58EdtR5PVjh8HnQyVRkNyFmcn2oIN52+JdbGRKZ0+mcMl?= =?iso-8859-1?Q?ovqBDjbdKCgbpJ/px2+umNVHUDjwDnwAzwAMRcuvDPwiernGUvQrWy95+1?= =?iso-8859-1?Q?UN2uoyI9vQcQhWx/NH3sesk4MrL1cUWfbBZi7tSka1J/cyhB+1G2XMvlrQ?= =?iso-8859-1?Q?OiLkXk4NNzcnkDW9kz5tR6bKicU0DlpXxVtHqb9yXoaD3KIbP8vrYI42g2?= =?iso-8859-1?Q?wWpfexssphypJiI0blpDtzlDpD2X172vsby/gVrj3ZRLC7D07ZoeQ1/srU?= =?iso-8859-1?Q?xjMkKpvQ9/uf6StgcPowoav45fpd32Sa0hyMlMhf1VCoXPdfm5FY8bkQCV?= =?iso-8859-1?Q?yuGTEHM3Y5A1SPCFj17hJCuJT6YRf3NXMgNKFpnGV+MbwkGgfDm+YfwUgD?= =?iso-8859-1?Q?mryj5hh/M/2wC62wZ9Or6NQa2fvdtX3Tted8pm6PzIkL16pm7DNXThjeyB?= =?iso-8859-1?Q?TDxx87NHie3DhupIoGZ6V8xrHyaHojeelZThClJZXaDI5UUhkl5UFTtnXo?= =?iso-8859-1?Q?5FeAqIkw3ppZ5cI4xYWd8RRMzZyEsA58NyKx6hH8RTeBlrBM52mjnOqJug?= =?iso-8859-1?Q?B5k06R+SfdddnA0vBtkuCQ3M/3AD8bPS8WQ/lNgO9nGcI2vD/el++BqYIf?= =?iso-8859-1?Q?6A+yHMOYB+2MjHCDyUjyJcdtuMdRAs6Zm2ur4bMnMJRVV5bON6wg0vSZWr?= =?iso-8859-1?Q?ADyVjh23xAVzh6h8=3D?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:Et1s7H1mc8XXbfj0OX+ZwUM02uMgXAmwtWcRIJ5X1xLC8mLk0AL5zd24hw90QIv7Kw03dw4SyxU1JtMCcgZa+GIicJcFnXLrSx/m5ZmE0lWJKXUIjk3WVFY5S0YkwFmfd3BlXf9irIDCYFRdT/rF6NF+yOIUPKNleagtP07OX6vQXQw4fAShPE3XhDxO4IetQFKuOsMpYjDHBPLqd1MBCbaBNmS+5XdIZ+szQ2weQRlujfbpYGI//s5jHEEleEojaNQF+pnwgfG8H8m/HqTDSGZXELcJ5SdeXRNn8r8ZBaBS53iZ7Ug5F8uGAUwaVsFpJKJpYtNFzWif69X6dTomvEOWRXF5twp51V15xo5tQwI=; 5:E9hA6P5IQMHxP8FlJrrba0SusgYIfetk7DFMt8/FmdJ7e529FZBk8VBRu2bze9bwARNNYLGURgrP/ezohemAR1+Sb4rvkTJDHJm+v7McYkslX22DjWtb6CVuasE6YfVurS9Z2Uv1rxIILhAWCmK2qTIshWbLTypRITk/cC9AWe4=; 24:gvg5SKDRyK2PbKKrjRrcsHsJRtIBvM7JKa1AuwyV3Z7BlL3oE4w/oFEeMmoalWCx8luB2q7joAKBQ05X5EA+s2aaeBXwMOWdSfrrlBsIeCg=; 7:52fRVrj9hm74YDqvCr/5F4pdJiGlnsBFQLOVr7UYRPbf/2AmgDhd1VwBVWYbUwVrLFkQE6zzo7vfxHVGOXiIu4kV5Pb5D1evIewyQkqij9/WcoI10nIvKjCN9MmysvIYYiwjL3i59hGt2vu61O6HpwzQfIhDsWCGMqhIFhVTN6jTtYNROEyMnLFs41SyETUfgZWF5zghLEizHh72r6UDpIbsEtpTmLhBncPV0HHS5XSLb7EmuXOUZRMbTho+OfXd SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 02 Feb 2018 12:59:45.3878 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 99329229-f31f-4e57-c13b-08d56a3cd5a5 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Subject: [netmod] Missing references X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 12:59:51 -0000 I just came across (yet) another example of a reference to an RFC in a description clause of a YANG module that appears nowhere else in the I-D. This seems to be a systematic error that some YANG module authors make; can the tools be modified to pick it up? The logic is simple enough. The latest example is in draft-ietf-rtgwg-yang-rip-09 which fails to reference RFC5952; I think that the I-D is in the RFC Editor queue. Tom Petch From nobody Fri Feb 2 05:51:27 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 63812129BBF; Fri, 2 Feb 2018 05:51:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.711 X-Spam-Level: X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xij-9fDUSnfa; Fri, 2 Feb 2018 05:51:22 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D1BE12422F; Fri, 2 Feb 2018 05:51:22 -0800 (PST) Received: from pps.filterd (m0108161.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w12DnqJn026711; Fri, 2 Feb 2018 05:51:20 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=XkIYt0Ccr3TIE6F0RyaKFq60fwFrkhYDRQ0DQ3fDqho=; b=ikVy5oOhV6gg+kdxU0b2picevla4SgP/m8B8X/cTjuIJkr4ADh7VqEXSR6PZ9y55cYOE QoEZiT2PXv0fayDg0kqCnEr+zrizmhHh6eWEpwUEXeotzL0xtkmnt7h2oJ0+0yAZdANg 2xqzhObVrxfybim0spb3cp1rr/V7j0ntIfRJlWx+3gDNRkjajewPUUB/tWfTYzcvpptC PuJciN9TAjDZoPh3oSfmrlkCMjEsYTBfZWGZm6TTtZqMlxfpoYFT7tqbMQIEQshYUXq4 hrzT3eniOTu1WlIXFBEavdYVGC2+UDaiggv2dSBNsvb+qBufXTod8+dl+rMkGE66A/Q9 JA== Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0016.outbound.protection.outlook.com [207.46.163.16]) by mx0b-00273201.pphosted.com with ESMTP id 2fvs2qg0ty-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 02 Feb 2018 05:51:20 -0800 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2889.namprd05.prod.outlook.com (10.168.176.13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Fri, 2 Feb 2018 13:51:18 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0464.012; Fri, 2 Feb 2018 13:51:18 +0000 From: Kent Watsen To: Robert Wilton , Mahesh Jethanandani , NETCONF WG CC: NETMOD WG Thread-Topic: [Netconf] LC on YANG Library (bis) Thread-Index: AQHTm47bJW9dUvOobEWSKznAzlTJN6OQ2bqA///1IwA= Date: Fri, 2 Feb 2018 13:51:18 +0000 Message-ID: <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> References: <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> In-Reply-To: <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB2889; 6:BQyBC9ckfFF4Bs1mlfSA/iC5L/9CNKTyP11eXxwbIyk/jC24+JpQhrzrKosPS2It8TGp4Nk2/6qeLh2KAKmEgVFN2w5Cw/jy1n8tgsU7WqxMApokSYPlk+VlJvYVBQkPpvID9YaeCN7OnkgQayaMRyUkzO2vtApx5qXpa8eReDdZeP9FD3D03ahU+ILG/q6VrWBfhvMOzlyuDAJinM+vIB3kLp2MQGyjh6P2SBRgzvlTcjK1BtTUlx3ZIof+/2OgPPiIFEi8GTF6gDIGV9rmiv7ghJa6XxlgFhW6P2Tmx9Icr4Rd3dcmaMVwrFnRz9GToRq+DuLnPoD/x0RpsRKQN1pSmZ3XmGOU21IR5kcnMC5H24S99abg3pBhe7kwMvP5; 5:y4hybOKmKFC0d2ajwdLLuyORkvikFc5m8nNDOFE9ITFVLXC0UYXo0eMqYzM/OYrONRK0smROxFfxiX04PX6CRwGtha+U7FPHsqQKRqbK762XTwaa8mOZ1iNQFKQ65bic374PPlrsyNVHTq+IohpEtb/Tigj+NvCei9Cm6EHLOrQ=; 24:jIhY5Z0enDC/qhSUSQ+ADS5uOSQ31rLXZQ6FbyN3UyFfJT3ke4EntG7WUodNOM17MhzDQRJ0rWteNJfPHWi/AnxW/ZLjtOYtalFh3hL58NM=; 7:Nu0Lh3u3BAmIa1n6+YT2Q6wJcpwPBVjCBSyVutmOB8aTrcciV8ZWRhvCvkf3rbvL7MaaqdB+Me5lEH0kkYVcQ3GOUD7NxcFwUdldgYFfN8vamfTmTYVLXYB4JPbQnW+lIndiFVlpp2nRAHiDRJtjtQmOmn6u3vd62OSu0n5tNZFmDCusr6PkZSnFFHligPn8kYmDrZmF6BEGp5+3kp72DodmLvMrfg24Ysy0HK1kVayZhQE0a+fHewhpkMlWyeCG x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e66d14b0-d553-4944-c201-08d56a440927 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB2889; x-ms-traffictypediagnostic: DM5PR05MB2889: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(95692535739014)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231101)(2400082)(944501161)(3002001)(10201501046)(6055026)(6041288)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB2889; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2889; x-forefront-prvs: 05715BE7FD x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(346002)(376002)(39380400002)(39860400002)(189003)(199004)(39060400002)(316002)(2950100002)(478600001)(2900100001)(3660700001)(3280700002)(110136005)(14454004)(58126008)(33656002)(105586002)(6506007)(26005)(53546011)(99286004)(5660300001)(83506002)(3846002)(6116002)(102836004)(2906002)(606006)(76176011)(966005)(6436002)(7736002)(106356001)(68736007)(81156014)(97736004)(77096007)(229853002)(36756003)(81166006)(66066001)(53936002)(8676002)(83716003)(86362001)(186003)(54896002)(8936002)(236005)(4326008)(82746002)(6512007)(6246003)(6486002)(6306002)(25786009); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2889; H:DM5PR05MB3484.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) x-microsoft-antispam-message-info: 6W5iwhq8XlSEBLms3mb9BNwotEC7rCTs1NRZIEcW9ZJmjpp1aoTrBVXkBZhZoqmZphIA8Bt68ictkWd9maYOyg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_14390982A1C240E5AEA1B03B02E8ACECjunipernet_" MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: e66d14b0-d553-4944-c201-08d56a440927 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Feb 2018 13:51:18.6103 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2889 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-02_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802020172 Archived-At: Subject: Re: [netmod] [Netconf] LC on YANG Library (bis) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 13:51:25 -0000 --_000_14390982A1C240E5AEA1B03B02E8ACECjunipernet_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QXMgY28tYXV0aG9yLCBJIGFtIG5vdCBhd2FyZSBvZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBk b2N1bWVudC4NCg0KQXMgYSBjb250cmlidXRvciwgSSBoYXZlIHJlYWQgdGhpcyBkb2N1bWVudCBh bmQgdGhpbmsgdGhhdCBpdCBpcyByZWFkeSBmb3IgYWR2YW5jZW1lbnQuDQoNCktlbnQNCg0KDQpP biAyLzIvMTgsIDQ6MzAgQU0sICJOZXRjb25mIG9uIGJlaGFsZiBvZiBSb2JlcnQgV2lsdG9uIiA8 bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc+ IG9uIGJlaGFsZiBvZiByd2lsdG9uQGNpc2NvLmNvbTxtYWlsdG86cndpbHRvbkBjaXNjby5jb20+ PiB3cm90ZToNCg0KSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZG9j dW1lbnQuDQoNClRoYW5rcywNClJvYg0KDQpPbiAwMS8wMi8yMDE4IDE4OjU5LCBNYWhlc2ggSmV0 aGFuYW5kYW5pIHdyb3RlOg0KV0csDQoNClRoZSBhdXRob3JzIG9mIHJmYzc4OTViaXMgaGF2ZSBp bmRpY2F0ZWQgdGhhdCB0aGV5IGJlbGlldmUgdGhlIGRvY3VtZW50IGlzIHJlYWR5IGZvciBMQ1sx XS4NCg0KVGhpcyBzdGFydHMgYSB0d28gd2VlayBMQyBvbiB0aGUgZHJhZnQ8aHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19o dG1sX2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYtMkRyZmM3ODk1YmlzLTJEMDQmZD1Ed01ELWcmYz1I QWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpH SjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWZpX29wamo0a2lvN2V1ZlJYU1FTaThk U2pKTmxrVkRvOGExRjB6c0NyZkUmcz1NcWJWbGpuWXFJazl3NzhrY2ZwN29VcUdSLXFWb05WOTBu anlUd0xBZHBjJmU9Pi4gVGhlIExDIHdpbGwgZW5kIG9uIEZlYnJ1YXJ5IDE1Lg0KDQpQbGVhc2Ug c2VuZCB5b3VyIGNvbW1lbnRzIG9uIHRoaXMgdGhyZWFkLiBSZXZpZXdzIG9mIHRoZSBkb2N1bWVu dCwgYW5kIHN0YXRlbWVudCBvZiBzdXBwb3J0IGFyZSBwYXJ0aWN1bGFybHkgaGVscGZ1bCB0byB0 aGUgYXV0aG9ycy4gSWYgeW91IGhhdmUgY29uY2VybnMgYWJvdXQgdGhlIGRvY3VtZW50LCBwbGVh c2Ugc3RhdGUgdGhvc2UgdG9vLg0KDQpBdXRob3JzIHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgYXJl IGF3YXJlIG9mIGFueSBJUFIgb24gdGhlIGRvY3VtZW50Lg0KDQpUaGFua3MuDQoNClsxXSBodHRw czovL3d3dy5pZXRmLm9yZy9tYWlsLWFyY2hpdmUvd2ViL25ldGNvbmYvY3VycmVudC9tc2cxMzk4 MC5odG1sPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z QV9fd3d3LmlldGYub3JnX21haWwtMkRhcmNoaXZlX3dlYl9uZXRjb25mX2N1cnJlbnRfbXNnMTM5 ODAuaHRtbCZkPUR3TUQtZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhj V3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Zmlf b3BqajRraW83ZXVmUlhTUVNpOGRTakpObGtWRG84YTFGMHpzQ3JmRSZzPVhoUlNTVFdpZk8tU2tQ aTJDV0s1WjVhVW5pMkYxcVJROE1vajdUN2dJLVkmZT0+DQoNCk1haGVzaCAmIEtlbnQNCg0KDQoN Cg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQpO ZXRjb25mIG1haWxpbmcgbGlzdA0KDQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25mQGll dGYub3JnPg0KDQpodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8 aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cu aWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRjb25mJmQ9RHdNRC1nJmM9SEFrWXVoNjNyc3Vo cjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhx bjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1maV9vcGpqNGtpbzdldWZSWFNRU2k4ZFNqSk5sa1ZEbzhh MUYwenNDcmZFJnM9bWNERi12NUk0ZXBnc3VXTEh2cjMycFo1bVJvblJPS044enBLY1pXQkMwbyZl PT4NCg0KDQo= --_000_14390982A1C240E5AEA1B03B02E8ACECjunipernet_ Content-Type: text/html; charset="utf-8" Content-ID: <58C4C238B76A5F43BBF50322EE65B7AB@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0 aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5 bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpz cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250 LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xv cjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5v bmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0 eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls ZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1 ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkFzIGNvLWF1dGhv ciwgSSBhbSBub3QgYXdhcmUgb2YgYW55IElQUiByZWxhdGVkIHRvIHRoaXMgZG9jdW1lbnQuPG86 cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5BcyBhIGNvbnRy aWJ1dG9yLCBJIGhhdmUgcmVhZCB0aGlzIGRvY3VtZW50IGFuZCB0aGluayB0aGF0IGl0IGlzIHJl YWR5IGZvciBhZHZhbmNlbWVudC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt aWx5OkNhbGlicmkiPktlbnQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48 L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5 OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+T24gMi8yLzE4LCA0OjMwIEFNLCAmcXVvdDtOZXRjb25mIG9uIGJl aGFsZiBvZiBSb2JlcnQgV2lsdG9uJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86bmV0Y29uZi1i b3VuY2VzQGlldGYub3JnIj5uZXRjb25mLWJvdW5jZXNAaWV0Zi5vcmc8L2E+IG9uIGJlaGFsZiBv Zg0KPGEgaHJlZj0ibWFpbHRvOnJ3aWx0b25AY2lzY28uY29tIj5yd2lsdG9uQGNpc2NvLmNvbTwv YT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij5JIGFtIG5vdCBhd2FyZSBv ZiBhbnkgSVBSIHJlbGF0ZWQgdG8gdGhpcyBkb2N1bWVudC48YnI+DQo8YnI+DQpUaGFua3MsPGJy Pg0KUm9iPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+T24gMDEvMDIvMjAxOCAxODo1OSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZTo8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7 bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5XRywgPG86cD48L286 cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgYXV0aG9ycyBvZiByZmM3 ODk1YmlzIGhhdmUgaW5kaWNhdGVkIHRoYXQgdGhleSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcyBy ZWFkeSBmb3IgTENbMV0uPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiPlRoaXMgc3RhcnRzIGEgdHdvIHdlZWsgTEMgb24gdGhlJm5ic3A7PGEgaHJl Zj0iaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX190 b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEaWV0Zi0yRG5ldGNvbmYtMkRyZmM3ODk1YmlzLTJE MDQmYW1wO2Q9RHdNRC1nJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9E VFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNa byZhbXA7bT1maV9vcGpqNGtpbzdldWZSWFNRU2k4ZFNqSk5sa1ZEbzhhMUYwenNDcmZFJmFtcDtz PU1xYlZsam5ZcUlrOXc3OGtjZnA3b1VxR1ItcVZvTlY5MG5qeVR3TEFkcGMmYW1wO2U9Ij5kcmFm dDwvYT4uDQogVGhlIExDIHdpbGwgZW5kIG9uIEZlYnJ1YXJ5IDE1LiZuYnNwOzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5QbGVhc2Ugc2VuZCB5 b3VyIGNvbW1lbnRzIG9uIHRoaXMgdGhyZWFkLiBSZXZpZXdzIG9mIHRoZSBkb2N1bWVudCwgYW5k IHN0YXRlbWVudCBvZiBzdXBwb3J0IGFyZSBwYXJ0aWN1bGFybHkgaGVscGZ1bCB0byB0aGUgYXV0 aG9ycy4gSWYgeW91IGhhdmUgY29uY2VybnMgYWJvdXQgdGhlIGRvY3VtZW50LCBwbGVhc2Ugc3Rh dGUgdGhvc2UgdG9vLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5BdXRob3JzIHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgYXJlIGF3YXJlIG9mIGFu eSBJUFIgb24gdGhlIGRvY3VtZW50LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+ DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlsxXSZuYnNwOzxhIGhyZWY9Imh0dHBzOi8vdXJsZGVm ZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWwt MkRhcmNoaXZlX3dlYl9uZXRjb25mX2N1cnJlbnRfbXNnMTM5ODAuaHRtbCZhbXA7ZD1Ed01ELWcm YW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05 emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPWZpX29wamo0 a2lvN2V1ZlJYU1FTaThkU2pKTmxrVkRvOGExRjB6c0NyZkUmYW1wO3M9WGhSU1NUV2lmTy1Ta1Bp MkNXSzVaNWFVbmkyRjFxUlE4TW9qN1Q3Z0ktWSZhbXA7ZT0iPmh0dHBzOi8vd3d3LmlldGYub3Jn L21haWwtYXJjaGl2ZS93ZWIvbmV0Y29uZi9jdXJyZW50L21zZzEzOTgwLmh0bWw8L2E+PG86cD48 L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+TWFoZXNoICZh bXA7IEtlbnQ8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+ PGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8cHJlPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fPG86cD48L286cD48L3ByZT4NCjxwcmU+TmV0 Y29uZiBtYWlsaW5nIGxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48YSBocmVmPSJtYWlsdG86 TmV0Y29uZkBpZXRmLm9yZyI+TmV0Y29uZkBpZXRmLm9yZzwvYT48bzpwPjwvbzpwPjwvcHJlPg0K PHByZT48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldGNvbmYmYW1wO2Q9RHdN RC1nJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1w O3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1maV9v cGpqNGtpbzdldWZSWFNRU2k4ZFNqSk5sa1ZEbzhhMUYwenNDcmZFJmFtcDtzPW1jREYtdjVJNGVw Z3N1V0xIdnIzMnBaNW1Sb25ST0tOOHpwS2NaV0JDMG8mYW1wO2U9Ij5odHRwczovL3d3dy5pZXRm Lm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmY8L2E+PG86cD48L286cD48L3ByZT4NCjwvYmxv Y2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_14390982A1C240E5AEA1B03B02E8ACECjunipernet_-- From nobody Fri Feb 2 10:35:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0591112D82D for ; Fri, 2 Feb 2018 10:35:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.01 X-Spam-Level: X-Spam-Status: No, score=-0.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id s7B37ZnpdzTp for ; Fri, 2 Feb 2018 10:35:53 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 0C80D1252BA for ; Fri, 2 Feb 2018 10:35:53 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id p188so23881261ioe.12 for ; Fri, 02 Feb 2018 10:35:53 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=KH8flky5tGTWU+sQ7+7lotrISVyidXHmsWH4ll/SRJ4=; b=WLF1pQo75MkIE5mlMpNfr/JS4ul3kn2G4h/G2jv2XZmIuK8JGBiobNWwKpfrsqX/7d JPd9pLdAkYhtDUyJAQOP1N+OqG9As5IdcA42y/SuLifzxnhce9FuxSks7bPvWQW1Y47y cJPfOBq4hC64zSY6mv68qw9r//9Z1Uz2PO6geIh+vAXnp7swQLJ2BcxUmpVPHfxmRjDB bgFXTkfnhlEy0k4lnwDwCIvCXYlrR04o6K9mSfP0rIzFgHWhPKkO+pHagCkgfodk6l4r Xr/1oqpfdQaI5Eug8efp3TVsbEifNGmjnCrvnh+uSJE6cJ72p2v84RVmdNLHru59vZzO 1mKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=KH8flky5tGTWU+sQ7+7lotrISVyidXHmsWH4ll/SRJ4=; b=GNUiQDn19ohoRmRs/ywfvM69q4oFXSE2OAj4y0mW7Ks3Cd9jonzP76GMA04mxxl24N 16ISNoXu7TrLKcLmuuQGjBknwmIIKLzwravoZmoiVDLCJN+GC1K+aErv/KoMaTK/5qtu d7/IXt2qEBgXZyv+RW144PqyeCtA0BmR2I3UiVzLhs4iYJvuatbwU8YC0pR+qq1KMyWw skM2x0X573hWFEYWkldu4jhUOsy0ftfgCXKVv7Th6XCBpnL/hzgwYqV2HGxUifQVH4mW V1IJZyQAe9JV7fWOUHz188sUhupElfGncdlqp7tPzu5l7JVXrwSnJQPu1+fOw6LvhZI+ nN/g== X-Gm-Message-State: AKwxytdKj5wMkMA2kSS2Lv1fHTF7eJkeTBZXbU7tk8dqAaedPW6rTbSk MSauOpPiEHdUdYZz3xpyatH95J// X-Google-Smtp-Source: AH8x226GTXR+a8xUedCK+lLggIwtsfuTkhMyJJZ0/F/aIU2Bg2d4T/Wlviw+k6g7heR7y2HJfbfKAw== X-Received: by 10.107.9.213 with SMTP id 82mr45226242ioj.295.1517596552353; Fri, 02 Feb 2018 10:35:52 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:1c3b:9228:ac55:4210]) by smtp.gmail.com with ESMTPSA id i83sm1595485iod.82.2018.02.02.10.35.49 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Feb 2018 10:35:50 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_4DC644E7-4C35-41B0-9662-C9A4876EB821" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 2 Feb 2018 10:35:48 -0800 In-Reply-To: <543B7D01-A491-4BFB-B74B-786002F31022@juniper.net> Cc: Juergen Schoenwaelder , "netmod@ietf.org" To: Kent Watsen References: <8C19AD4C-0DCA-4D96-A070-0D76BE92BFA4@juniper.net> <20180117224916.4xtwnxgsw3snzwvf@elstar.local> <4EB04703-CD66-43D3-8653-BFC62B2C0FA1@gmail.com> <788291A3-8BB6-494A-A7CF-D68B3FC70F98@gmail.com> <543B7D01-A491-4BFB-B74B-786002F31022@juniper.net> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 02 Feb 2018 18:35:56 -0000 --Apple-Mail=_4DC644E7-4C35-41B0-9662-C9A4876EB821 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jan 22, 2018, at 7:50 AM, Kent Watsen wrote: >=20 > Hi Mahesh, > =20 > Thanks, it doesn't get much more concrete then a pull request ;) > =20 > Okay, so from a chair/shepherd perspective, can folks please consider = this update to -15 as the LC solution to removing the open issue Juergen = found in the draft? > =20 > As a contributor, I don't think the name of the groupings or their = description statements should allude to something that doesn't exist = yet. Rather than e.g. "source-or-group", could it be instead something = like "source-type"? Also, the update seems to be for both when = specifying networks as well as when specifying port-ranges, but the = original issue (see below) only mentioned addresses - is the = pull-request actually what's needed and the description of the issue in = Section 8 is incomplete? > =20 > 8. Open Issues > =20 > o The current model does not support the concept of = "containers" > used to contain multiple addresses per rule entry. I have updated the description of the issue on GitHub to refer to IP = addresses and ports, the two thing object groups are used for, and = removed the Open Issues section in the draft. The PR(#23) has the = capability to add this in the future.=20 Thanks. > =20 > Thanks, > Kent > =20 > =20 > On 1/21/18, 12:32 AM, "Mahesh Jethanandani" > wrote: > =20 > =20 >=20 >=20 >> On Jan 20, 2018, at 7:21 AM, Kent Watsen > wrote: >> =20 >> Hi Mahesh, >>=20 >> I'm okay not adding the ability to reference an external rulebase = now, or are you saying that you'd also like to defer priming the YANG = model now so that it can be added later in a backwards compatible = manner? >>=20 >> If you plan to prime the YANG model so that the ability to reference = an external rulebase can added later in a backwards compatible manner, = can you please send a concrete proposal to the list so that we can = better understand the impact? =20 >>=20 >> My expectation is that it merely adds a 'choice' statement around the = existing rulebase container, thereby enabling something other than a = rulebase container to exist some day in the future. =20 > =20 > That is correct. The proposal is to add a =E2=80=98choice=E2=80=99 = statement in parts of the model that will allow an external rulebase to = be added in the future as another case statement. > =20 > Here is the concrete proposal of what those changes will look like: > =20 > https://github.com/netmod-wg/acl-model/pull/23 = > =20 > Thanks > =20 >=20 >>=20 >> If the addition is indeed just this, then I don't believe that it = materially changes the ACL model and therefore can be added as a LC = comment. Of course, the WG will want to review the addition for = correctness, but otherwise should be alright. >>=20 >> Thanks, >> Kent // co-chair and shepherd >>=20 >>=20 >> =3D=3D=3D=3D=3D original message =3D=3D=3D=3D=3D >>=20 >> Kent, >>=20 >> I have not heard a strong requirement to have the open issue fixed in = this version of the RFC. We would therefore like to defer it to a bis = document. >>=20 >> I will wait for the LC to complete, and update the draft to address = all the comments received during the LC. >>=20 >> Thanks. >>=20 >>=20 >>> On Jan 17, 2018, at 3:33 PM, Kent Watsen > wrote: >>>=20 >>>=20 >>> H Mahesh, >>>=20 >>>=20 >>>>> - There is an open issue in the document (section 8) - are we = going >>>>> to resolve that during WG last call or is this a leftover? >>>>=20 >>>> This will be resolved in the next version of the module. It is >>>> documented under Issues tab in GitHub. Should we remove it from >>>> the draft? >>>=20 >>> Most of Juergen's comments are editorial in nature and can truly be = handled as part of the LC process, but this open issue has me worried, = as it may result in a significant technical change. =20 >>>=20 >>> What will it take to close this open issue? Is it just a matter of = the getting the WG to agree that it's not an issue, or do we already = know that it is a real issue and only the solution is pending? >>>=20 >>> Thanks, >>> Kent >>>=20 >>>=20 >>>=20 >>>=20 >>=20 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 >>=20 >=20 > =20 > Mahesh Jethanandani > mjethanandani@gmail.com >=20 >=20 Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_4DC644E7-4C35-41B0-9662-C9A4876EB821 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jan 22, 2018, at 7:50 AM, Kent Watsen <kwatsen@juniper.net>= wrote:

Hi Mahesh,
 
Thanks, it doesn't get much = more concrete then a pull request  ;)
 
Okay, so from a chair/shepherd = perspective, can folks please consider this update to -15 as the LC = solution to removing the open issue Juergen found in the draft?
 
As a contributor, I don't think = the name of the groupings or their description statements should allude = to something that doesn't exist yet.  Rather than e.g. = "source-or-group", could it be instead something like "source-type"?    Also, the update seems to be for = both when specifying networks as well as when specifying port-ranges, = but the original issue (see below) only mentioned addresses - is the = pull-request actually what's needed and the description of the issue in Section 8 is incomplete?
 
    8.  = Open Issues
 
  =      o  The current model does not support = the concept of "containers"
  =           used to = contain multiple addresses per rule = entry.

I have updated the description of the issue on GitHub = to refer to IP addresses and ports, the two thing object groups are used = for, and removed the Open Issues section in the draft. The PR(#23) has = the capability to add this in the future. 

Thanks.

 
Thanks,
Kent
 
 
On 1/21/18, 12:32 AM, "Mahesh = Jethanandani" <mjethanandani@gmail.com> wrote:
 
 


On Jan 20, 2018, at 7:21 AM, = Kent Watsen <kwatsen@juniper.net> wrote:
 
Hi Mahesh,

I'm okay not adding the ability to reference an external rulebase now, = or are you saying that you'd also like to defer priming the YANG model = now so that it can be added later in a backwards compatible manner?

If you plan to prime the YANG model so that the ability to reference an = external rulebase can added later in a backwards compatible manner, can = you please send a concrete proposal to the list so that we can better = understand the impact?  

My expectation is that it merely adds a 'choice' statement around the = existing rulebase container, thereby enabling something other than a = rulebase container to exist some day in the future.  
 
That is correct. The proposal is to add a = =E2=80=98choice=E2=80=99 statement in parts of the model that will allow = an external rulebase to be added in the future as another case = statement.
 
Here is the concrete proposal = of what those changes will look like:
 
https://github.com/netmod-wg/acl-model/pull/23
 
Thanks
 


If the addition is indeed just this, then I don't believe that it = materially changes the ACL model and therefore can be added as a LC = comment.  Of course, the WG will want to review the addition for = correctness, but otherwise should be alright.

Thanks,
Kent // co-chair and shepherd


=3D=3D=3D=3D=3D original message =3D=3D=3D=3D=3D

Kent,

I have not heard a strong requirement to have the open issue fixed in = this version of the RFC. We would therefore like to defer it to a bis = document.

I will wait for the LC to complete, and update the draft to address all = the comments received during the LC.

Thanks.


On Jan 17, 2018, at 3:33 PM, Kent = Watsen <kwatsen@juniper.net> wrote:


H Mahesh,


- There is an open issue in the = document (section 8) - are we going
to resolve that during WG last call or is this a leftover?

This will be resolved in the next version of the module. It is
documented under Issues tab in GitHub. Should we remove it from
the draft?


Most of Juergen's comments are editorial in nature and can truly be = handled as part of the LC process, but this open issue has me worried, = as it may result in a significant technical change.  

What will it take to close this open issue?  Is it just a matter of = the getting the WG to agree that it's not an issue, or do we already = know that it is a real issue and only the solution is pending?

Thanks,
Kent




Mahesh Jethanandani
mjethanandani@gmail.com


 
Mahesh Jethanandani
mjethanandani@gmail.com



Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_4DC644E7-4C35-41B0-9662-C9A4876EB821-- From nobody Fri Feb 2 16:06:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D3D6124D37 for ; Fri, 2 Feb 2018 16:06:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vs7EeDq_bmOH for ; Fri, 2 Feb 2018 16:05:58 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 822FF1200B9 for ; Fri, 2 Feb 2018 16:05:58 -0800 (PST) Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1303t7i026109 for ; Fri, 2 Feb 2018 16:05:57 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=ttfH6Divb2kkauFfY9uUbgPNdsjJvcF53TR3LLHU7jc=; b=Kzq5EQwg/wyWDpOXFdZM3r+9MF3OeokrEiuPuUp1ZNu2sgojxlGi+9ohjELXcoUro8f7 Komz5yZyyI8ElPOaD1NQG7olzOrsjKNMbnzB7kfxlcRLhmHGIwN1tWinNKJ43mtbNXND eeYpHMKEoS2s6XUey17/wZ1t5qvHAAYL7drcFrdCnXigOrKpwMaaPk9Mp8SJijjaUglT pGme6SJTFxegjhKNfR+xIPTNCr9JV3TmxxbRjRDk0v/qFk8DLhcU428urTgRbhW2noVq 4a41Dx+DvzrdtwusCOGBJc85EIbPdqBaWnXBMHP7BaYFNOoQcQt2bYSKv0A4oeDj5SCA 4Q== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0023.outbound.protection.outlook.com [216.32.180.23]) by mx0b-00273201.pphosted.com with ESMTP id 2fw25t006p-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT) for ; Fri, 02 Feb 2018 16:05:57 -0800 Received: from MWHPR05MB3486.namprd05.prod.outlook.com (10.174.248.37) by MWHPR05MB2847.namprd05.prod.outlook.com (10.168.245.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.464.6; Sat, 3 Feb 2018 00:05:55 +0000 Received: from MWHPR05MB3486.namprd05.prod.outlook.com ([10.174.248.37]) by MWHPR05MB3486.namprd05.prod.outlook.com ([10.174.248.37]) with mapi id 15.20.0464.012; Sat, 3 Feb 2018 00:05:55 +0000 From: Kent Watsen To: "netmod@ietf.org" Thread-Topic: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 Thread-Index: AQHTnILCbv6W+PCjZkunY202Xmd17g== Date: Sat, 3 Feb 2018 00:05:55 +0000 Message-ID: <4D7DDD59-0572-46B9-8616-89D06995CB12@juniper.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.12] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; MWHPR05MB2847; 7:ykAQvhnF5JEmYAIvZFWsxVxbQmDsRqJHJAdMgtS+MzYEyLEZu9gwYFp/8D5mQR6WeM1NxLgHI5S6FZrZEUlWoGUgEmI6nedYTyqY2AqM64HbwVVhxk7g/YqD9DKsA4ovkt/0FepKVxYh1ijBqEjYMsiEtBnPeB8rGDZQFVjh7nS8BrDZpkGPY2uub2EkgflmSZIicFqm342dVOmrFrxpvpgwpc4rzpWGOneJGMKRRoQt44qY6uT4slK4WcyJWHEy x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: d99812b0-bac2-4d79-b120-08d56a99e59b x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:MWHPR05MB2847; x-ms-traffictypediagnostic: MWHPR05MB2847: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(3002001)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123560045)(20161123562045)(6072148)(201708071742011); SRVR:MWHPR05MB2847; BCL:0; PCL:0; RULEID:; SRVR:MWHPR05MB2847; x-forefront-prvs: 05724A8921 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(346002)(376002)(366004)(39380400002)(189003)(199004)(105586002)(36756003)(186003)(966005)(305945005)(26005)(478600001)(14454004)(106356001)(97736004)(33656002)(81166006)(1730700003)(8676002)(81156014)(7736002)(3280700002)(58126008)(8936002)(59450400001)(53936002)(5660300001)(2351001)(6246003)(25786009)(99286004)(6506007)(3660700001)(575784001)(5640700003)(6512007)(6486002)(6436002)(6306002)(82746002)(83716003)(316002)(83506002)(102836004)(66066001)(2900100001)(68736007)(77096007)(2906002)(229853002)(86362001)(6116002)(6916009)(2501003)(3846002); DIR:OUT; SFP:1102; SCL:1; SRVR:MWHPR05MB2847; H:MWHPR05MB3486.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) x-microsoft-antispam-message-info: LizPTrz3NQxXB+iJu5Q933WATklM3BhXtH4C7qxpRjnn+ZfEgYaYfwgcARhIHHT/BTpWRLCNe5mUJB/DGrT7Mw== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: d99812b0-bac2-4d79-b120-08d56a99e59b X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Feb 2018 00:05:55.6738 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: MWHPR05MB2847 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-02_04:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802020287 Archived-At: Subject: Re: [netmod] WG Last Call: draft-ietf-netmod-acl-model-15 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 00:06:00 -0000 DQpBbGwsIA0KDQpUaGlzIG1lc3NhZ2UgY2xvc2VzIHRoZSBMYXN0IENhbGwgb24gdGhlIEFDTCBk cmFmdC4gIA0KDQpBZnRlciBhIG51bWJlciBvZiBydW4tdXBzLCBpdCBzZWVtcyB0aGF0IHdlIG5v dyBoYXZlDQphIGRyYWZ0IHRoYXQgZm9sa3MgYXJlIGhhcHB5IHdpdGguICBUaGFuayB5b3UgZXZl cnlvbmUNCmludm9sdmVkLg0KDQpJdCdzIHVuZGVyc3Rvb2QgdGhhdCBvYmplY3QgZ3JvdXBpbmdz IGFyZSBkZXNpcmFibGUuDQpUaG91Z2ggd2UncmUgbm90IGFkZGluZyBvYmplY3QgZ3JvdXBpbmdz IG5vdywgd2UgYXJlDQphZGRpbmcgJ2Nob2ljZScgc3RhdGVtZW50cyBlbmFibGluZyB0aGVtIHRv IGJlIGFkZGVkDQpsYXRlci4NCg0KQXV0aG9ycywgcGxlYXNlIHBvc3QgYW4gdXBkYXRlZCBkcmFm dCBhZGRyZXNzaW5nIHRoZQ0KTGFzdCBDYWxsIGNvbW1lbnRzIHJlY2VpdmVkLiAgUGxlYXNlIHJl cXVlc3QgdGhlDQpjb21tZW50ZXJzIHRvIGNvbmZpcm0gdGhhdCB0aGVpciBjb25jZXJucyBoYXZl IGJlZW4NCmFkZHJlc3NlZC4gICBPbmNlIHRoaXMgaXMgZG9uZSwgSSB3aWxsIGRvIHRoZSBzaGVw aGVyZA0Kd3JpdGUtdXAgb24gdGhlIGRyYWZ0LiANCg0KVGhhbmtzLA0KS2VudA0KDQo9PT09PSBv cmlnaW5hbCBtZXNzYWdlID09PT09DQoNCkFsbCwNCg0KVGhpcyBzdGFydHMgYSB0d28td2VlayB3 b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBvbg0KZHJhZnQtaWV0Zi1uZXRtb2QtYWNsLW1vZGVsLTE1 Lg0KDQpUaGlzIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIGVuZHMgb24gSmFudWFyeSAzMXN0Lg0K UGxlYXNlIHNlbmQgeW91ciBjb21tZW50cyB0byB0aGUgTkVUTU9EIG1haWxpbmcgbGlzdC4NCg0K UG9zaXRpdmUgY29tbWVudHMsIGUuZy4sICJJJ3ZlIHJldmlld2VkIHRoaXMgZG9jdW1lbnQNCmFu ZCBiZWxpZXZlIGl0IGlzIHJlYWR5IGZvciBwdWJsaWNhdGlvbiIsIGFyZSB3ZWxjb21lIQ0KVGhp cyBpcyB1c2VmdWwgYW5kIGltcG9ydGFudCwgZXZlbiBmcm9tIGF1dGhvcnMuDQoNCkFsc28sIGNv dWxkIHRoZSBhdXRob3JzLCBleHBsaWNpdGx5IENDLWVkIG9uIHRoaXMgZW1haWwsDQpwbGVhc2Ug Y29uZmlybSBhdCB0aGlzIHRpbWUgdGhhdCB0aGV5IGFyZSB1bmF3YXJlIG9mDQphbnkgSVBSIHJl bGF0ZWQgdG8gdGhpcyBkcmFmdC4NCg0KVGhhbmsgeW91LA0KTkVUTU9EIENoYWlycw0KDQpfX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxp bmcgbGlzdA0KbmV0bW9kQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j b20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1v ZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0km cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09V2lSOHdOdWZF V1hPTVFjbWNCMFU0MnFrSEM0TnJXc19NVTRXdnYzLXNkOCZzPVluLVhPakdqdlZlZTFrSzhVeHV4 Yml0SFN5OVBxcnE4Z0pPRnM4UTM3R0UmZT0NCg0KDQo= From nobody Fri Feb 2 17:26:27 2018 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 5C01D124235; Fri, 2 Feb 2018 17:26:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151762118030.14613.16606991699665016537@ietfa.amsl.com> Date: Fri, 02 Feb 2018 17:26:20 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-acl-model-16.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 01:26:20 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Network Access Control List (ACL) YANG Data Model Authors : Mahesh Jethanandani Lisa Huang Sonal Agarwal Dana Blair Filename : draft-ietf-netmod-acl-model-16.txt Pages : 54 Date : 2018-02-02 Abstract: This document describes a data model of Access Control List (ACL) basic building blocks. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. Please note that no other RFC Editor instructions are specified anywhere else in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements o "XXXX" --> the assigned RFC value for this draft both in this draft and in the YANG models under the revision statement. o Revision date in model needs to get updated with the date the draft gets approved. The date also needs to get reflected on the line with . The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-16 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-16 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 2 17:41:29 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF294126E01 for ; Fri, 2 Feb 2018 17:41:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n8IDRKUzr-b4 for ; Fri, 2 Feb 2018 17:41:24 -0800 (PST) Received: from mail-io0-x230.google.com (mail-io0-x230.google.com [IPv6:2607:f8b0:4001:c06::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 8D695126DFF for ; Fri, 2 Feb 2018 17:41:24 -0800 (PST) Received: by mail-io0-x230.google.com with SMTP id n7so24830433iob.0 for ; Fri, 02 Feb 2018 17:41:24 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:content-transfer-encoding:mime-version:subject:date:references :to:in-reply-to:message-id; bh=vgzNpN8EdwMHxNxpeiSyXhC6SX8IxYIVAA6vQO4mClM=; b=Ef7o3ex2Bh+sA6Hv/99wnSJk5kKTxwzgiKOj+N2eFABJojovA6dC7AaEzo/k5ZEhaP 57Y9vA8PspTHZlZpsrMgKsI2vyCYP9/NyT2rx3Z6RBH0j2d+tNHFkMnVxxUw7OeoPHK2 2FMU5jnQ9vWqUnXJhDtM+o0vGlwr9xjsx7jJ9YSQaTufbBTtacos7RGOO/KGz4koX/MJ wAtlZhnY5EE9xbG+dwEMFY4lv5/Zuynaiw0qCIj0pHinI8zdG7Ft7G1U34Mi1nzEqXTu Hj+9bH1FJAP2aU4aghKIhSdrXHv8zcRV/oKb8vzvk83FF6rmz0h7UIeZEHoPK+oMZFan nx2w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:content-transfer-encoding:mime-version :subject:date:references:to:in-reply-to:message-id; bh=vgzNpN8EdwMHxNxpeiSyXhC6SX8IxYIVAA6vQO4mClM=; b=QKcXqdKiiZWbXpitvS5YlNQBU666liTLjQ/EpA2E3/bLrxUZTn6dpdogv68fW/n5ZI aiiGffJ986UnYLvlLjtPgqbZohQAOxxT25BciUJU3/SeXzekdIj/kcjbgRqz5ANnaBBs dP8imaW0FNlWDT7iIrVWY5XL2BQFbZ+tcWvZKzDCgJK/6WC1eDpGE1UKtl/Unj49Jquh laB/lxwdJagvg+NHxKdg0LrUzYfn8fGbCxHO4xw+5x9MKRTWpaNmUGEwx7EPWIkyBVML Wvxw3GxfIrPe1xCYcT81mJR4kb/mYSYqYNKxHidmDLZtHWwz6lU1v1Zkt+iKqOEYEwGp FYtA== X-Gm-Message-State: AKwxytfnMZeEJSeVF0ZqAt+SAX3pIeI88DYzttGshWkW6gKyd/P4GHrs +5o38J9U44VlMBkn9e1XqaaodBo3 X-Google-Smtp-Source: AH8x226yoPjuQNdwNAavizfnWXUW1kMO/Wt9dWLodBdWzvWaceK8ZKtd0MlCNuhk4NUU3NgBWor3DQ== X-Received: by 10.107.203.5 with SMTP id b5mr1391256iog.144.1517622083664; Fri, 02 Feb 2018 17:41:23 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:1c3b:9228:ac55:4210]) by smtp.gmail.com with ESMTPSA id z1sm1823041itg.37.2018.02.02.17.41.22 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 02 Feb 2018 17:41:22 -0800 (PST) From: Mahesh Jethanandani Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Fri, 2 Feb 2018 17:41:21 -0800 References: <151762118030.14613.16606991699665016537@ietfa.amsl.com> To: NETMOD WG In-Reply-To: <151762118030.14613.16606991699665016537@ietfa.amsl.com> Message-Id: <37914E8C-1A57-4ECF-A865-D8880169F454@gmail.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-16.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 03 Feb 2018 01:41:27 -0000 This update addresses the comments that were received as part of LC. For = those of you who commented on the draft during the LC, please verify = that your comments have been addressed. Thanks. > On Feb 2, 2018, at 5:26 PM, internet-drafts@ietf.org wrote: >=20 >=20 > A New Internet-Draft is available from the on-line Internet-Drafts = directories. > This draft is a work item of the Network Modeling WG of the IETF. >=20 > Title : Network Access Control List (ACL) YANG Data = Model > Authors : Mahesh Jethanandani > Lisa Huang > Sonal Agarwal > Dana Blair > Filename : draft-ietf-netmod-acl-model-16.txt > Pages : 54 > Date : 2018-02-02 >=20 > Abstract: > This document describes a data model of Access Control List (ACL) > basic building blocks. >=20 > Editorial Note (To be removed by RFC Editor) >=20 > This draft contains many placeholder values that need to be replaced > with finalized values at the time of publication. This note > summarizes all of the substitutions that are needed. Please note > that no other RFC Editor instructions are specified anywhere else in > this document. >=20 > Artwork in this document contains shorthand references to drafts in > progress. Please apply the following replacements >=20 > o "XXXX" --> the assigned RFC value for this draft both in this > draft and in the YANG models under the revision statement. >=20 > o Revision date in model needs to get updated with the date the > draft gets approved. The date also needs to get reflected on the > line with . >=20 >=20 > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ >=20 > There are also htmlized versions available at: > https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 > https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-16 >=20 > A diff from the previous version is available at: > https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-16 >=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 Mahesh Jethanandani mjethanandani@gmail.com From nobody Sun Feb 4 01:24:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F597124C27 for ; Sun, 4 Feb 2018 01:24:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XEuo1xseWn0g for ; Sun, 4 Feb 2018 01:24:15 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA9FE1241FC for ; Sun, 4 Feb 2018 01:24:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1961; q=dns/txt; s=iport; t=1517736255; x=1518945855; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=wIVPHEmsZoSPv4eXrBo54V3knYSRMLquc40FZtyb2B8=; b=EIttYRGmZIhunKQHdsM4fTca8CXMQZSZXuMv7bFV7bi75EEpjeS/5jZP I0Pn59vRd737kzPsleKHWTrQu5pKjamQ60+q7ODOyLMKna7A1Tfd7UKhT aBfhW1eUPHiFhwiLrQwDHGbLboul7sjDf8gnw5MUYh/+ezDbW6OMC0uYD s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQDH0HZa/xbLJq1aGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ3cCiOfY87mWAKGAuESU8CgxAUAQEBAQEBAQECayiFJAEBBAE?= =?us-ascii?q?BMAEFNgsQCw4KLicwBgEMBgIBAYoxEMIThQCDcoIGAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEZBYRqg2yBaCmDBYMvAQECh2sFkkWRYIwbiVaMN4gAj1+IF4E8NiKBUDM?= =?us-ascii?q?aCBsVPYJGhHhAN4wlAQEB?= X-IronPort-AV: E=Sophos;i="5.46,458,1511827200"; d="scan'208";a="1844971" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2018 09:24:03 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w149O3d3010076; Sun, 4 Feb 2018 09:24:03 GMT To: Martin Bjorklund , mvasko@cesnet.cz Cc: netmod@ietf.org References: <4f1c-5a703c80-79-5fc7eb00@206654228> <20180130.160056.1269600856222747465.mbj@tail-f.com> From: Benoit Claise Message-ID: Date: Sun, 4 Feb 2018 10:24:03 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180130.160056.1269600856222747465.mbj@tail-f.com> Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] YANG tree diagram uses X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 04 Feb 2018 09:24:17 -0000 Martin, Michal, Do we need any clarification in the draft? Regards, B. > Michal Va¨ko wrote: >> Hi, >> >> we have encountered some problem while implementing a feature from >> draft-ietf-netmod-yang-tree-diagrams-05, specifically not resolving >> groupings and printing uses names instead (Section 2.2). >> >> We have 2 example models, A and B. A defines a container and a >> grouping. B defines an augment that adds uses into the container from >> A and resolves to the grouping from model A. >> >> grouping A:g; >> A:c { >> B:uses A:g; >> } >> >> Now, if printing model A with the augment not resolving uses we >> currently print >> >> +--rw c >> +---u B:A:g; > pyang prints this as well, but it is more "by accident". It looks > quite odd. > > It wouldn't be correct to write > > +---u B:g; > > since 'g' isn't defined in B. > > OTOH, > > +---u A:g; > > is correct in the sense that "A:g" is the "name of the grouping", and > that is what the current document says should be printed. Granted, > this doesn't show the whole picture, but maybe this is good enough. > > It might be wise to not print a grouping like this in order to avoid > confusion. > > > /martin > > >> since the uses is foreign. We could not decide what the "correct" >> output should be and it is likely left to various interpretations but >> we were wondering what some of you think. Should it perhaps be only >> "B:g" since the grouping becomes local? But what if the grouping would >> be from a third model, are 2 prefixes okay? Thanks for your opinions. >> >> Regards, >> Michal >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >> > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > From nobody Mon Feb 5 05:42:33 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6802612D7EA for ; Mon, 5 Feb 2018 05:42:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.8 X-Spam-Level: X-Spam-Status: No, score=-1.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, T_DKIM_INVALID=0.01, T_RP_MATCHES_RCVD=-0.01] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (body has been altered)" 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 qOIUhXxnDpvY for ; Mon, 5 Feb 2018 05:42:29 -0800 (PST) Received: from kalendar.cesnet.cz (kalendar.cesnet.cz [IPv6:2001:718:1:1f:50:56ff:feee:34]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D872512D7E9 for ; Mon, 5 Feb 2018 05:42:28 -0800 (PST) Received: by kalendar.cesnet.cz (Postfix, from userid 999) id 08C7B604DB; Mon, 5 Feb 2018 14:42:25 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=kalendar; t=1517838145; bh=+5STxaOCsN5JgQ0XEWOuOObM1hC+m4UEbCH2l4ZMcis=; h=In-Reply-To:From:Date:Cc:To:Subject; b=XrfXIRJ9sM90ICd21XxP2vyeCBs2+1aBzObeZwDYlughqNOBSnyYJ6phBKOOIr6Lx Ibs8RiJpWLtgpzfwg71tKhqqG1k2wle3yr7QoSTZv7QZeVUc+777rneMEsctR4Ee4u 7qv7HbW9Pe4mMUmdS8awAvZX9VeT5OG+iFfc/hFY= Content-Type: text/plain; charset="utf-8" In-Reply-To: From: =?utf-8?q?Michal_Va=C5=A1ko?= X-Forward: 2001:67c:1220:80c:f5:8e35:ef0e:146c Date: Mon, 05 Feb 2018 14:42:25 +0100 Cc: netmod@ietf.org To: "Martin Bjorklund" , "Benoit Claise" MIME-Version: 1.0 Message-ID: <7231-5a785f80-79-79ec2a00@42055075> User-Agent: SOGoMail 2.3.23 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] =?utf-8?b?Pz09P3V0Zi04P3E/ICBZQU5HIHRyZWUgZGlhZ3JhbSB1?= =?utf-8?q?ses?= X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 13:42:31 -0000 Hi Benoit, the way I understand it is that the draft tries to mention only the cor= e Tree Diagram characteristics and formatting leaving the details imple= mentation-specific. I was simply asking for another opinion on how to h= andle an implementation detail, I think the draft fulfils the mentioned= purpose just fine. Regards, Michal On Sunday, February 4, 2018 10:24 CET, Benoit Claise wrote: > Martin, Michal, > > Do we need any clarification in the draft? > > Regards, B. > > Michal Va=C5=A1ko wrote: > >> Hi, > >> > >> we have encountered some problem while implementing a feature from= > >> draft-ietf-netmod-yang-tree-diagrams-05, specifically not resolvin= g > >> groupings and printing uses names instead (Section 2.2). > >> > >> We have 2 example models, A and B. A defines a container and a > >> grouping. B defines an augment that adds uses into the container f= rom > >> A and resolves to the grouping from model A. > >> > >> grouping A:g; > >> A:c { > >> B:uses A:g; > >> } > >> > >> Now, if printing model A with the augment not resolving uses we > >> currently print > >> > >> +--rw c > >> +---u B:A:g; > > pyang prints this as well, but it is more "by accident". It looks= > > quite odd. > > > > It wouldn't be correct to write > > > > +---u B:g; > > > > since 'g' isn't defined in B. > > > > OTOH, > > > > +---u A:g; > > > > is correct in the sense that "A:g" is the "name of the grouping", a= nd > > that is what the current document says should be printed. Granted,= > > this doesn't show the whole picture, but maybe this is good enough.= > > > > It might be wise to not print a grouping like this in order to avoi= d > > confusion. > > > > > > /martin > > > > > >> since the uses is foreign. We could not decide what the "correct"= > >> output should be and it is likely left to various interpretations = but > >> we were wondering what some of you think. Should it perhaps be onl= y > >> "B:g" since the grouping becomes local? But what if the grouping w= ould > >> be from a third model, are 2 prefixes okay? Thanks for your opinio= ns. > >> > >> Regards, > >> Michal > >> > >> =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F > >> netmod mailing list > >> netmod@ietf.org > >> https://www.ietf.org/mailman/listinfo/netmod > >> > > =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= =5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F=5F= > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > From nobody Mon Feb 5 09:43:36 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C952B12D863; Mon, 5 Feb 2018 09:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j4C6H6D-AQQB; Mon, 5 Feb 2018 09:43:27 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C365312D87C; Mon, 5 Feb 2018 09:43:13 -0800 (PST) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id EE9571AE0397; Mon, 5 Feb 2018 18:43:12 +0100 (CET) Date: Mon, 05 Feb 2018 18:43:12 +0100 (CET) Message-Id: <20180205.184312.338993520253253388.mbj@tail-f.com> To: mjethanandani@gmail.com Cc: netconf@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com> <20180131181619.ziqdv5peqdeeuhl4@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 17:43:30 -0000 SGksDQoNCk1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPiB3cm90 ZToNCj4gVGhpcyBjbG9zZXMgdGhlIExDIGZvciB0aGUgdHdvIE5ETUEgZHJhZnRzIGZvciBORVRD T05GIGFuZCBSRVNUQ09ORi4NCj4gDQo+IEFzIHBhcnQgb2YgdGhlIExDLCB0aGVyZSB3ZXJlIGEg Y291cGxlIG9mIGNvbW1lbnRzL3F1ZXN0aW9ucw0KPiByYWlzZWQuIEluIHBhcnRpY3VsYXIgDQo+ IA0KPiAtIFZsYWRtaXIgcmVwb3J0ZWQgYW4gZXJyb3IsIHdoaWNoIE1hcnRpbiBzYWlkIGlzIGZp eGVkIGluIGhpcyBsb2NhbCBjb3B5Lg0KDQpGaXhlZC4NCg0KPiAtIFJvYmVydCBzdWdnZXN0ZWQg dGhhdCDigJwveWFuZy1saWJyYXJ5L2NoZWNrc3Vt4oCdIHNob3VsZCBiZSBhDQo+ICAgcmVmZXJl bmNlLiBKdWVyZ2VuIHN1cHBvcnRlZCB0aGF0IGNvbW1lbnQsIHNvIEkgYW0gYXNzdW1pbmcgdGhh dA0KPiAgIHRoYXQgd2lsbCBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgZHJhZnQuDQoNClllcywg Zml4ZWQuDQoNCj4gLSBBbmR5IGhhZCBxdWVzdGlvbnMgYXJvdW5kIGRhdGFzdG9yZSBzZXQgdG8g 4oCcY29udmVudGlvbmFs4oCdDQoNCkZpeGVkLg0KDQo+ICAgLCBhYm91dCBvcmlnaW4gZmlsdGVy IGxpbWl0ZWQgdG8gMSBzb3VyY2UNCg0KRml4ZWQuDQoNCj4gICBhbmQgdGhlIGJlaGF2aW9yIG9m IHdpdGgtZGVmYXVsdHMuDQoNClRoZXJlIHdlcmUgbm8gYWRkaXRpb25hbCBjaGFuZ2VzIHRvIHRo ZSBkb2N1bWVudCBmcm9tIHRoZSBkaXNjdXNzaW9uDQphYm91dCB0aGlzLg0KDQo+ICAgSSBzZWUg c29tZSBkaXNjdXNzaW9uIGFyb3VuZCBpdCB3aXRoIHRoZSBhdXRob3JzDQo+ICAgYWdyZWVpbmcg dGhhdCBzb21lIG9mIHRoZW0gbmVlZCBzb21lIHRleHQgY2xhcmlmeWluZyB0aGUNCj4gICBwb3Np dGlvbi4gQ2FuIHRoZSBhdXRob3JzIHBsZWFzZSBwb3N0IHRoZSBzdWdnZXN0ZWQgdGV4dC9hZGRp dGlvbnMNCj4gICBmb3IgdGhlIFdHIHRvIHJldmlldy4gDQo+IC0gQW55dGhpbmcgZWxzZT8/DQo+ IA0KPiBPbmNlIGFuIHVwZGF0ZWQgZHJhZnQgaGFzIGJlZW4gcG9zdGVkLCBJIHdpbGwgZG8gYSB3 cml0ZXVwIG9uIHRoZQ0KPiBkcmFmdHMgYW5kIHNlbmQgaXQgdG8gSUVTRy4gIA0KDQpUaGUgaXNz dWVzIGFib3ZlIGFyZSBub3cgYWRkcmVzc2VkLCBpbg0KZHJhZnQtaWV0Zi1uZXRjb25mLW5tZGEt bmV0Y29uZi0wMy4NCg0KVGhlcmUgd2VyZSBubyBhZGRpdGlvbmFsIGNvbW1lbnRzIG9uDQpkcmFm dC1pZXRmLW5ldGNvbmYtbm1kYS1yZXN0Y29uZi0wMiwgc28gSSBiZWxpZXZlIHRoaXMgdmVyc2lv biBpcw0KcmVhZHkuDQoNCg0KL21hcnRpbg0KDQoNCj4gDQo+IFRoYW5rcy4NCj4gDQo+ID4gT24g SmFuIDMxLCAyMDE4LCBhdCAxMDoxNiBBTSwgSnVlcmdlbiBTY2hvZW53YWVsZGVyIDxqLnNjaG9l bndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGU+IHdyb3RlOg0KPiA+IA0KPiA+IE9uIFdlZCwg SmFuIDMxLCAyMDE4IGF0IDA0OjUzOjQ4UE0gKzAwMDAsIEVyaWMgVm9pdCAoZXZvaXQpIHdyb3Rl Og0KPiA+PiANCj4gPj4gSSBkbyBoYXZlIG9uZSBhZGRpdGlvbmFsIHRob3VnaHQgYmVsb3cgb24g ZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzIHNlY3Rpb24gNS4zIGRlZmF1bHQg aGFuZGxpbmcgcHJvY2Vzcy4gIFNlZSBpbi1saW5lLi4uDQo+ID4+IA0KPiA+IA0KPiA+IFdlbGws IHRoaXMgZG9jdW1lbnQgaXMgd2l0aCB0aGUgUkZDIGVkaXRvciBub3cuIEkgZG8gbm90IHRoaW5r IGl0IG5lZWRzDQo+ID4gY2xhcmlmaWNhdGlvbi4gSXQgYWxyZWFkeSBoYXMgdGV4dCBpbiA1LjMg c3VjaCBhczoNCj4gPiANCj4gPiAgIFJlcXVlc3RzIHRvIHJldHJpZXZlIG5vZGVzIGZyb20gPG9w ZXJhdGlvbmFsPiBhbHdheXMgcmV0dXJuIHRoZSB2YWx1ZQ0KPiA+ICAgaW4gdXNlIGlmIHRoZSBu b2RlIGV4aXN0cywgcmVnYXJkbGVzcyBvZiBhbnkgZGVmYXVsdCB2YWx1ZSBzcGVjaWZpZWQNCj4g PiAgIGluIHRoZSBZQU5HIG1vZHVsZS4gIElmIG5vIHZhbHVlIGlzIHJldHVybmVkIGZvciBhIGdp dmVuIG5vZGUsIHRoZW4NCj4gPiAgIHRoaXMgaW1wbGllcyB0aGF0IHRoZSBub2RlIGlzIG5vdCB1 c2VkIGJ5IHRoZSBkZXZpY2UuDQo+ID4gDQo+ID4gL2pzDQo+ID4gDQo+ID4+IEZyb206IFJvYmVy dCBXaWx0b24gLVgsIEphbnVhcnkgMzEsIDIwMTggNjozMSBBTQ0KPiA+PiANCj4gPj4gDQo+ID4+ IEhpIEFuZHksDQo+ID4+IA0KPiA+PiBPbiAzMS8wMS8yMDE4IDA5OjIyLCBBbmR5IEJpZXJtYW4g d3JvdGU6DQo+ID4+IA0KPiA+PiANCj4gPj4gT24gV2VkLCBKYW4gMzEsIDIwMTggYXQgMTI6MTEg QU0sIEp1ZXJnZW4gU2Nob2Vud2FlbGRlciA8ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJz aXR5LmRlIDxtYWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPjxtYWls dG86ai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIDxtYWlsdG86ai5zY2hvZW53 YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlPj4+IHdyb3RlOg0KPiA+PiBPbiBUdWUsIEphbiAz MCwgMjAxOCBhdCAxMjozNTozM1BNIC0wODAwLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ID4+PiBI aSwNCj4gPj4+IA0KPiA+Pj4gSSBoYXZlIHNvbWUgcXVlc3Rpb25zIGFib3V0IHRoZXNlIGRyYWZ0 cy4NCj4gPj4+IA0KPiA+Pj4gMSkgd2hhdCBpZiBkYXRhc3RvcmUgc2V0IHRvICJjb252ZW50aW9u YWwiPw0KPiA+Pj4gICAgVGhlcmUgYXJlIG1hbnkgcGxhY2VzIHdoZXJlIGEgZGF0YXN0b3JlLXJl ZiB0eXBlIGlzIHVzZWQuDQo+ID4+PiAgICBIb3dldmVyLCAiY29udmVudGlvbmFsIiBpcyB2YWxp ZCBmb3IgYmFzZSAiZGF0YXN0b3JlIiwgZXZlbiB0aG91Z2gNCj4gPj4+ICAgIGl0IGlzIGFtYmln dW91cyBhcyBhIGRhdGFzdG9yZSBzZWxlY3Rvci4NCj4gPj4gDQo+ID4+IFdlIGNhbiBhZGQgZXhw bGljaXQgdGV4dCB0aGF0IGFuIGlkZW50aXR5IHRoYXQgZG9lcyBub3QgcmVzb2x2ZSB0byBhDQo+ ID4+IGRhdGFzdG9yZSBpbXBsZW1lbnRlZCBieSB0aGUgc2VydmVyIHJlc3VsdHMgaW4gYW4gaW52 YWxpZCB2YWx1ZSBlcnJvci4NCj4gPj4gDQo+ID4+IA0KPiA+PiBPSw0KPiA+PiANCj4gPj4gDQo+ ID4+PiAyKSBvcmlnaW4gZmlsdGVyIGlzIGxpbWl0ZWQgdG8gMSBzb3VyY2UNCj4gPj4+ICAgVGhp cyBmaWx0ZXJpbmcgc2VlbXMgcmF0aGVyIGxpbWl0ZWQuICBBIGNsaWVudCBtdXN0IHJldHJpZXZl DQo+ID4+PiA8d2l0aC1vcmlnaW4+IGFuZCBjaGVjaw0KPiA+Pj4gICAgYWxsIHRoZSB2YWx1ZXMg aW4gdXNlLCB0aGVuIG1ha2UgcmVwZWF0ZWQgcmVxdWVzdHMgZm9yIGVhY2ggc291cmNlIGFzIGEN Cj4gPj4+IGRpZmZlcmVudA0KPiA+Pj4gICAgPG9yaWdpbi1maWx0ZXI+IGxlYWYNCj4gPj4gDQo+ ID4+IElmIHRoZSBjbGllbnQgZG9lcyA8d2l0aC1vcmlnaW4+LCB0aGVuIGl0IGhhcyBhbGwgb3Jp Z2luIGluZm9ybWF0aW9uDQo+ID4+IGFuZCBpdCBjYW4gZmlsdGVyIGxvY2FsbHkuIFRoYXQgc2Fp ZCwgd2UgY291bGQgbWFrZSBvcmlnaW4tZmlsdGVyIGENCj4gPj4gbGVhZi1saXN0IHdoaWNoIGlz IGxvZ2ljYWxseSBPUmVkIHNvIHRoYXQgb25lIGNhbiByZXRyaWV2ZQ0KPiA+PiBvcmlnaW4tZmls dGVyPW9yOnN5c3RlbSBvciBvcmlnaW4tZmlsdGVyPW9yOmxlYXJuZWQgaW4gb25lIHJlcXVlc3Qu DQo+ID4+IA0KPiA+PiANCj4gPj4gT0sNCj4gPj4gDQo+ID4+PiAzKSB3aXRoLWRlZmF1bHRzIGJy b2tlbg0KPiA+Pj4gICAgVGhlIG9wZXJhdGlvbmFsIGRhdGFzdG9yZSBkb2VzIG5vdCBzdXBwb3J0 IHdpdGgtZGVmYXVsdHMuDQo+ID4+PiAgICAgSW5zdGVhZCwgdGhlIGNsaWVudCBtdXN0IHVzZSBv cmlnaW4tZmlsdGVyPW9yOmRlZmF1bHQgb3Igd2l0aC1vcmlnaW4NCj4gPj4+ICAgICBhbmQgY2hl Y2sgYWxsIHRoZSBvcmlnaW4gYXR0cmlidXRlcy4gIFNpbmNlIGEgY2xpZW50IG5lZWRzIHRvIHVz ZQ0KPiA+Pj4gICAgIHdpdGgtZGVmYXVsdHMgZm9yIG90aGVyIGRhdGFzdG9yZXMsIHRoaXMgc3Bl Y2lhbCBoYW5kbGluZyBvZg0KPiA+Pj4gPG9wZXJhdGlvbmFsPg0KPiA+Pj4gICAgIHNlZW1zIHVu aGVscGZ1bC4NCj4gPj4gDQo+ID4+IEkgdGhpbmsgdGhlIHdpdGgtZGVmYXVsdHMgc2VtYW50aWNz IGZvciBjb252ZW50aW9uYWwgY29uZmlndXJhdGlvbg0KPiA+PiBkYXRhc3RvcmVzIGFyZSBtdWNo IG1vcmUgY29tcGxpY2F0ZWQgdGhhbiBuZWNlc3NhcnkgZm9yIHRoZQ0KPiA+PiBvcGVyYXRpb25h bCBzdGF0ZSBkYXRhc3RvcmUuIE5vdGUgdGhhdCB0aGF0IHRoZSBvcGVyYXRpb25hbCBzdGF0ZQ0K PiA+PiBkYXRhc3RvcmUgcmVwb3J0cyBpbi11c2UgdmFsdWVzIG5vdCByZWFsbHkgZGVmYXVsdHM6 DQo+ID4+IA0KPiA+PiAgPGxlYWYgb3I6b3JpZ2luPSdkZWZhdWx0Jz5mb288L2xlYWY+DQo+ID4+ IA0KPiA+PiBUaGlzIHJlcG9ydHMgdGhhdCB0aGUgdmFsdWUgJ2ZvbycgaXMgaW4gdXNlIGFuZCB0 aGF0IGl0IG9yaWdpbmF0ZXMNCj4gPj4gZnJvbSBhIGRlZmF1bHQgdmFsdWUuIE5vdGUgdGhhdCB0 aGlzIGNvdWxkIGFsc28gYmUNCj4gPj4gDQo+ID4+ICA8bGVhZiBvcjpvcmlnaW49J2ludGVuZGVk Jz5mb288L2xlYWY+DQo+ID4+IA0KPiA+PiBpbiBjYXNlIHRoZSBpbnRlbmRlZCBjb25maWd1cmF0 aW9uIGRhdGFzdG9yZSBjb25maWd1cmVkIHRoZSB2YWx1ZQ0KPiA+PiAnZm9vJyAoZGVzcGl0ZSB0 aGlzIHZhbHVlIG1hdGNoaW5nIHRoZSBkZWZhdWx0KS4gVGhlIHdpdGgtZGVmYXVsdHMNCj4gPj4g c29sdXRpb24gaXMgcHJldHR5IGNvbXBsZXggYmVjYXVzZSBpdCB0cmllcyB0byBoYW5kbGUgaG93 IGRpZmZlcmVudA0KPiA+PiBzeXN0ZW1zIGRlYWwgd2l0aCBjb25maWd1cmF0aW9uIGRlZmF1bHRz LiBUaGUgaWRlYSBpcyB0byBub3QgY2FycnkNCj4gPj4gdGhpcyBjb21wbGV4aXR5IG92ZXIgdG8g aW4tdXNlIHZhbHVlcyBpbiB0aGUgb3BlcmF0aW9uYWwgc3RhdGUNCj4gPj4gZGF0YXN0b3JlLg0K PiA+PiANCj4gPj4gDQo+ID4+IEJlZm9yZSBOTURBLCB0aGUgY2xpZW50IGNvdWxkIGRlY2lkZSBp ZiBpdCB3YW50ZWQgdG8gcmV0cmlldmUgZGVmYXVsdCBub2RlcyBvciBub3QuDQo+ID4+IFRoaXMg Y2xpZW50LWNob2ljZSBoYXMgYmVlbiByZW1vdmVkIGZyb20gTk1EQSwgd2hpY2ggaXMgYSBwcm9i bGVtLg0KPiA+PiBXZSB0cmllZCB0byByZWFjaCBhIHNlbnNpYmxlIGNvbXByb21pc2Ugb24gdGhl IGRhdGEgcmV0dXJuZWQgZnJvbSBvcGVyYXRpb25hbCAoZGVmaW5lZCBpbiBzZWN0aW9uIDUuMyBv ZiB0aGUgTk1EQSBhcmNoaXRlY3R1cmUpOg0KPiA+PiAtIGl0IHNob3VsZCByZXR1cm4gZXhwbGlj aXQgdmFsdWVzIGZvciBldmVyeXRoaW5nIHRoYXQgaXMgYWZmZWN0aW5nIHRoZSBhY3R1YWwgcnVu bmluZyBzdGF0ZSBvZiB0aGUgZGV2aWNlIChyZWdhcmRsZXNzIG9mIHdoZXRoZXIgdGhlIG9wZXJh dGlvbmFsIHZhbHVlIG1hdGNoZXMgYSBzY2hlbWEgZGVmYXVsdCB2YWx1ZSkuDQo+ID4+IC0gaXQg ZG9lcyBub3QgbmVlZCB0bywgYW5kIHNob3VsZCBub3QsIHJldHVybiBvcGVyYXRpb25hbCB2YWx1 ZXMgZm9yIHN0dWZmIHRoYXQgaXNuJ3QgYWN0dWFsbHkgaW4gdXNlLCBpLmUuIGRvbid0IHJldHVy biBuZWVkbGVzcyBhbmQgdW53YW50ZWQgZGF0YS4NCj4gPj4gDQo+ID4+IEluIHBhcnRpY3VsYXIs IGlmIG5vIHZhbHVlIGlzIHJldHVybmVkIGZyb20gYSBwYXJ0aWN1bGFyIGRhdGEgbm9kZSBpbiA8 b3BlcmF0aW9uYWw+IHRoZW4sIGJhcnJpbmcgbWdtdCBwcm90b2NvbCBlcnJvcnMsIGEgY2xpZW50 IGNhbiBhc3N1bWUgdGhhdCBhbnkgZnVuY3Rpb25hbGl0eSBhc3NvY2lhdGVkIHdpdGggdGhhdCBk YXRhIG5vZGUgaXMgb2ZmIChpLmUuIG5vdCBpbiB1c2UpLg0KPiA+PiANCj4gPj4gU29tZSBleGFt cGxlcyB0byBpbGx1c3RyYXRlIHRoZSBiZWhhdmlvcjoNCj4gPj4gDQo+ID4+IChpKSBJZiBhIHBy b3RvY29sLCBlLmcuIE9TUEYsICBpcyBub3QgZW5hYmxlZC9ydW5uaW5nIHRoZW4gPG9wZXJhdGlv bmFsPiBkb2VzIG5vdCBuZWVkIHRvIHJldHVybiBhbnkgZGF0YSBmb3IgaXQuICBJdCB3b3VsZCBi ZSByZWFzb25hYmxlIHRvIHJldHVybiBhIGZsYWcgdG8gaW5kaWNhdGUgdGhhdCBPU1BGIGlzIG5v dCBlbmFibGVkL3J1bm5pbmcuDQo+ID4+IA0KPiA+PiAoaWkpIElmIHlvdSBoYXZlIHNvbWUgZnVu a3kgd2lkZ2V0IG9uIGFuIGludGVyZmFjZSB0aGF0IGRlZmF1bHRzIHRvIGJlaW5nIG9mZiBhbmQg aXNuJ3QgYmVpbmcgdXNlZCB0aGVuIDxvcGVyYXRpb25hbD4gZG9uJ3QgbmVlZCB0byByZXR1cm4g YW55IGRhdGEgZm9yIGl0Lg0KPiA+PiANCj4gPj4gKGlpaSkgQnV0LCBpZiB5b3UgaGF2ZSBzb21l IGZ1bmt5IHdpZGdldCBvbiBhbiBpbnRlcmZhY2UgdGhhdCBkZWZhdWx0cyB0byBiZWluZyBvbiwg dGhlbiB0aGUgc2VydmVyIHNob3VsZCByZXR1cm4gZGF0YSBmb3IgaXQuIElmIGl0IGlzIGFjdHVh bGx5IGVuYWJsZWQsIHRoZW4gaXQgd291bGQgaW5kaWNhdGUgdGhhdCBpdCBpcyBvbiBhbmQgcmV0 dXJuIGFueSBhc3NvY2lhdGVkIHZhbHVlcyB3aXRoIGl0cyBvcGVyYXRpb25hbCBzdGF0ZSwgb3Ig aWYgaXQgaXMgZGlzYWJsZWQgdGhlbiBpdCBzaG91bGQgZXhwbGljaXRseSByZXBvcnQgdGhhdCBp dCBpcyBvZmYuDQo+ID4+IA0KPiA+PiAoaXYpIEkgd291bGQgcmVnYXJkIHRoYXQgYWxsIGFwcGxp ZWQgY29uZmlndXJhdGlvbiBpcyAiaW4gdXNlIiBieSB0aGUgc3lzdGVtLCBldmVuIGlmIGl0IG1h dGNoZXMgdGhlIGRlZmF1bHQgdmFsdWUsIGFuZCBoZW5jZSBpdCBzaG91bGQgYmUgcmVwb3J0ZWQu DQo+ID4+IA0KPiA+PiANCj4gPj4gVGhpcyBiZWhhdmlvciBmb3IgPG9wZXJhdGlvbmFsPiBpcyBv YnZpb3VzbHkgc2xpZ2h0bHkgZGlmZmVyZW50IGZyb20gdGhlIGV4aXN0aW5nIHdpdGgtZGVmYXVs dCBoYW5kbGluZyB0aGF0IGlzIHN1cHBvcnRlZCBmb3IgY29uZmlndXJhdGlvbiBkYXRhc3RvcmVz LiAgQXMgSSByZWNhbGwsIHRoZXJlIHdlcmUgYSBjb3VwbGUgb2YgcmVhc29ucyB0aGF0IHdlIGRl Y2lkZWQgdG8gaGF2ZSBhIGRpZmZlcmVudCBiZWhhdmlvciBmb3IgPG9wZXJhdGlvbmFsPjoNCj4g Pj4gKGEpIHRvIGhhdmUgY29uc2lzdGVudCBzZW1hbnRpY3MgZm9yIGFsbCBzZXJ2ZXJzLCByYXRo ZXIgdGhhbiBkaWZmZXJlbnQgc2VydmVycyBzdXBwb3J0aW5nIGRpZmZlcmVudCB3aXRoLWRlZmF1 bHRzIGJlaGF2aW9ycyAod2hpY2ggbWFrZXMgbGlmZSBoYXJkZXIgZm9yIGNsaWVudHMgYmVjYXVz ZSB0aGV5IG11c3QgY29wZSB3aXRoIGFsbCB2YXJpYW50cykuDQo+ID4+IChiKSB0byByZW1vdmUg YW55IHBvdGVudGlhbCBhbWJpZ3VpdHkgaWYgZGF0YSBpc24ndCByZXR1cm5lZC4gIEkuZS4gd2l0 aCB0aGUgZXhpc3Rpbmcgd2l0aC1kZWZhdWx0cyBzZW1hbnRpY3MgaXQgaXMgbm90IGNsZWFyIHRv IG1lIHRoYXQgc2VydmVycyB3aWxsIGFsd2F5cyByZXR1cm4gYW4gZXhwbGljaXQgdmFsdWUgdG8g aW5kaWNhdGUgdGhhdCBhIHBhcnRpY3VsYXIgd2lkZ2V0IGlzIG9mZiBpZiB0aGUgc2NoZW1hIGRl ZmluZXMgdGhhdCB0aGUgZGVmYXVsdCBpdCB0aGF0IGlzIGVuYWJsZWQuICBJZiB0aGUgc2VydmVy IGRvZXNuJ3Qgc3VwcG9ydCBhIGdpdmVuIHdpZGdldCBhdCBhbGwsIGl0IGlzIHF1aXRlIHBsYXVz aWJsZSB0aGF0IGl0IHdpbGwganVzdCByZXR1cm4gbm8gZGF0YSBmb3IgaXQuICBJbiB0aGVvcnkg ZmVhdHVyZXMvZGV2aWF0aW9ucyBzaG91bGQgaGFuZGxlIHRoaXMsIGJ1dCB0aG9zZSBkb24ndCB3 b3JrIHNvIHdlbGwgaWYgZGlmZmVyZW50IGxpbmVjYXJkcyBoYXZlIGRpZmZlcmVudCBjYXBhYmls aXRpZXMuICBIZW5jZSBiZWluZyBleHBsaWNpdCBhYm91dCBzdHVmZiB0aGF0IGlzIGluIHVzZSBz ZWVtcyBtb3JlIHJvYnVzdC4NCj4gPj4gDQo+ID4+IDxlcmljPiBUaGVzZSBhcmUgZ29vZCBleGFt cGxlcy4gIEl0IHdvdWxkIGJlIGdyZWF0IGlmIHNlY3Rpb24gNS4zIGNvdWxkIGJlIHR3ZWFrZWQg dG8gbWFrZSBjbGVhcmVyIHRoZSByZWxhdGlvbnNoaXAgYmV0d2VlbiBydW5uaW5nIGRhdGFzdG9y ZSBkZWZhdWx0cyBhbmQgb3RoZXIgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIGRlZmF1bHRzIGZvciB0 aGUgc2FtZSB0cmVlLg0KPiA+PiANCj4gPj4gRm9yIGV4YW1wbGUsIGxldOKAmXMgc2F5IEkgY3Jl YXRlIGEgY29uZmlndXJlZCBzdWJzY3JpcHRpb24sIGFuZCB0aGUgZGVmYXVsdCB0cmFuc3BvcnQg cHJvdG9jb2wgaXMgTkVUQ09ORi4gIE5FVENPTkYgd2lsbCBiZSB1c2VkIGZvciB0aGF0IHN1YnNj cmlwdGlvbiBldmVuIHRob3VnaCB0aGUgbm9kZSBtaWdodCBub3QgYmUgcG9wdWxhdGVkLiAgSW4g dGhpcyBjYXNlLCB0aGUgb2JqZWN0IHdvdWxkIG5vdCBhcHBlYXIgaW4gdGhlIHJ1bm5pbmcgZGF0 YXN0b3JlLCBidXQgTVVTVCogYXBwZWFyIGluIHRoZSBvcGVyYXRpb25hbCBkYXRhc3RvcmUgd2l0 aCB0aGUgZGVmYXVsdCBvcmlnaW4gKGFzIGl0IGlzIGluLXVzZSkuDQo+ID4+IA0KPiA+PiBUaGlz IHRvIG1lIGlzIHRoZSBkZXNpcmVkIGJlaGF2aW9yIGFzIGl0IGRvZXNu4oCZdCBpbmNvcnJlY3Rs eSBhZGQgaW5mb3JtYXRpb24gdG8gdGhlIHJ1bm5pbmcgZGF0YXN0b3JlLCBidXQgc2hvd3Mgd2hh dCBpcyBpbi11c2Ugd2l0aGluIG9wZXJhdGlvbmFsLiAgIEkgc3VzcGVjdCBvdGhlciBzdWNoIHJl bGF0aW9uc2hpcHMgZm9yIG90aGVyIG9wZXJhdGlvbmFsIHRyZWUgZGVmYXVsdHMgY291bGQgYmUg YXNzZXJ0ZWQsIHBlcmhhcHMgYmFzZWQgb24gdGhlIG9yaWdpbi4NCj4gPj4gDQo+ID4+ICgqIE1h eWJlIOKAmE1VU1QgZXZlbnR1YWxseeKAmSwgYXMgb2J2aW91c2x5IHRoZXJlIGlzIGEgdGVtcG9y YWwgcmVsYXRpb25zaGlwIGJldHdlZW4gdGhlIHR3byBkYXRhc3RvcmVzLikNCj4gPj4gDQo+ID4+ IEVyaWMNCj4gPj4gDQo+ID4+IFRoYW5rcywNCj4gPj4gUm9iDQo+ID4+IA0KPiA+PiANCj4gPj4g DQo+ID4+IA0KPiA+PiANCj4gPj4gDQo+ID4+IC9qcw0KPiA+PiANCj4gPj4gQW5keQ0KPiA+PiAN Cj4gPj4gLS0NCj4gPj4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAgICAgICAgICBKYWNvYnMgVW5p dmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPj4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1ODcgICAgICAg ICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiA+PiBGYXg6ICAgKzQ5 IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+ DQo+ID4+IA0KPiA+PiANCj4gPj4gDQo+ID4+IA0KPiA+PiANCj4gPj4gX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4gDQo+ID4+IG5ldG1vZCBtYWls aW5nIGxpc3QNCj4gPj4gDQo+ID4+IG5ldG1vZEBpZXRmLm9yZyA8bWFpbHRvOm5ldG1vZEBpZXRm Lm9yZz48bWFpbHRvOm5ldG1vZEBpZXRmLm9yZyA8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4+DQo+ ID4+IA0KPiA+PiBodHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCA8 aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2Q+DQo+ID4+IA0KPiA+ IA0KPiA+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K PiA+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4+IG5ldG1vZEBpZXRmLm9yZyA8bWFpbHRvOm5l dG1vZEBpZXRmLm9yZz4NCj4gPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5m by9uZXRtb2QgPGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPg0K PiA+IA0KPiA+IA0KPiA+IC0tIA0KPiA+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAgICAg SmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4gUGhvbmU6ICs0OSA0MjEgMjAwIDM1 ODcgICAgICAgICBDYW1wdXMgUmluZyAxIHwgMjg3NTkgQnJlbWVuIHwgR2VybWFueQ0KPiA+IEZh eDogICArNDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJz aXR5LmRlLyA8aHR0cHM6Ly93d3cuamFjb2JzLXVuaXZlcnNpdHkuZGUvPj4NCj4gPiANCj4gPiBf X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1v ZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcgPG1haWx0bzpuZXRtb2RAaWV0Zi5v cmc+DQo+ID4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QgPGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPg0KPiBNYWhlc2ggSmV0 aGFuYW5kYW5pDQo+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tDQo+IA0K From nobody Mon Feb 5 13:33:26 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 18ADF12895E; Mon, 5 Feb 2018 13:33:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3LjXMbPnyVce; Mon, 5 Feb 2018 13:33:17 -0800 (PST) Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E28C812711E; Mon, 5 Feb 2018 13:33:16 -0800 (PST) Received: by mail-io0-x22c.google.com with SMTP id b198so238933iof.6; Mon, 05 Feb 2018 13:33:16 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ONcebH6l0oMCOgoiizf3YgHlJj7L7Dzz5ybxmOm6Aj0=; b=vA9KrbGBrHVRvd2nyxDTVuCztkA+iFG7joBgPzYGisTqvCgSgkQVyCOmJnFrB5R3Ay mTDRIcgRtReKOVFxSl2Y467GiXwSQ/xnjpwLyOxZYEH86HZ+1NbOZuUgA56MHcYBZtdS 8kT+GWXv2sP2kWoJGt8mHASvOdZtrYqQu9+3RJ/HrwNxVEd/OAcd42XlF7F8exJOyaWD XHtPQ1UHNMc3WdC93juVs1QwUH+1Le/tBkgt1Vp9S81VQUpRUm1JvOXHETx80g5mf2jU tn2Ek1avyTVWk45OtuKKv4X7OcEsmHBBihoeHa1YVUnIiDuR+CtE3APrDFIwHBUgnSqo PRJA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=ONcebH6l0oMCOgoiizf3YgHlJj7L7Dzz5ybxmOm6Aj0=; b=phN/z6nM3FjuRrChQdE2EKsOFXskNV7k5XJJE9WYR+HT696ppouh/DyDnunEtlHouX NcFiy99fQq4iNnFkb0855pwYBbACz38vT16VAuWeyBPzC9EUhfGdW5Jm2RN072jqbA0J WSby3cYEaBFb21pEOClkRyKJmxaFYx064RNnOENB5MZObuop07JyiQh94hl72ckiuJqW xNePiIHRNJPByC12cYsJLdlbV5dhYFQJK7MDAcBTVBFGJLffOuZpDdL5c7lOs9x8b8vs +HclMtOhCN73GKQQMHg1coPnD0ObxVHoxxgN9SPhUIxknbPMEkTVmD0WnsICaS7PTZL6 kS6w== X-Gm-Message-State: APf1xPAq+mpxkQgc4533LIxIyUoNmvIjO3gnk017V4VcHzaJrHhPBR3e S/IZPLmfEfS/MiVjnBIiwStyIA== X-Google-Smtp-Source: AH8x2261Fk4kptlo0B+PRJUJF2YrVv+7jXEqCZSpHrfEnxKx5qQlNIDoIQnaGgTm++Aw3OX/BykC0g== X-Received: by 10.107.142.202 with SMTP id q193mr329527iod.100.1517866395800; Mon, 05 Feb 2018 13:33:15 -0800 (PST) Received: from ?IPv6:2600:1700:edb0:8fd0:1d06:aab4:a2c5:e1c8? ([2600:1700:edb0:8fd0:1d06:aab4:a2c5:e1c8]) by smtp.gmail.com with ESMTPSA id a19sm5659103ioc.17.2018.02.05.13.33.14 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 05 Feb 2018 13:33:14 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (1.0) From: Mahesh Jethanandani X-Mailer: iPhone Mail (14G60) In-Reply-To: <20180205.184312.338993520253253388.mbj@tail-f.com> Date: Mon, 5 Feb 2018 13:33:13 -0800 Cc: netconf@ietf.org, netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <39203004-C003-4C07-A376-006B6F7969D6@gmail.com> References: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com> <20180131181619.ziqdv5peqdeeuhl4@elstar.local> <20180205.184312.338993520253253388.mbj@tail-f.com> To: Martin Bjorklund Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 05 Feb 2018 21:33:20 -0000 For folks that provided comments as part of LC, please verify that your comm= ents have been adequately addressed by -03 version of the draft.=20 Thanks=20 Mahesh Jethanandani=20 mjethanandani@gmail.com > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund wrote: >=20 > Hi, >=20 > Mahesh Jethanandani wrote: >> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF. >>=20 >> As part of the LC, there were a couple of comments/questions >> raised. In particular=20 >>=20 >> - Vladmir reported an error, which Martin said is fixed in his local copy= . >=20 > Fixed. >=20 >> - Robert suggested that =E2=80=9C/yang-library/checksum=E2=80=9D should b= e a >> reference. Juergen supported that comment, so I am assuming that >> that will be incorporated into the draft. >=20 > Yes, fixed. >=20 >> - Andy had questions around datastore set to =E2=80=9Cconventional=E2=80=9D= >=20 > Fixed. >=20 >> , about origin filter limited to 1 source >=20 > Fixed. >=20 >> and the behavior of with-defaults. >=20 > There were no additional changes to the document from the discussion > about this. >=20 >> I see some discussion around it with the authors >> agreeing that some of them need some text clarifying the >> position. Can the authors please post the suggested text/additions >> for the WG to review.=20 >> - Anything else?? >>=20 >> Once an updated draft has been posted, I will do a writeup on the >> drafts and send it to IESG. =20 >=20 > The issues above are now addressed, in > draft-ietf-netconf-nmda-netconf-03. >=20 > There were no additional comments on > draft-ietf-netconf-nmda-restconf-02, so I believe this version is > ready. >=20 >=20 > /martin >=20 >=20 >>=20 >> Thanks. >>=20 >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder wrote: >>>=20 >>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote: >>>>=20 >>>> I do have one additional thought below on draft-ietf-netmod-revised-dat= astores section 5.3 default handling process. See in-line... >>>>=20 >>>=20 >>> Well, this document is with the RFC editor now. I do not think it needs >>> clarification. It already has text in 5.3 such as: >>>=20 >>> Requests to retrieve nodes from always return the value >>> in use if the node exists, regardless of any default value specified >>> in the YANG module. If no value is returned for a given node, then >>> this implies that the node is not used by the device. >>>=20 >>> /js >>>=20 >>>> From: Robert Wilton -X, January 31, 2018 6:31 AM >>>>=20 >>>>=20 >>>> Hi Andy, >>>>=20 >>>> On 31/01/2018 09:22, Andy Bierman wrote: >>>>=20 >>>>=20 >>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder >> wrote: >>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: >>>>> Hi, >>>>>=20 >>>>> I have some questions about these drafts. >>>>>=20 >>>>> 1) what if datastore set to "conventional"? >>>>> There are many places where a datastore-ref type is used. >>>>> However, "conventional" is valid for base "datastore", even though >>>>> it is ambiguous as a datastore selector. >>>>=20 >>>> We can add explicit text that an identity that does not resolve to a >>>> datastore implemented by the server results in an invalid value error. >>>>=20 >>>>=20 >>>> OK >>>>=20 >>>>=20 >>>>> 2) origin filter is limited to 1 source >>>>> This filtering seems rather limited. A client must retrieve >>>>> and check >>>>> all the values in use, then make repeated requests for each source a= s a >>>>> different >>>>> leaf >>>>=20 >>>> If the client does , then it has all origin information >>>> and it can filter locally. That said, we could make origin-filter a >>>> leaf-list which is logically ORed so that one can retrieve >>>> origin-filter=3Dor:system or origin-filter=3Dor:learned in one request.= >>>>=20 >>>>=20 >>>> OK >>>>=20 >>>>> 3) with-defaults broken >>>>> The operational datastore does not support with-defaults. >>>>> Instead, the client must use origin-filter=3Dor:default or with-ori= gin >>>>> and check all the origin attributes. Since a client needs to use >>>>> with-defaults for other datastores, this special handling of >>>>> >>>>> seems unhelpful. >>>>=20 >>>> I think the with-defaults semantics for conventional configuration >>>> datastores are much more complicated than necessary for the >>>> operational state datastore. Note that that the operational state >>>> datastore reports in-use values not really defaults: >>>>=20 >>>> foo >>>>=20 >>>> This reports that the value 'foo' is in use and that it originates >>>> from a default value. Note that this could also be >>>>=20 >>>> foo >>>>=20 >>>> in case the intended configuration datastore configured the value >>>> 'foo' (despite this value matching the default). The with-defaults >>>> solution is pretty complex because it tries to handle how different >>>> systems deal with configuration defaults. The idea is to not carry >>>> this complexity over to in-use values in the operational state >>>> datastore. >>>>=20 >>>>=20 >>>> Before NMDA, the client could decide if it wanted to retrieve default n= odes or not. >>>> This client-choice has been removed from NMDA, which is a problem. >>>> We tried to reach a sensible compromise on the data returned from opera= tional (defined in section 5.3 of the NMDA architecture): >>>> - it should return explicit values for everything that is affecting the= actual running state of the device (regardless of whether the operational v= alue matches a schema default value). >>>> - it does not need to, and should not, return operational values for st= uff that isn't actually in use, i.e. don't return needless and unwanted data= . >>>>=20 >>>> In particular, if no value is returned from a particular data node in <= operational> then, barring mgmt protocol errors, a client can assume that an= y functionality associated with that data node is off (i.e. not in use). >>>>=20 >>>> Some examples to illustrate the behavior: >>>>=20 >>>> (i) If a protocol, e.g. OSPF, is not enabled/running then does not need to return any data for it. It would be reasonable to return= a flag to indicate that OSPF is not enabled/running. >>>>=20 >>>> (ii) If you have some funky widget on an interface that defaults to bei= ng off and isn't being used then don't need to return any data= for it. >>>>=20 >>>> (iii) But, if you have some funky widget on an interface that defaults t= o being on, then the server should return data for it. If it is actually ena= bled, then it would indicate that it is on and return any associated values w= ith its operational state, or if it is disabled then it should explicitly re= port that it is off. >>>>=20 >>>> (iv) I would regard that all applied configuration is "in use" by the s= ystem, even if it matches the default value, and hence it should be reported= . >>>>=20 >>>>=20 >>>> This behavior for is obviously slightly different from th= e existing with-default handling that is supported for configuration datasto= res. As I recall, there were a couple of reasons that we decided to have a d= ifferent behavior for : >>>> (a) to have consistent semantics for all servers, rather than different= servers supporting different with-defaults behaviors (which makes life hard= er for clients because they must cope with all variants). >>>> (b) to remove any potential ambiguity if data isn't returned. I.e. wit= h the existing with-defaults semantics it is not clear to me that servers wi= ll always return an explicit value to indicate that a particular widget is o= ff if the schema defines that the default it that is enabled. If the server= doesn't support a given widget at all, it is quite plausible that it will j= ust return no data for it. In theory features/deviations should handle this= , but those don't work so well if different linecards have different capabil= ities. Hence being explicit about stuff that is in use seems more robust. >>>>=20 >>>> These are good examples. It would be great if section 5.3 could= be tweaked to make clearer the relationship between running datastore defau= lts and other operational datastore defaults for the same tree. >>>>=20 >>>> For example, let=E2=80=99s say I create a configured subscription, and t= he default transport protocol is NETCONF. NETCONF will be used for that sub= scription even though the node might not be populated. In this case, the ob= ject would not appear in the running datastore, but MUST* appear in the oper= ational datastore with the default origin (as it is in-use). >>>>=20 >>>> This to me is the desired behavior as it doesn=E2=80=99t incorrectly ad= d information to the running datastore, but shows what is in-use within oper= ational. I suspect other such relationships for other operational tree def= aults could be asserted, perhaps based on the origin. >>>>=20 >>>> (* Maybe =E2=80=98MUST eventually=E2=80=99, as obviously there is a tem= poral relationship between the two datastores.) >>>>=20 >>>> Eric >>>>=20 >>>> Thanks, >>>> Rob >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> /js >>>>=20 >>>> Andy >>>>=20 >>>> -- >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>> Fax: +49 421 200 3103 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>>=20 >>>> netmod mailing list >>>>=20 >>>> netmod@ietf.org > >>>>=20 >>>> https://www.ietf.org/mailman/listinfo/netmod >>>>=20 >>>=20 >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>>=20 >>>=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 >> Mahesh Jethanandani >> mjethanandani@gmail.com >>=20 From nobody Mon Feb 5 17:36:19 2018 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 DC5FA127342; Mon, 5 Feb 2018 17:36:12 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.71.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151788097285.24984.6744281522702450280@ietfa.amsl.com> Date: Mon, 05 Feb 2018 17:36:12 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-17.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 01:36:13 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : Guidelines for Authors and Reviewers of YANG Data Model Documents Author : Andy Bierman Filename : draft-ietf-netmod-rfc6087bis-17.txt Pages : 71 Date : 2018-02-05 Abstract: This memo provides guidelines for authors and reviewers of Standards Track specifications containing YANG data model modules. Applicable portions may be used as a basis for reviews of other YANG data model documents. Recommendations and procedures are defined, which are intended to increase interoperability and usability of Network Configuration Protocol (NETCONF) and RESTCONF protocol implementations that utilize YANG data model modules. This document obsoletes RFC 6087. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-17 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-17 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-17 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Tue Feb 6 00:33:54 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 41009126BF6 for ; Tue, 6 Feb 2018 00:33:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKC5EmsIOJYY for ; Tue, 6 Feb 2018 00:33:49 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3B48120727 for ; Tue, 6 Feb 2018 00:33:48 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 1119CEFE; Tue, 6 Feb 2018 09:33:47 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id LDuzrD6jFV_E; Tue, 6 Feb 2018 09:33:44 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 Feb 2018 09:33:47 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id EB1CE20149; Tue, 6 Feb 2018 09:33:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rQgKcfhe79pq; Tue, 6 Feb 2018 09:33:44 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id A5B8620147; Tue, 6 Feb 2018 09:33:44 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 629A04239CBF; Tue, 6 Feb 2018 09:33:44 +0100 (CET) Date: Tue, 6 Feb 2018 09:33:44 +0100 From: Juergen Schoenwaelder To: Kent Watsen Cc: "netmod@ietf.org" Message-ID: <20180206083344.o5vqjwwtkq7awrxy@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Kent Watsen , "netmod@ietf.org" References: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 08:33:52 -0000 On Wed, Jan 31, 2018 at 09:36:07PM +0000, Kent Watsen wrote: > > The authors created a "pre09" branch on GitHub a few weeks back. On this branch, they completed a full update of the draft. While waiting for details on how to proceed with regards to a SM-bis, we thought it would be helpful to make this text available now so that the technical parts can be discussed. With this in mind, can folks please have a quick look and post any technical comments they have? > I have reviewed draft-ietf-netmod-schema-mount-pre-09 that I fetched today from GitHub. Here are my comments: * Perhaps the abstract can be improved. The single sentence that we have is not even quite correct. This document defines a mechanism to combine YANG modules into the schema defined in other YANG modules. According to YL bis, a datastore has a schema, which consists of a set of YANG modules. The terminology used in RFC 7950 is 'schema node' and 'schema tree'. Perhaps this sentence can be rewritten to better explain the purpose of this document. * The following text is not consistent with what YLbis says: 2. Implementation-time: the mounted schema is defined by a server implementor and is as stable as YANG library information, i.e., it may change after an upgrade of server software but not after rebooting the server. Also, a client can learn the entire schema together with YANG library data. YLbis does allow YANG library to change. I think this text should change as follows: 2. Implementation-time: the mounted schema is defined by a server implementor and is as stable as YANG library information of the server. A client can learn the entire schema by reading the server's YANG library data. I think 3. should also be changed. The phrase 'is part of the mounted data model' may not be exactly true with NMDA - well depending what the 'mounted data model' really means. Perhaps something like this: 3. Run-time: the mounted schema is defined by instance data that is associated with the mount point and reported outside the server's YANG library information. If there are multiple instances of the same mount point (e.g., in multiple entries of a list), the mounted data model may be different for each instance. * Terminology - should this document import the terms client, server, notification from the NMDA document instead of the NETCONF document? I assume the terms are understood more broadly than just NETCONF client and server. * Definition of inline schema: o inline schema: a mounted schema whose definition is provided as part of the mounted data, using YANG library [I-D.ietf-netconf-rfc7895bis]. I am not sure 'as part of the mounted data, using YANG library' is a good definition. Which YANG library? I think what this term means is a mount point specific YANG library, not the master server's YANG library. This is also why I was largely confused about the inline case; the schema used by the mountpoint is not defined inline from the master server's point of view, from which the document is written. From the master server's point of view, the 'inline schema' is actually the opposite, it is an 'external schema' since I have to pull the schema information from an external source; the schema is not reported with the server's schema information - this is what I would consider inline. It may be too late to change this term but at least for me 'inline' has been very confusing since we describe everything from the perspective of the master server. Later on, the phrase "use-schema" case is used as well. Perhaps this should also be a defined term and a better term should be used. The terms should describe the concepts and the YANG model should follow; what we have is kind of backwards, there is a YANG model and then model names are used a conceptual terms. * YANG library stability I reported this already. The statement 'In particular, it SHOULD NOT change during the same management session.' is not consistent with what YL and YLbis say. * YANG library has a drawing of the underlying conceptual model. It may help to agree on how schema mount is extending the model. Here is a drawing that I created for myself: +-----------+ | datastore | +-----------+ | | has a V +-----------+ +--------+ +------------+ | datastore | union of | module | consists of | modules + | .----->| schema |----------->| set |--------------->| submodules | | +-----------+ +--------+ +------------+ | | | | has | v | +-----------+ '------| mount |------> external YANG library uses | points | uses schema reference +-----------+ Note that this makes drawing makes my struggle with the term 'inline' even more obvious. If you look at this figure, then inline would mean the exact opposite of what 'inline' means today. * Where is the schema defined in the external aka 'inline' case? The current text says: In case 1, the mounted schema is determined at run time: every instance of the mount point that exists in the parent tree MUST contain a copy of YANG library data [I-D.ietf-netconf-rfc7895bis] that defines the mounted schema exactly as for a top-level data model. A client is expected to retrieve this data from the instance tree, possibly after creating the mount point. Instances of the same mount point MAY use different mounted schemas. I think this does not work for datastores except the operational datastore. In fact, I think the model must be that if /foo is an external 'inline' mountpoint, then the /foo instance in the operational state datastore must include a YANG library instantiation in which a client can find the schema definition for /foo in any datastore where /foo is supported. In other words, if /foo is config true and a client wants to know how the /foo schema in , then the client has to fetch the YANG library residing under /foo in in order to obtain the schema information for the datastore. The text does not say any of this. * Where is the schema defined in the inline aka 'not inline' case? The current text says: In case 2, the mounted schema is defined by the combination of all "schema" entries referred to in the "use-schema" list. I think the YANG model refers to a single schema. I think this text needs to be revised and aligned with the new data model. This like applies to other places in the document where "use-schema" is discussed. I do not understand the following statement: [...] Note, that in this case a mount point may include a mounted YANG library module and the data contained in the mounted module MUST exactly match the data contained in the "schema" entries associated with the mount point. There is text about a "schema" list in 3.2 that I think is not needed anymore. * RPC operations and notifications "clients can invoke this operation by representing it as an action defined for the corresponding mount point" The wording 'invoke ... by representing" seems wrong. I think this should be "clients can invoke this operation as if it were defined as an action for the corresponding mount point" or something like this. Should there be additional text discussing how parameters of operations and notification content is interpreted? I assume everything is scoped to the mount point but perhaps this needs to be stated explicitly. * Data model The model is augmenting /yanglib:yang-library/yanglib:schema. In the case where I had two different schemas defined for say the operational state datastore and conventional datastores, this implies that I have to duplicate the schema-mounts specific definitions even in the likely case where the schema mounts are identical in both datastores. (For the extern 'inline' case they actually have to be the same or at least the operational state datastore schema-mounts have to be a superset of the conventional datastore schema-mounts since otherwise I can't get the schema information. So the question is whether schema-mount should be a list directly under /yanglib:yang-library and then /yanglib:yang-library/yanglib:schema would be augmented by a leaf (or a leaf-list) referring to schema-mount entries. * YANG definitions I think the description of the leaf 'inline' [yeah, this should be 'external'] needs to be updated to explain where in an NMDA system the YANG library information can be found. And yes, 'use-schema' is really what I call 'inline' - the schema information is provided as part of the YANG library defining the mount point. * Security considerations I was expecting text that explains how NACM works on a server that has schema mounts, discussing both cases, the inline and external schema mount cases. * Examples I have not reviewed the examples. /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 Feb 6 01:19:55 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA4D2129C56 for ; Tue, 6 Feb 2018 01:19:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yODFj1ybfieE for ; Tue, 6 Feb 2018 01:19:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 4A666126DD9 for ; Tue, 6 Feb 2018 01:19:51 -0800 (PST) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 625DD1AE02C9; Tue, 6 Feb 2018 10:19:49 +0100 (CET) Date: Tue, 06 Feb 2018 10:19:49 +0100 (CET) Message-Id: <20180206.101949.156510094898094470.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180206083344.o5vqjwwtkq7awrxy@elstar.local> References: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> <20180206083344.o5vqjwwtkq7awrxy@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 09:19:53 -0000 Hi Juergen, Thanks for your review, comments inline. Juergen Schoenwaelder wrote: > On Wed, Jan 31, 2018 at 09:36:07PM +0000, Kent Watsen wrote: > > > > The authors created a "pre09" branch on GitHub a few weeks back. On this branch, they completed a full update of the draft. While waiting for details on how to proceed with regards to a SM-bis, we thought it would be helpful to make this text available now so that the technical parts can be discussed. With this in mind, can folks please have a quick look and post any technical comments they have? > > > > I have reviewed draft-ietf-netmod-schema-mount-pre-09 that I fetched > today from GitHub. Here are my comments: > > * Perhaps the abstract can be improved. The single sentence that we > have is not even quite correct. > > This document defines a mechanism to combine YANG modules into the > schema defined in other YANG modules. > > According to YL bis, a datastore has a schema, which consists of a > set of YANG modules. The terminology used in RFC 7950 is 'schema > node' and 'schema tree'. Perhaps this sentence can be rewritten to > better explain the purpose of this document. Maybe something along the lines of: This document defines a mechanism to extend a datastore schema with other schemas. It is still a bit terse... > * The following text is not consistent with what YLbis says: > > 2. Implementation-time: the mounted schema is defined by a server > implementor and is as stable as YANG library information, i.e., > it may change after an upgrade of server software but not after > rebooting the server. Also, a client can learn the entire schema > together with YANG library data. > > YLbis does allow YANG library to change. I think this text should > change as follows: > > 2. Implementation-time: the mounted schema is defined by a server > implementor and is as stable as YANG library information of the > server. A client can learn the entire schema by reading the > server's YANG library data. Yes this is better. > I think 3. should also be changed. The phrase 'is part of the > mounted data model' may not be exactly true with NMDA - well > depending what the 'mounted data model' really means. Perhaps > something like this: > > 3. Run-time: the mounted schema is defined by instance data that > is associated with the mount point and reported outside the > server's YANG library information. If there are multiple > instances of the same mount point (e.g., in multiple entries of > a list), the mounted data model may be different for each > instance. Ok. > * Terminology - should this document import the terms client, server, > notification from the NMDA document instead of the NETCONF document? Ok + "datastore schema". > I assume the terms are understood more broadly than just NETCONF > client and server. > > * Definition of inline schema: > > o inline schema: a mounted schema whose definition is provided as > part of the mounted data, using YANG library > [I-D.ietf-netconf-rfc7895bis]. > > I am not sure 'as part of the mounted data, using YANG library' is > a good definition. Which YANG library? I think what this term means > is a mount point specific YANG library, not the master server's > YANG library. > > This is also why I was largely confused about the inline case; the > schema used by the mountpoint is not defined inline from the master > server's point of view, from which the document is written. From > the master server's point of view, the 'inline schema' is actually > the opposite, it is an 'external schema' since I have to pull the > schema information from an external source; No this is not quite correct. It is "inline" from the master's point of view, in the sense of "inline in the data tree", as opposed to "part of the (augmented) yang-library schema definition". And it is *not* external. The client still fetches this data from the "master" server; and how the master server handles this is an implementation detail (or possibly standardized in the future - *one* use case is peer mount in which case the data is fetched from another system, but again, this is just one example). > the schema is not > reported with the server's schema information - this is what I > would consider inline. > > It may be too late to change this term but at least for me 'inline' > has been very confusing since we describe everything from the > perspective of the master server. > > Later on, the phrase "use-schema" case is used as well. Perhaps this > should also be a defined term Ok, this makes sense. > and a better term should be used. The > terms should describe the concepts and the YANG model should follow; > what we have is kind of backwards, there is a YANG model and then > model names are used a conceptual terms. > > * YANG library stability > > I reported this already. The statement 'In particular, it SHOULD NOT > change during the same management session.' is not consistent with > what YL and YLbis say. I agree. > * YANG library has a drawing of the underlying conceptual model. It > may help to agree on how schema mount is extending the model. Here > is a drawing that I created for myself: > > +-----------+ > | datastore | > +-----------+ > | > | has a > V > +-----------+ +--------+ +------------+ > | datastore | union of | module | consists of | modules + | > .----->| schema |----------->| set |--------------->| submodules | > | +-----------+ +--------+ +------------+ > | | > | | has > | v > | +-----------+ > '------| mount |------> external YANG library > uses | points | uses schema reference > +-----------+ > > Note that this makes drawing makes my struggle with the term > 'inline' even more obvious. I like the drawing, but I don't see the problem with the terms. Maybe just b/c I'm used to them. I think we can include this figure but s/external/inline/ > If you look at this figure, then inline > would mean the exact opposite of what 'inline' means today. > > * Where is the schema defined in the external aka 'inline' case? > The current text says: > > In case 1, the mounted schema is determined at run time: every > instance of the mount point that exists in the parent tree MUST > contain a copy of YANG library data [I-D.ietf-netconf-rfc7895bis] > that defines the mounted schema exactly as for a top-level data > model. A client is expected to retrieve this data from the instance > tree, possibly after creating the mount point. Instances of the same > mount point MAY use different mounted schemas. > > I think this does not work for datastores except the operational > datastore. In fact, I think the model must be that if /foo is an > external 'inline' mountpoint, then the /foo instance in the > operational state datastore must include a YANG library > instantiation in which a client can find the schema definition for > /foo in any datastore where /foo is supported. In other words, if > /foo is config true and a client wants to know how the /foo schema > in , then the client has to fetch the YANG library residing > under /foo in in order to obtain the schema > information for the datastore. The text does not say any > of this. I agree. We can write: A client is expected to retrieve this data from the instance tree in , and possibly add your example. > * Where is the schema defined in the inline aka 'not inline' case? > The current text says: > > In case 2, the mounted schema is defined by the combination of all > "schema" entries referred to in the "use-schema" list. > > I think the YANG model refers to a single schema. I think this text > needs to be revised and aligned with the new data model. Yes. There is just one schema, and we should write "yanglib:schema" to clarify that the "schema" node is defined in YL(bis). > This like > applies to other places in the document where "use-schema" is > discussed. > I do not understand the following statement: > > [...] Note, that in this case a mount point may include a mounted > YANG library module and the data contained in the mounted module MUST > exactly match the data contained in the "schema" entries associated > with the mount point. > > There is text about a "schema" list in 3.2 that I think is not > needed anymore. Yes, will remove. > * RPC operations and notifications > > "clients can invoke this operation by representing it as an action > defined for the corresponding mount point" > > The wording 'invoke ... by representing" seems wrong. I think this > should be "clients can invoke this operation as if it were defined > as an action for the corresponding mount point" or something like > this. Ok. > Should there be additional text discussing how parameters of > operations and notification content is interpreted? I assume > everything is scoped to the mount point but perhaps this needs to be > stated explicitly. I think this handling follows from "as if it was defined as an action...". > * Data model > > The model is augmenting /yanglib:yang-library/yanglib:schema. In > the case where I had two different schemas defined for say the > operational state datastore and conventional datastores, this > implies that I have to duplicate the schema-mounts specific > definitions even in the likely case where the schema mounts are > identical in both datastores. Yes, but you can define a sinlge module-set and refer to it from both schemas. > (For the extern 'inline' case they > actually have to be the same or at least the operational state > datastore schema-mounts have to be a superset of the conventional > datastore schema-mounts since otherwise I can't get the schema > information. So the question is whether schema-mount should be a > list directly under /yanglib:yang-library and then > /yanglib:yang-library/yanglib:schema would be augmented by a leaf > (or a leaf-list) referring to schema-mount entries. > > * YANG definitions > > I think the description of the leaf 'inline' [yeah, this should be > 'external'] needs to be updated to explain where in an NMDA system > the YANG library information can be found. Ok, we should add that it is available in . > And yes, 'use-schema' is really what I call 'inline' - the schema > information is provided as part of the YANG library defining the > mount point. > > * Security considerations > > I was expecting text that explains how NACM works on a server that > has schema mounts, discussing both cases, the inline and external > schema mount cases. We had a discussion about this on the ML, I have to get back and re-read it. /martin > > * Examples > > I have not reviewed the examples. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Feb 6 01:39:52 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6A8E129C5D for ; Tue, 6 Feb 2018 01:39:50 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eoWgWlamMFwX for ; Tue, 6 Feb 2018 01:39:48 -0800 (PST) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id CEF3A126CE8 for ; Tue, 6 Feb 2018 01:39:47 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id B36CC2619A1 for ; Tue, 6 Feb 2018 10:39:48 +0100 (CET) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gPQ+7lSwwNlA for ; Tue, 6 Feb 2018 10:39:46 +0100 (CET) Received: from Kristians-MacBook-Pro.local (c-1789e455.014-82-73746f13.cust.bredbandsbolaget.se [85.228.137.23]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 02C8C2618BC for ; Tue, 6 Feb 2018 10:39:46 +0100 (CET) To: netmod@ietf.org References: <151762118030.14613.16606991699665016537@ietfa.amsl.com> <37914E8C-1A57-4ECF-A865-D8880169F454@gmail.com> From: Kristian Larsson Message-ID: <84f42879-1a49-d023-3a62-afbbcb53d73e@spritelink.net> Date: Tue, 6 Feb 2018 10:42:15 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <37914E8C-1A57-4ECF-A865-D8880169F454@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-16.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 09:39:51 -0000 Mahesh, I suppose, since you posted the update Friday night, that I missed my chance of prettifying the source/destination port choice/container structure that was just added. If not, it's in a PR towards your repo - https://github.com/mjethanandani/acl-model/pull/4 Kind regards, Kristian. On 2018-02-03 02:41, Mahesh Jethanandani wrote: > This update addresses the comments that were received as part of LC. For those of you who commented on the draft during the LC, please verify that your comments have been addressed. > > Thanks. > >> On Feb 2, 2018, at 5:26 PM, internet-drafts@ietf.org wrote: >> >> >> A New Internet-Draft is available from the on-line Internet-Drafts directories. >> This draft is a work item of the Network Modeling WG of the IETF. >> >> Title : Network Access Control List (ACL) YANG Data Model >> Authors : Mahesh Jethanandani >> Lisa Huang >> Sonal Agarwal >> Dana Blair >> Filename : draft-ietf-netmod-acl-model-16.txt >> Pages : 54 >> Date : 2018-02-02 >> >> Abstract: >> This document describes a data model of Access Control List (ACL) >> basic building blocks. >> >> Editorial Note (To be removed by RFC Editor) >> >> This draft contains many placeholder values that need to be replaced >> with finalized values at the time of publication. This note >> summarizes all of the substitutions that are needed. Please note >> that no other RFC Editor instructions are specified anywhere else in >> this document. >> >> Artwork in this document contains shorthand references to drafts in >> progress. Please apply the following replacements >> >> o "XXXX" --> the assigned RFC value for this draft both in this >> draft and in the YANG models under the revision statement. >> >> o Revision date in model needs to get updated with the date the >> draft gets approved. The date also needs to get reflected on the >> line with . >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ >> >> There are also htmlized versions available at: >> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 >> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-16 >> >> A diff from the previous version is available at: >> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-16 >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > Mahesh Jethanandani > mjethanandani@gmail.com > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Tue Feb 6 05:43:34 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A250B12D7ED for ; Tue, 6 Feb 2018 05:43:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6tY8q4y_NKOa for ; Tue, 6 Feb 2018 05:43:28 -0800 (PST) Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 992BB12AF84 for ; Tue, 6 Feb 2018 05:43:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1648; q=dns/txt; s=iport; t=1517924607; x=1519134207; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=ZX0it3ZMXt2NekHyLBr0rdyHOV50q5MCE4+y0MKYCF4=; b=g115op7VM5MAy+ehtxkwWIG+B9hNfu4qeQ82xArKS7iaMHdCSoY1Svga uegY9IYsEHHWpbf7pur4T9JjMkx+aQmjDYf7a2Y3kOAa9qn8cEtbYJUY1 Z2iicFUeEOvuI8HKcqawY54Pgs/ViDPlnf4KUrOQdifWwNq58Jms04KN3 c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQB2sHla/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUnKINlixiPP5lgCoU7AoMxFAEBAQEBAQEBAmsohSQBBSMECwE?= =?us-ascii?q?FQRALDgIIAgImAgJXBgEMBgIBAYoxtmKBbTqFAIN7gXgBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEggQ+DW4NsghGDBYMvBIE7g0uCZQEEimmZRJV0jDeIBI9niBeBPDYigVA?= =?us-ascii?q?zGggbFYMDhHdBN48mAQEB?= X-IronPort-AV: E=Sophos;i="5.46,468,1511827200"; d="scan'208";a="1847239" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 13:43:23 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w16DhNlf022014; Tue, 6 Feb 2018 13:43:23 GMT To: Martin Bjorklund , j.schoenwaelder@jacobs-university.de Cc: netmod@ietf.org References: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> <20180206083344.o5vqjwwtkq7awrxy@elstar.local> <20180206.101949.156510094898094470.mbj@tail-f.com> From: Robert Wilton Message-ID: <03e2804c-d8bb-1ff1-f5de-1af25c366e42@cisco.com> Date: Tue, 6 Feb 2018 13:43:23 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180206.101949.156510094898094470.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 13:43:30 -0000 On 06/02/2018 09:19, Martin Bjorklund wrote: > Hi Juergen, > > Thanks for your review, comments inline. > > Juergen Schoenwaelder wrote: > >> * YANG library has a drawing of the underlying conceptual model. It >> may help to agree on how schema mount is extending the model. Here >> is a drawing that I created for myself: >> >> +-----------+ >> | datastore | >> +-----------+ >> | >> | has a >> V >> +-----------+ +--------+ +------------+ >> | datastore | union of | module | consists of | modules + | >> .----->| schema |----------->| set |--------------->| submodules | >> | +-----------+ +--------+ +------------+ >> | | >> | | has >> | v >> | +-----------+ >> '------| mount |------> external YANG library >> uses | points | uses schema reference >> +-----------+ >> >> Note that this makes drawing makes my struggle with the term >> 'inline' even more obvious. > I like the drawing, but I don't see the problem with the terms. Maybe > just b/c I'm used to them. I think we can include this figure but > s/external/inline/ I think that Juergen's diagram is helpful. I also think that there needs to be some text to help explain how mount points interact with datastores.  I.e. each datastore can have separate mount points so data could be mounted in but not or vice-versa. Thanks, Rob From nobody Tue Feb 6 05:45:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6F1BB12D7E4 for ; Tue, 6 Feb 2018 05:45:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -12.52 X-Spam-Level: X-Spam-Status: No, score=-12.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4ACVdsm3Ds8L for ; Tue, 6 Feb 2018 05:45:45 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4AAB12AF84 for ; Tue, 6 Feb 2018 05:45:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7472; q=dns/txt; s=iport; t=1517924744; x=1519134344; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=t3SAlmd14M4w54aseNbj47xsxfy0CW04tYkVRoZ0KFQ=; b=KSFRFyaS2a71OglhimOAt4gg2wqYHcpxcUao7Ewl2+PjRqwExnmPUCyC OhJuvyD7bZhjKfLAkdz0i2f3PkAr3vBtD5lRek4sUPCOxtzjie9fjGmxK wdv1bsigYmzpvvzi4HEkIJCIOWpCDoET4suEh/mVmRrANCFU7Zuj5o5BE 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQAWsXla/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMkgRNwKINlixiPP5Fzh20KGAEFhE5PAoMxFAEBAQEBAQEBAms?= =?us-ascii?q?ohSQBAQQBASFLGwsOCioCAicwBgEMBgIBAReKGhC2WoInJoRag3uBeAEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBARgFhGqDbIIRgwWDLwEBAhmBQIMtgmUFpC2IGo1agh6?= =?us-ascii?q?GJoNziASLDIJlgXaIF4E8NiIlgSszGggbFT2CRoN7AQhzQTcBAQGPIwEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,468,1511827200"; d="scan'208,217";a="1841783" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 13:45:37 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w16DjaVf003136; Tue, 6 Feb 2018 13:45:37 GMT To: Kent Watsen , "netmod@ietf.org" , Martin Bjorklund , Ladislav Lhotka References: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> From: Robert Wilton Message-ID: Date: Tue, 6 Feb 2018 13:45:36 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> Content-Type: multipart/alternative; boundary="------------7B3DF82DB9F908C0559419C5" Content-Language: en-US Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 13:45:47 -0000 This is a multi-part message in MIME format. --------------7B3DF82DB9F908C0559419C5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, Some comments on the pre-09 version, particularly the data model. 1) I still don't get why this draft is called "YANG Schema Mount" rather than "YANG Mount", since to me this implies that it *only* the schema that is being made available, and by implication not the instance data.  I.e. I can see what schema a VM is using, but I cannot access the instance data of that VM. I understand the scope of the draft (and I'm not trying to change that at all), and agree that it doesn't specify any protocol for how to remotely mount data (e.g. peer mount).  But my understanding of the solution here is that it doesn't just mount the schema.  I think that it also always makes the mounted instance data available using the regular NETCONF/RESTCONF operations right?  Which sounds like it is doing more than just mounting the schema! 2) Regarding the YANG Data Model: (i) Should "schema-mounts" just be "mounts", since it is already under the "schema" container. (ii) Should "parent-references" be part of the "use-schema" container, or should then be part of a schema directly.  E.g. should schema-mount augment yanglib:schema with both a "mounts" container and a "parent-reference" leaflist. (iii) Do we definitely need the namespace list?  Shouldn't the prefixes/namespaces be resolved against the implemented modules in the referenced schema, or is this not sufficient?  If this is not sufficient, I wonder if it would be helpful for the draft to describe this. (iv) I agree with Juergen that "inline" is a confusing term because it is meaning that the mounted schema is available inline in the instance data tree, not that it is inline in the schema tree. Thanks, Rob On 31/01/2018 21:36, Kent Watsen wrote: > All, > > The authors created a "pre09" branch on GitHub a few weeks back. On this branch, they completed a full update of the draft. While waiting for details on how to proceed with regards to a SM-bis, we thought it would be helpful to make this text available now so that the technical parts can be discussed. With this in mind, can folks please have a quick look and post any technical comments they have? > > > The "txt" version of the draft: https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt > > > rfcdiff against the current -08 draft: https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08&url2=https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt > > > Since rfc7895bis obsoletes RFC 7895, the server-must-implement-rfc7895bis requirement is no surprise, right? > > Thanks, > Kent // shepherd > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > . > --------------7B3DF82DB9F908C0559419C5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

Some comments on the pre-09 version, particularly the data model.


1) I still don't get why this draft is called "YANG Schema Mount" rather than "YANG Mount", since to me this implies that it *only* the schema that is being made available, and by implication not the instance data.  I.e. I can see what schema a VM is using, but I cannot access the instance data of that VM.

I understand the scope of the draft (and I'm not trying to change that at all), and agree that it doesn't specify any protocol for how to remotely mount data (e.g. peer mount).  But my understanding of the solution here is that it doesn't just mount the schema.  I think that it also always makes the mounted instance data available using the regular NETCONF/RESTCONF operations right?  Which sounds like it is doing more than just mounting the schema!

2) Regarding the YANG Data Model:

(i) Should "schema-mounts" just be "mounts", since it is already under the "schema" container.

(ii) Should "parent-references" be part of the "use-schema" container, or should then be part of a schema directly.  E.g. should schema-mount augment yanglib:schema with both a "mounts" container and a "parent-reference" leaflist.

(iii) Do we definitely need the namespace list?  Shouldn't the prefixes/namespaces be resolved against the implemented modules in the referenced schema, or is this not sufficient?  If this is not sufficient, I wonder if it would be helpful for the draft to describe this.

(iv) I agree with Juergen that "inline" is a confusing term because it is meaning that the mounted schema is available inline in the instance data tree, not that it is inline in the schema tree.

Thanks,
Rob


On 31/01/2018 21:36, Kent Watsen wrote:
All,

The authors created a "pre09" branch on GitHub a few weeks back.  On this branch, they completed a full update of the draft.  While waiting for details on how to proceed with regards to a SM-bis, we thought it would be helpful to make this text available now so that the technical parts can be discussed.  With this in mind, can folks please have a quick look and post any technical comments they have?  


The "txt" version of the draft:  https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt


rfcdiff against the current -08 draft:  https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08&url2=https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt


Since rfc7895bis obsoletes RFC 7895, the server-must-implement-rfc7895bis requirement is no surprise, right?

Thanks,
Kent // shepherd


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

--------------7B3DF82DB9F908C0559419C5-- From nobody Tue Feb 6 06:01:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B856312D7F4 for ; Tue, 6 Feb 2018 06:01:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ancieay_DlIB for ; Tue, 6 Feb 2018 06:00:53 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A78E812D7E7 for ; Tue, 6 Feb 2018 06:00:53 -0800 (PST) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 0A0B21AE02C9; Tue, 6 Feb 2018 15:00:50 +0100 (CET) Date: Tue, 06 Feb 2018 15:00:49 +0100 (CET) Message-Id: <20180206.150049.1814182722336587134.mbj@tail-f.com> To: rwilton@cisco.com Cc: kwatsen@juniper.net, netmod@ietf.org, lhotka@nic.cz From: Martin Bjorklund In-Reply-To: References: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 14:01:01 -0000 Hi, Thanks for your comments, see inline. Robert Wilton wrote: > Hi, > = > Some comments on the pre-09 version, particularly the data model. > = > = > 1) I still don't get why this draft is called "YANG Schema Mount" > rather than "YANG Mount", since to me this implies that it *only* the= > schema that is being made available, and by implication not the > instance data.=A0 I.e. I can see what schema a VM is using, but I can= not > access the instance data of that VM. > = > I understand the scope of the draft (and I'm not trying to change tha= t > at all), and agree that it doesn't specify any protocol for how to > remotely mount data (e.g. peer mount).=A0 But my understanding of the= > solution here is that it doesn't just mount the schema.=A0 I think th= at > it also always makes the mounted instance data available using the > regular NETCONF/RESTCONF operations right?=A0 Which sounds like it is= > doing more than just mounting the schema! Once you have a mounted schema, even in the inline case, a server might be just a single normal server with no extra VMs or anything; you just have a nested schema. Such a server would allow you to use normal edit-config to add mounted data, and it would just affect that single server's database and instrumentation. The point is that schema mount says nothing about *how* things are instantiated. Peer mount, OTOH, attaches instance-specific meaning to its mount points - if you try to write to peer mounted data the server will act as a "proxy" and write to the remote server. (ok, current peer mount is defined to be read-only, but you get my point). > 2) Regarding the YANG Data Model: > = > (i) Should "schema-mounts" just be "mounts", since it is already unde= r > the "schema" container. I don't have a strong opinion on this. > (ii) Should "parent-references" be part of the "use-schema" container= , > or should then be part of a schema directly.=A0 E.g. should schema-mo= unt > augment yanglib:schema with both a "mounts" container and a > "parent-reference" leaflist. This would mean the same parent-references for all mount points in a schema, as opposed to per-mount-point parent-references as we have today. Lada, what's your opinion on this? > (iii) Do we definitely need the namespace list?=A0 Shouldn't the > prefixes/namespaces be resolved against the implemented modules in th= e > referenced schema, or is this not sufficient?=A0 If this is not > sufficient, I wonder if it would be helpful for the draft to describe= > this. It is not sufficient b/c the only prefixes available from the implemented modules are the prefixes in the modules themselves, and they aren't necessarily unique. > (iv) I agree with Juergen that "inline" is a confusing term because i= t > is meaning that the mounted schema is available inline in the instanc= e > data tree, not that it is inline in the schema tree. /martin > = > Thanks, > Rob > = > = > On 31/01/2018 21:36, Kent Watsen wrote: > > All, > > > > The authors created a "pre09" branch on GitHub a few weeks back. O= n > > this branch, they completed a full update of the draft. While wait= ing > > for details on how to proceed with regards to a SM-bis, we thought = it > > would be helpful to make this text available now so that the techni= cal > > parts can be discussed. With this in mind, can folks please have a= > > quick look and post any technical comments they have? > > > > > > The "txt" version of the draft: > > https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draf= t-ietf-netmod-schema-mount-pre-09.txt > > > > > > rfcdiff against the current -08 draft: > > https://www.ietf.org/rfcdiff?url1=3Ddraft-ietf-netmod-schema-mount-= 08&url2=3Dhttps://raw.githubusercontent.com/netmod-wg/schema-mount/pre0= 9/draft-ietf-netmod-schema-mount-pre-09.txt > > > > > > Since rfc7895bis obsoletes RFC 7895, the > > server-must-implement-rfc7895bis requirement is no surprise, right?= > > > > Thanks, > > Kent // shepherd > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > . > > > = From nobody Tue Feb 6 06:17:04 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6AB3C12E042 for ; Tue, 6 Feb 2018 06:17:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MWzaizAhZeSB for ; Tue, 6 Feb 2018 06:17:00 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D6F0126B72 for ; Tue, 6 Feb 2018 06:17:00 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 30283F91; Tue, 6 Feb 2018 15:16:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Vb9QAUdYYCgW; Tue, 6 Feb 2018 15:16:56 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 6 Feb 2018 15:16:59 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 15F4620149; Tue, 6 Feb 2018 15:16:59 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id VOTy1vIdYJj8; Tue, 6 Feb 2018 15:16:58 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D708320147; Tue, 6 Feb 2018 15:16:57 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 08827423A4AD; Tue, 6 Feb 2018 15:16:55 +0100 (CET) Date: Tue, 6 Feb 2018 15:16:55 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: kwatsen@juniper.net, netmod@ietf.org Message-ID: <20180206141655.6iast3lbhubk6rk5@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , kwatsen@juniper.net, netmod@ietf.org References: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> <20180206083344.o5vqjwwtkq7awrxy@elstar.local> <20180206.101949.156510094898094470.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180206.101949.156510094898094470.mbj@tail-f.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 14:17:03 -0000 On Tue, Feb 06, 2018 at 10:19:49AM +0100, Martin Bjorklund wrote: > Hi Juergen, > > Thanks for your review, comments inline. > > Juergen Schoenwaelder wrote: > > On Wed, Jan 31, 2018 at 09:36:07PM +0000, Kent Watsen wrote: > > > > > > The authors created a "pre09" branch on GitHub a few weeks back. On this branch, they completed a full update of the draft. While waiting for details on how to proceed with regards to a SM-bis, we thought it would be helpful to make this text available now so that the technical parts can be discussed. With this in mind, can folks please have a quick look and post any technical comments they have? > > > > > > > I have reviewed draft-ietf-netmod-schema-mount-pre-09 that I fetched > > today from GitHub. Here are my comments: > > > > * Perhaps the abstract can be improved. The single sentence that we > > have is not even quite correct. > > > > This document defines a mechanism to combine YANG modules into the > > schema defined in other YANG modules. > > > > According to YL bis, a datastore has a schema, which consists of a > > set of YANG modules. The terminology used in RFC 7950 is 'schema > > node' and 'schema tree'. Perhaps this sentence can be rewritten to > > better explain the purpose of this document. > > Maybe something along the lines of: > > This document defines a mechanism to extend a datastore schema with > other schemas. > > It is still a bit terse... One question here is: Does the datastore schema include the mounted schema tree or not? We can side step this question by writing: This document defines a mechanism to extend a YANG schema tree with other schema trees. This is still terse but I think in terms of terminology this is clear and correct. > > * Definition of inline schema: > > > > o inline schema: a mounted schema whose definition is provided as > > part of the mounted data, using YANG library > > [I-D.ietf-netconf-rfc7895bis]. > > > > I am not sure 'as part of the mounted data, using YANG library' is > > a good definition. Which YANG library? I think what this term means > > is a mount point specific YANG library, not the master server's > > YANG library. > > > > This is also why I was largely confused about the inline case; the > > schema used by the mountpoint is not defined inline from the master > > server's point of view, from which the document is written. From > > the master server's point of view, the 'inline schema' is actually > > the opposite, it is an 'external schema' since I have to pull the > > schema information from an external source; > > No this is not quite correct. It is "inline" from the master's point > of view, in the sense of "inline in the data tree", as opposed to > "part of the (augmented) yang-library schema definition". This means its inline from the viewpoint of the mounted data, it is external from the viewpoint of the master. You are swapping the viewpoint here. > And it is *not* external. The client still fetches this data from the > "master" server; and how the master server handles this is an > implementation detail (or possibly standardized in the future - *one* > use case is peer mount in which case the data is fetched from another > system, but again, this is just one example). It is external from the viewpoint of the master servers YANG library. The schema sits in a different YANG library instantiation. I have to fetch this separately. This makes it kind of external for me. > > * YANG library has a drawing of the underlying conceptual model. It > > may help to agree on how schema mount is extending the model. Here > > is a drawing that I created for myself: > > > > +-----------+ > > | datastore | > > +-----------+ > > | > > | has a > > V > > +-----------+ +--------+ +------------+ > > | datastore | union of | module | consists of | modules + | > > .----->| schema |----------->| set |--------------->| submodules | > > | +-----------+ +--------+ +------------+ > > | | > > | | has > > | v > > | +-----------+ > > '------| mount |------> external YANG library > > uses | points | uses schema reference > > +-----------+ > > > > Note that this makes drawing makes my struggle with the term > > 'inline' even more obvious. > > I like the drawing, but I don't see the problem with the terms. Maybe > just b/c I'm used to them. I think we can include this figure but > s/external/inline/ Inline suggests to me that the schema details are reported inline of this YANG library instantiation, i.e. the opposite of today's "inline" case. In today's "inline" case, I have to fetch a different YANG library instance and look things up there. I find it very confusing to call this "inline" and the inline case "use-schema". I understand the resistance to change terms at this point in time but then the figure makes it somewhat obvious why "inline" confused me a lot since I look at things from the master server's perspective, i.e., from the master server's yang library perspective. > > * Where is the schema defined in the external aka 'inline' case? > > The current text says: > > > > In case 1, the mounted schema is determined at run time: every > > instance of the mount point that exists in the parent tree MUST > > contain a copy of YANG library data [I-D.ietf-netconf-rfc7895bis] > > that defines the mounted schema exactly as for a top-level data > > model. A client is expected to retrieve this data from the instance > > tree, possibly after creating the mount point. Instances of the same > > mount point MAY use different mounted schemas. > > > > I think this does not work for datastores except the operational > > datastore. In fact, I think the model must be that if /foo is an > > external 'inline' mountpoint, then the /foo instance in the > > operational state datastore must include a YANG library > > instantiation in which a client can find the schema definition for > > /foo in any datastore where /foo is supported. In other words, if > > /foo is config true and a client wants to know how the /foo schema > > in , then the client has to fetch the YANG library residing > > under /foo in in order to obtain the schema > > information for the datastore. The text does not say any > > of this. > > I agree. We can write: > > A client is expected to retrieve this data from the instance > tree in , > > and possibly add your example. Better but I would prefer to have a very clear description how the client resolves "inline" schemas by consulting other instantiations of the YANG library - and how this works with NMDA datastores. An example likely helps. > > * Data model > > > > The model is augmenting /yanglib:yang-library/yanglib:schema. In > > the case where I had two different schemas defined for say the > > operational state datastore and conventional datastores, this > > implies that I have to duplicate the schema-mounts specific > > definitions even in the likely case where the schema mounts are > > identical in both datastores. > > Yes, but you can define a sinlge module-set and refer to it from both > schemas. Well, the modules supported by the two datastore schemas can be different so I have to have two schema definitions... /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 Feb 6 06:39:34 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B333712D7EF for ; Tue, 6 Feb 2018 06:39:32 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yere6TLR4nGJ for ; Tue, 6 Feb 2018 06:39:30 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0C4A512D7EC for ; Tue, 6 Feb 2018 06:39:29 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6064; q=dns/txt; s=iport; t=1517927970; x=1519137570; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=WximwF15Fjoy4vMlHYXVo1T3xp0BhajHxR4PiqKKwl0=; b=lhlqtjU9u1WX6JzKv65t6AG570aC7JhLy8CC4TatHIVp/UAo3IeqizG+ g/NTOKxuZutvPfAKLZ2W+bMcZSCRZFuylL2HeGeIbyfPeeGWpaDxJJ4o3 IHSnuXdzveIGgT7KPcSLlP/9fsRF2kA67bE2KZwVpCwGlH4DuNsiZIvdN A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BzAQDKvHla/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ3cCiDZYsYjz+ZYAoYBoROTwKDNBQBAQEBAQEBAQJrKIUjAQE?= =?us-ascii?q?BAwEBASEPAQU2CwULCw4KAgImAgInMAYNBgIBAReKEggQtjCCJ4UAg3yBeAEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBARgFgQ+DW4NsgWgpgwWDLwEBAhmBQIMtgmUFkku?= =?us-ascii?q?RY4gajVqCHoYng3Mmh16LDIJlgXiIF4E8NiI/gREzGggbFT2CRoR3QTcBAQGPF?= =?us-ascii?q?wEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,469,1511827200"; d="scan'208";a="1895792" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 14:39:28 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w16EdRDC009689; Tue, 6 Feb 2018 14:39:27 GMT To: Martin Bjorklund Cc: kwatsen@juniper.net, netmod@ietf.org, lhotka@nic.cz References: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> <20180206.150049.1814182722336587134.mbj@tail-f.com> From: Robert Wilton Message-ID: <254903d0-052d-c38c-6a6e-a841acc504cd@cisco.com> Date: Tue, 6 Feb 2018 14:39:27 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180206.150049.1814182722336587134.mbj@tail-f.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 14:39:33 -0000 Hi Martin, On 06/02/2018 14:00, Martin Bjorklund wrote: > Hi, > > Thanks for your comments, see inline. > > Robert Wilton wrote: >> Hi, >> >> Some comments on the pre-09 version, particularly the data model. >> >> >> 1) I still don't get why this draft is called "YANG Schema Mount" >> rather than "YANG Mount", since to me this implies that it *only* the >> schema that is being made available, and by implication not the >> instance data.  I.e. I can see what schema a VM is using, but I cannot >> access the instance data of that VM. >> >> I understand the scope of the draft (and I'm not trying to change that >> at all), and agree that it doesn't specify any protocol for how to >> remotely mount data (e.g. peer mount).  But my understanding of the >> solution here is that it doesn't just mount the schema.  I think that >> it also always makes the mounted instance data available using the >> regular NETCONF/RESTCONF operations right?  Which sounds like it is >> doing more than just mounting the schema! > Once you have a mounted schema, even in the inline case, a server > might be just a single normal server with no extra VMs or anything; > you just have a nested schema. Such a server would allow you to use > normal edit-config to add mounted data, and it would just affect that > single server's database and instrumentation. OK.  So, it is not just the schema that is available, but also the instance data associated with that schema. > The point is that schema mount says nothing about *how* things are > instantiated. I agree. But I think that is also consistent with how the term "mount" is used from its Unix heritage. I.e. just because some data is mounted doesn't imply that it is remote.  E.g. if I look at my Linux VM's /etc/mtab I see a dozen mount points, only one of which I would class as being remote (from the perspective of the VM). Whereas, to me the term "schema mount" implies that it is only the schema that are being mounted.  Why would there be instance data available if the only thing that is being mounted is the schema? > > Peer mount, OTOH, attaches instance-specific meaning to its mount > points - if you try to write to peer mounted data the server will act > as a "proxy" and write to the remote server. (ok, current peer mount > is defined to be read-only, but you get my point). Yes, OK.  But I don't think that the term "YANG Mount" implies "Peer mount". Extending the filesystem analogy further, I think that YANG mount tell you the mounted path, whether it is read/write, and where to find the schema.  It doesn't specify what protocol is being used to access that data.  E.g. in future I could imagine that peer mount might want to augment the mount-point/inline to indicate further properties about the mount point.  But this would seem to be somewhat odd if what it is augmenting is a "YANG schema mount" rather than just a "YANG mount". > >> 2) Regarding the YANG Data Model: >> >> (i) Should "schema-mounts" just be "mounts", since it is already under >> the "schema" container. > I don't have a strong opinion on this. > >> (ii) Should "parent-references" be part of the "use-schema" container, >> or should then be part of a schema directly.  E.g. should schema-mount >> augment yanglib:schema with both a "mounts" container and a >> "parent-reference" leaflist. > This would mean the same parent-references for all mount points in a > schema, as opposed to per-mount-point parent-references as we have > today. Lada, what's your opinion on this? > >> (iii) Do we definitely need the namespace list?  Shouldn't the >> prefixes/namespaces be resolved against the implemented modules in the >> referenced schema, or is this not sufficient?  If this is not >> sufficient, I wonder if it would be helpful for the draft to describe >> this. > It is not sufficient b/c the only prefixes available from the > implemented modules are the prefixes in the modules themselves, and > they aren't necessarily unique. OK.  So would another choice could be to rather than having the namespace map from  prefix to namespace, instead have it as a map from prefix to module name (which is resolved against the implemented modules in the parent schema(s))? The URI would still be available form the module entry in the parent schema (if required).  I'm just wondering whether this would make the binding feel a bit less XML encoding specific. Thanks, Rob > >> (iv) I agree with Juergen that "inline" is a confusing term because it >> is meaning that the mounted schema is available inline in the instance >> data tree, not that it is inline in the schema tree. > > > /martin > > > >> Thanks, >> Rob >> >> >> On 31/01/2018 21:36, Kent Watsen wrote: >>> All, >>> >>> The authors created a "pre09" branch on GitHub a few weeks back. On >>> this branch, they completed a full update of the draft. While waiting >>> for details on how to proceed with regards to a SM-bis, we thought it >>> would be helpful to make this text available now so that the technical >>> parts can be discussed. With this in mind, can folks please have a >>> quick look and post any technical comments they have? >>> >>> >>> The "txt" version of the draft: >>> https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt >>> >>> >>> rfcdiff against the current -08 draft: >>> https://www.ietf.org/rfcdiff?url1=draft-ietf-netmod-schema-mount-08&url2=https://raw.githubusercontent.com/netmod-wg/schema-mount/pre09/draft-ietf-netmod-schema-mount-pre-09.txt >>> >>> >>> Since rfc7895bis obsoletes RFC 7895, the >>> server-must-implement-rfc7895bis requirement is no surprise, right? >>> >>> Thanks, >>> Kent // shepherd >>> >>> >>> _______________________________________________ >>> netmod mailing list >>> netmod@ietf.org >>> https://www.ietf.org/mailman/listinfo/netmod >>> . >>> > . > From nobody Tue Feb 6 07:26:00 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EFF1512D84E for ; Tue, 6 Feb 2018 07:25:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Wo2ogKBPCk49 for ; Tue, 6 Feb 2018 07:25:56 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7973B126FDC for ; Tue, 6 Feb 2018 07:25:55 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4392; q=dns/txt; s=iport; t=1517930755; x=1519140355; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=TC+OfsXlezBUofNdOHKT1gH4qKiqsRkh2nfalsiNz2Q=; b=EB9PE+UYix57QmdvZ48R2SCrlxUvWSK8q1U4SdhRav1TV8vU6iHR89qu +wylFFpDN01QDhf0e/q4wZbZAyQWmb+FbDLMvWUo0pClpvEIMADPNpS3J 7aUVYwFIC0CLrnCQe8Zp4w/f8nDxZtXQKkdMzMDTYQIHd/VLNodEMGTUc Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQDVx3la/xbLJq1bGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMkggMog2WLGI8YJ5lgCoU7AoM0FAEBAQEBAQEBAmsohSQBBSM?= =?us-ascii?q?VUQsOAggCAiYCAlcGAQwGAgEBijG2LYInhQCDfIF4AQEBAQEBAQECAQEBAQEBA?= =?us-ascii?q?SGBD4Nbg2yCEQyCeYMvBIFZgy2CZQEEpC6VdIIehieDc4gEiwyEXYgXgTw2IoF?= =?us-ascii?q?QMxoIGxWDA4N7AQhzQTePGgEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,469,1511827200"; d="scan'208";a="1895834" 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; 06 Feb 2018 15:25:53 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w16FPrJA002593; Tue, 6 Feb 2018 15:25:53 GMT To: Martin Bjorklund , kwatsen@juniper.net, netmod@ietf.org References: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> <20180206083344.o5vqjwwtkq7awrxy@elstar.local> <20180206.101949.156510094898094470.mbj@tail-f.com> <20180206141655.6iast3lbhubk6rk5@elstar.local> From: Robert Wilton Message-ID: <3f3f9984-0797-1ded-ded4-17543382f628@cisco.com> Date: Tue, 6 Feb 2018 15:25:52 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20180206141655.6iast3lbhubk6rk5@elstar.local> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 15:25:58 -0000 On 06/02/2018 14:16, Juergen Schoenwaelder wrote: > On Tue, Feb 06, 2018 at 10:19:49AM +0100, Martin Bjorklund wrote: >> Hi Juergen, >> >> Thanks for your review, comments inline. >> >> Juergen Schoenwaelder wrote: >>> On Wed, Jan 31, 2018 at 09:36:07PM +0000, Kent Watsen wrote: >>>> The authors created a "pre09" branch on GitHub a few weeks back. On this branch, they completed a full update of the draft. While waiting for details on how to proceed with regards to a SM-bis, we thought it would be helpful to make this text available now so that the technical parts can be discussed. With this in mind, can folks please have a quick look and post any technical comments they have? >>>> >>> I have reviewed draft-ietf-netmod-schema-mount-pre-09 that I fetched >>> today from GitHub. Here are my comments: >>> >>> * Perhaps the abstract can be improved. The single sentence that we >>> have is not even quite correct. >>> >>> This document defines a mechanism to combine YANG modules into the >>> schema defined in other YANG modules. >>> >>> According to YL bis, a datastore has a schema, which consists of a >>> set of YANG modules. The terminology used in RFC 7950 is 'schema >>> node' and 'schema tree'. Perhaps this sentence can be rewritten to >>> better explain the purpose of this document. >> Maybe something along the lines of: >> >> This document defines a mechanism to extend a datastore schema with >> other schemas. >> >> It is still a bit terse... > One question here is: Does the datastore schema include the mounted > schema tree or not? We can side step this question by writing: > > This document defines a mechanism to extend a YANG schema tree with > other schema trees. > > This is still terse but I think in terms of terminology this is > clear and correct. > >>> * Definition of inline schema: >>> >>> o inline schema: a mounted schema whose definition is provided as >>> part of the mounted data, using YANG library >>> [I-D.ietf-netconf-rfc7895bis]. >>> >>> I am not sure 'as part of the mounted data, using YANG library' is >>> a good definition. Which YANG library? I think what this term means >>> is a mount point specific YANG library, not the master server's >>> YANG library. >>> >>> This is also why I was largely confused about the inline case; the >>> schema used by the mountpoint is not defined inline from the master >>> server's point of view, from which the document is written. From >>> the master server's point of view, the 'inline schema' is actually >>> the opposite, it is an 'external schema' since I have to pull the >>> schema information from an external source; >> No this is not quite correct. It is "inline" from the master's point >> of view, in the sense of "inline in the data tree", as opposed to >> "part of the (augmented) yang-library schema definition". > This means its inline from the viewpoint of the mounted data, it is > external from the viewpoint of the master. You are swapping the > viewpoint here. > >> And it is *not* external. The client still fetches this data from the >> "master" server; and how the master server handles this is an >> implementation detail (or possibly standardized in the future - *one* >> use case is peer mount in which case the data is fetched from another >> system, but again, this is just one example). > It is external from the viewpoint of the master servers YANG library. The > schema sits in a different YANG library instantiation. I have to fetch > this separately. This makes it kind of external for me. I think that the term "external" could also be confusing, since I think that sort of implies peer mount like semantics. I would suggest the term "dynamic" instead of "inline " but that could easily be confused with dynamic datastores. Perhaps rather than "inline" another choice could be "discoverable", i.e. the schema is not known, and is dynamically discoverable inline at the mount point. Equally, rather than "use-schema", perhaps a better choice would be "known", i.e. the schema is already known, and made available as part of YANG library. Whether it would be right to change these at this time, I've no idea ... Thanks, Rob From nobody Tue Feb 6 08:18:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87BA812D82E; Tue, 6 Feb 2018 08:18:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZJkqa0IotWqg; Tue, 6 Feb 2018 08:18:39 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5892E12E87F; Tue, 6 Feb 2018 08:18:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11181; q=dns/txt; s=iport; t=1517933917; x=1519143517; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=NVo8OOiiH5OGxsutMYjWIDn9aNJHs51m7Mu7SlTctOA=; b=gH94JNvjYrYv1ezUlTiF7lNwwi7GOg2poZmGwBVxCd3eIeoEBOF4PY+o rXxkG1bpExnD27NliNlSRWwTdRuJL+lxt+m9RA6pSq0xOqA0qa8EIyic7 Lw9YzSW3qGJf2RU7JXi2q9IFk6QL1pRavk+jDEaMNGNOCZYkieYxfNhDY Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQBv1Hla/xbLJq1TBgMZAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgyCBF3Aog2WLGI8/iROOSoIDChgLhElPAoM0FAEBAQEBAQE?= =?us-ascii?q?BAmsohSMBAQEEAQEhDwEFNgQVAgsOAgIDAwICCQwCDAMCAhsGBh8DDgYBDAYCA?= =?us-ascii?q?QEVAooCAxUQtXCCJ4UAgj8NgTGBeAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFBYE?= =?us-ascii?q?Kg1uDbIFoKYMFgmtEAQECgUUDDwI3Jg8HgjqCZQWaDIlkPpBthQeCHoYng3OBZ?= =?us-ascii?q?YYfjjmBMIgXgTw2IoFQMxoIGxU9gkaCVRyCBkE3cItfAiWCJAEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,469,1511827200"; d="scan'208";a="1845007" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 Feb 2018 16:18:35 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w16GIYf8022217; Tue, 6 Feb 2018 16:18:34 GMT To: Mahesh Jethanandani , netconf@ietf.org, netmod@ietf.org References: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com> <20180131181619.ziqdv5peqdeeuhl4@elstar.local> <20180205.184312.338993520253253388.mbj@tail-f.com> <39203004-C003-4C07-A376-006B6F7969D6@gmail.com> From: Robert Wilton Message-ID: Date: Tue, 6 Feb 2018 16:18:34 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <39203004-C003-4C07-A376-006B6F7969D6@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 16:18:42 -0000 Yes, my comment on the YANG library checksum reference has been adequately addressed by the -03 version of the draft. Thanks, Rob On 05/02/2018 21:33, Mahesh Jethanandani wrote: > For folks that provided comments as part of LC, please verify that your comments have been adequately addressed by -03 version of the draft. > > Thanks > > Mahesh Jethanandani > mjethanandani@gmail.com > >> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund wrote: >> >> Hi, >> >> Mahesh Jethanandani wrote: >>> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF. >>> >>> As part of the LC, there were a couple of comments/questions >>> raised. In particular >>> >>> - Vladmir reported an error, which Martin said is fixed in his local copy. >> Fixed. >> >>> - Robert suggested that “/yang-library/checksum†should be a >>> reference. Juergen supported that comment, so I am assuming that >>> that will be incorporated into the draft. >> Yes, fixed. >> >>> - Andy had questions around datastore set to “conventional†>> Fixed. >> >>> , about origin filter limited to 1 source >> Fixed. >> >>> and the behavior of with-defaults. >> There were no additional changes to the document from the discussion >> about this. >> >>> I see some discussion around it with the authors >>> agreeing that some of them need some text clarifying the >>> position. Can the authors please post the suggested text/additions >>> for the WG to review. >>> - Anything else?? >>> >>> Once an updated draft has been posted, I will do a writeup on the >>> drafts and send it to IESG. >> The issues above are now addressed, in >> draft-ietf-netconf-nmda-netconf-03. >> >> There were no additional comments on >> draft-ietf-netconf-nmda-restconf-02, so I believe this version is >> ready. >> >> >> /martin >> >> >>> Thanks. >>> >>>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder wrote: >>>> >>>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote: >>>>> I do have one additional thought below on draft-ietf-netmod-revised-datastores section 5.3 default handling process. See in-line... >>>>> >>>> Well, this document is with the RFC editor now. I do not think it needs >>>> clarification. It already has text in 5.3 such as: >>>> >>>> Requests to retrieve nodes from always return the value >>>> in use if the node exists, regardless of any default value specified >>>> in the YANG module. If no value is returned for a given node, then >>>> this implies that the node is not used by the device. >>>> >>>> /js >>>> >>>>> From: Robert Wilton -X, January 31, 2018 6:31 AM >>>>> >>>>> >>>>> Hi Andy, >>>>> >>>>> On 31/01/2018 09:22, Andy Bierman wrote: >>>>> >>>>> >>>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder >> wrote: >>>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: >>>>>> Hi, >>>>>> >>>>>> I have some questions about these drafts. >>>>>> >>>>>> 1) what if datastore set to "conventional"? >>>>>> There are many places where a datastore-ref type is used. >>>>>> However, "conventional" is valid for base "datastore", even though >>>>>> it is ambiguous as a datastore selector. >>>>> We can add explicit text that an identity that does not resolve to a >>>>> datastore implemented by the server results in an invalid value error. >>>>> >>>>> >>>>> OK >>>>> >>>>> >>>>>> 2) origin filter is limited to 1 source >>>>>> This filtering seems rather limited. A client must retrieve >>>>>> and check >>>>>> all the values in use, then make repeated requests for each source as a >>>>>> different >>>>>> leaf >>>>> If the client does , then it has all origin information >>>>> and it can filter locally. That said, we could make origin-filter a >>>>> leaf-list which is logically ORed so that one can retrieve >>>>> origin-filter=or:system or origin-filter=or:learned in one request. >>>>> >>>>> >>>>> OK >>>>> >>>>>> 3) with-defaults broken >>>>>> The operational datastore does not support with-defaults. >>>>>> Instead, the client must use origin-filter=or:default or with-origin >>>>>> and check all the origin attributes. Since a client needs to use >>>>>> with-defaults for other datastores, this special handling of >>>>>> >>>>>> seems unhelpful. >>>>> I think the with-defaults semantics for conventional configuration >>>>> datastores are much more complicated than necessary for the >>>>> operational state datastore. Note that that the operational state >>>>> datastore reports in-use values not really defaults: >>>>> >>>>> foo >>>>> >>>>> This reports that the value 'foo' is in use and that it originates >>>>> from a default value. Note that this could also be >>>>> >>>>> foo >>>>> >>>>> in case the intended configuration datastore configured the value >>>>> 'foo' (despite this value matching the default). The with-defaults >>>>> solution is pretty complex because it tries to handle how different >>>>> systems deal with configuration defaults. The idea is to not carry >>>>> this complexity over to in-use values in the operational state >>>>> datastore. >>>>> >>>>> >>>>> Before NMDA, the client could decide if it wanted to retrieve default nodes or not. >>>>> This client-choice has been removed from NMDA, which is a problem. >>>>> We tried to reach a sensible compromise on the data returned from operational (defined in section 5.3 of the NMDA architecture): >>>>> - it should return explicit values for everything that is affecting the actual running state of the device (regardless of whether the operational value matches a schema default value). >>>>> - it does not need to, and should not, return operational values for stuff that isn't actually in use, i.e. don't return needless and unwanted data. >>>>> >>>>> In particular, if no value is returned from a particular data node in then, barring mgmt protocol errors, a client can assume that any functionality associated with that data node is off (i.e. not in use). >>>>> >>>>> Some examples to illustrate the behavior: >>>>> >>>>> (i) If a protocol, e.g. OSPF, is not enabled/running then does not need to return any data for it. It would be reasonable to return a flag to indicate that OSPF is not enabled/running. >>>>> >>>>> (ii) If you have some funky widget on an interface that defaults to being off and isn't being used then don't need to return any data for it. >>>>> >>>>> (iii) But, if you have some funky widget on an interface that defaults to being on, then the server should return data for it. If it is actually enabled, then it would indicate that it is on and return any associated values with its operational state, or if it is disabled then it should explicitly report that it is off. >>>>> >>>>> (iv) I would regard that all applied configuration is "in use" by the system, even if it matches the default value, and hence it should be reported. >>>>> >>>>> >>>>> This behavior for is obviously slightly different from the existing with-default handling that is supported for configuration datastores. As I recall, there were a couple of reasons that we decided to have a different behavior for : >>>>> (a) to have consistent semantics for all servers, rather than different servers supporting different with-defaults behaviors (which makes life harder for clients because they must cope with all variants). >>>>> (b) to remove any potential ambiguity if data isn't returned. I.e. with the existing with-defaults semantics it is not clear to me that servers will always return an explicit value to indicate that a particular widget is off if the schema defines that the default it that is enabled. If the server doesn't support a given widget at all, it is quite plausible that it will just return no data for it. In theory features/deviations should handle this, but those don't work so well if different linecards have different capabilities. Hence being explicit about stuff that is in use seems more robust. >>>>> >>>>> These are good examples. It would be great if section 5.3 could be tweaked to make clearer the relationship between running datastore defaults and other operational datastore defaults for the same tree. >>>>> >>>>> For example, let’s say I create a configured subscription, and the default transport protocol is NETCONF. NETCONF will be used for that subscription even though the node might not be populated. In this case, the object would not appear in the running datastore, but MUST* appear in the operational datastore with the default origin (as it is in-use). >>>>> >>>>> This to me is the desired behavior as it doesn’t incorrectly add information to the running datastore, but shows what is in-use within operational. I suspect other such relationships for other operational tree defaults could be asserted, perhaps based on the origin. >>>>> >>>>> (* Maybe ‘MUST eventually’, as obviously there is a temporal relationship between the two datastores.) >>>>> >>>>> Eric >>>>> >>>>> Thanks, >>>>> Rob >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> /js >>>>> >>>>> Andy >>>>> >>>>> -- >>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>>>> Fax: +49 421 200 3103 >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> _______________________________________________ >>>>> >>>>> netmod mailing list >>>>> >>>>> netmod@ietf.org > >>>>> >>>>> https://www.ietf.org/mailman/listinfo/netmod >>>>> >>>>> _______________________________________________ >>>>> 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 >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>> > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf From nobody Tue Feb 6 10:36:48 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DFDA12741D for ; Tue, 6 Feb 2018 10:36:46 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k2JyaLxZuTd0 for ; Tue, 6 Feb 2018 10:36:44 -0800 (PST) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3F4E127522 for ; Tue, 6 Feb 2018 10:36:43 -0800 (PST) Received: by mail-it0-x232.google.com with SMTP id p139so3725747itb.1 for ; Tue, 06 Feb 2018 10:36:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KfNHEhEW1MXFdQf9dG9l4GVd38xo5fzDGK+uFq/3sxY=; b=Pyqf03If+28lFhdd1/okxKbGrU1cpLPRIVlIu6h8ryFLk4PzoVAoLEKZbzeCkyIeZ8 xfhXTmyF6eWINvC8Y2lbWuLmoyEr4az3XcF/xHa0hRuI7HWp6kbSkD5svSR9ZOzeBo6Z igonfhHxL7TjT14nH1AWRMM7PZJgLVJtaRLDOShG3YV8SJd150eaQZ9arYf8HmP8C4JP ZbLA/e6PZ+Lqt9uoYRO8n5cVjr2G+kP5RqwuZPKnxRT1S2K0QLXGxaCZGswu7aJvqUmY EQsCc9lkOIQ1NWxjN0ypZ310wNIYeyPnlqY7JGN07s62q2VtE9Hae4kDjmj7CPfYqUYm 5+zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=KfNHEhEW1MXFdQf9dG9l4GVd38xo5fzDGK+uFq/3sxY=; b=HzqMpFxIUfxTXASpIltwzM5VMIGkuDdJsGvpls/fG7XjdQrHoPLR/wVJ3zIUkb7P0v hPcAeNCifEF8LqVzPIhzVtu4RMtZMhqp+U2XXi5qG0SRs1lwsq3VDDRckdGfWQipgtKG aMbhZVXC8EefBUAR+3MkXeqkM6PUvQqMb6J59t4BNC0q91/TkZAVkNLe1ojb3UYc767A cnD+BBtl0asuuUJ3jP6Zyz5KqLZBXbT9o0DiIJv+fEcO9UCzLsQaUDh/nVElHTg6WDbW xdnclA0M+WnFHGA7+XBOXbWJVsuhv//YKxm0wkIeHgnAXPWzaNFeARcPoiWxpEebnQ4Z OWgQ== X-Gm-Message-State: APf1xPD0HP4oHFrnsk7PXkUXbvcLgOQWVjE/ZMIVYUk7Lk23btxAvhHN rfTtcKUySktTk8HWZt5sELQ+gWCs X-Google-Smtp-Source: AH8x2252SukuO1jy7t44JnuemAF+aeKjRIkKw965Nwj2/W247rS4tOBepbGzhhZijZSVp76Q+OBIPw== X-Received: by 10.36.190.8 with SMTP id i8mr4576777itf.26.1517942203157; Tue, 06 Feb 2018 10:36:43 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:d498:9d84:6f93:f7de]) by smtp.gmail.com with ESMTPSA id l82sm7585099ioe.20.2018.02.06.10.36.42 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 10:36:42 -0800 (PST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Mahesh Jethanandani In-Reply-To: <84f42879-1a49-d023-3a62-afbbcb53d73e@spritelink.net> Date: Tue, 6 Feb 2018 10:36:40 -0800 Cc: netmod@ietf.org Content-Transfer-Encoding: quoted-printable Message-Id: <256632EC-30B7-4353-8B88-045F652432E2@gmail.com> References: <151762118030.14613.16606991699665016537@ietfa.amsl.com> <37914E8C-1A57-4ECF-A865-D8880169F454@gmail.com> <84f42879-1a49-d023-3a62-afbbcb53d73e@spritelink.net> To: Kristian Larsson X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-16.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 18:36:46 -0000 Kristian, As I commented on the PR, putting the =E2=80=98container=E2=80=99 inside = of the =E2=80=98choice=E2=80=99 statement allows me to collapse the = =E2=80=98container=E2=80=99 and the =E2=80=98case=E2=80=99 statement = into a single =E2=80=98container=E2=80=99 statement. With your changes, = I see an additional =E2=80=98case=E2=80=99 statement, bloating the model = in four places. Cheers. > On Feb 6, 2018, at 1:42 AM, Kristian Larsson = wrote: >=20 > Mahesh, >=20 > I suppose, since you posted the update Friday night, that I missed my = chance of prettifying the source/destination port choice/container = structure that was just added. If not, it's in a PR towards your repo - = https://github.com/mjethanandani/acl-model/pull/4 >=20 > Kind regards, > Kristian. >=20 >=20 >=20 > On 2018-02-03 02:41, Mahesh Jethanandani wrote: >> This update addresses the comments that were received as part of LC. = For those of you who commented on the draft during the LC, please verify = that your comments have been addressed. >> Thanks. >>> On Feb 2, 2018, at 5:26 PM, internet-drafts@ietf.org wrote: >>>=20 >>>=20 >>> A New Internet-Draft is available from the on-line Internet-Drafts = directories. >>> This draft is a work item of the Network Modeling WG of the IETF. >>>=20 >>> Title : Network Access Control List (ACL) YANG Data = Model >>> Authors : Mahesh Jethanandani >>> Lisa Huang >>> Sonal Agarwal >>> Dana Blair >>> Filename : draft-ietf-netmod-acl-model-16.txt >>> Pages : 54 >>> Date : 2018-02-02 >>>=20 >>> Abstract: >>> This document describes a data model of Access Control List (ACL) >>> basic building blocks. >>>=20 >>> Editorial Note (To be removed by RFC Editor) >>>=20 >>> This draft contains many placeholder values that need to be = replaced >>> with finalized values at the time of publication. This note >>> summarizes all of the substitutions that are needed. Please note >>> that no other RFC Editor instructions are specified anywhere else = in >>> this document. >>>=20 >>> Artwork in this document contains shorthand references to drafts = in >>> progress. Please apply the following replacements >>>=20 >>> o "XXXX" --> the assigned RFC value for this draft both in this >>> draft and in the YANG models under the revision statement. >>>=20 >>> o Revision date in model needs to get updated with the date the >>> draft gets approved. The date also needs to get reflected on = the >>> line with . >>>=20 >>>=20 >>> The IETF datatracker status page for this draft is: >>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ >>>=20 >>> There are also htmlized versions available at: >>> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 >>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-16 >>>=20 >>> A diff from the previous version is available at: >>> https://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-netmod-acl-model-16 >>>=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 >> Mahesh Jethanandani >> mjethanandani@gmail.com >> _______________________________________________ >> 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 Mahesh Jethanandani mjethanandani@gmail.com From nobody Tue Feb 6 15:47:29 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90F1B126DFB for ; Tue, 6 Feb 2018 15:47:28 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9exXxSqfNxxP for ; Tue, 6 Feb 2018 15:47:26 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BD85C126DCA for ; Tue, 6 Feb 2018 15:47:26 -0800 (PST) Received: from MBP.local ([IPv6:2620:11a:c081:20:384b:fe8:2d52:19df]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w16NlPx0056114 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 6 Feb 2018 23:47:26 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:384b:fe8:2d52:19df] claimed to be MBP.local To: NETMOD Working Group From: joel jaeggli Message-ID: Date: Tue, 6 Feb 2018 15:47:20 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="------------5A0E23C9045183DC47AA4F61" Content-Language: en-US Archived-At: Subject: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 23:47:28 -0000 This is a multi-part message in MIME format. --------------5A0E23C9045183DC47AA4F61 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi, This is the start of a *two* week poll on making draft-rtgyangdt-netmod-module-tags-02 a working group document.=C2=A0=C2=A0= https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 This document was most recently discussed at IETF 100. Please send email to the list indicating "yes/support" or "no/do not support".=C2=A0 If indicating no, please state your reservations with the= document.=C2=A0 If yes, please also feel free to provide comments you'd l= ike to see addressed once the document is a WG document. This poll ends on February 8. Thank you! Joel Jaeggli and IETF NETMOD Co-Chairs --------------5A0E23C9045183DC47AA4F61 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

This is the start of a *two* week poll on making draft-rtgyangdt-netmod-module-tags-02 a working group document.  

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or "no/do not support".  If indicating no, please state your reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-Chairs

--------------5A0E23C9045183DC47AA4F61-- From nobody Tue Feb 6 15:57:43 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D9A1912E877 for ; Tue, 6 Feb 2018 15:57:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.908 X-Spam-Level: X-Spam-Status: No, score=-6.908 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9PXqz0FtqHed for ; Tue, 6 Feb 2018 15:57:39 -0800 (PST) Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 562B612E05C for ; Tue, 6 Feb 2018 15:57:09 -0800 (PST) Received: from MBP.local ([IPv6:2620:11a:c081:20:384b:fe8:2d52:19df]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w16Nv89e056171 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Tue, 6 Feb 2018 23:57:08 GMT (envelope-from joelja@bogus.com) X-Authentication-Warning: nagasaki.bogus.com: Host [IPv6:2620:11a:c081:20:384b:fe8:2d52:19df] claimed to be MBP.local To: netmod@ietf.org References: From: joel jaeggli Message-ID: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com> Date: Tue, 6 Feb 2018 15:57:01 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------A853FAD9587DC7762C16F7A5" Content-Language: en-US Archived-At: Subject: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 06 Feb 2018 23:57:41 -0000 This is a multi-part message in MIME format. --------------A853FAD9587DC7762C16F7A5 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Sorry, Feb 20th is the end date for the adoption call. regards joel On 2/6/18 3:47 PM, joel jaeggli wrote: > > Hi, > > This is the start of a *two* week poll on making > draft-rtgyangdt-netmod-module-tags-02 a working group document.   > > https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 > > This document was most recently discussed at IETF 100. > > Please send email to the list indicating "yes/support" or "no/do not > support".  If indicating no, please state your reservations with the > document.  If yes, please also feel free to provide comments you'd > like to see addressed once the document is a WG document. > > This poll ends on February 8. > > Thank you! > > Joel Jaeggli and IETF NETMOD Co-Chairs > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------A853FAD9587DC7762C16F7A5 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Sorry, Feb 20th is the end date for the adoption call.

regards

joel


On 2/6/18 3:47 PM, joel jaeggli wrote:

Hi,

This is the start of a *two* week poll on making draft-rtgyangdt-netmod-module-tags-02 a working group document.  

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or "no/do not support".  If indicating no, please state your reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-Chairs



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

--------------A853FAD9587DC7762C16F7A5-- From nobody Tue Feb 6 16:01:44 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF456124BAC for ; Tue, 6 Feb 2018 16:01:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.697 X-Spam-Level: X-Spam-Status: No, score=-2.697 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SGtxmRv2NgSq for ; Tue, 6 Feb 2018 16:01:40 -0800 (PST) Received: from mail-yw0-x22d.google.com (mail-yw0-x22d.google.com [IPv6:2607:f8b0:4002:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07526127871 for ; Tue, 6 Feb 2018 16:01:39 -0800 (PST) Received: by mail-yw0-x22d.google.com with SMTP id x62so2664461ywg.11 for ; Tue, 06 Feb 2018 16:01:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=user-agent:date:subject:from:to:message-id:thread-topic:references :in-reply-to:mime-version; bh=3KVlWCHURfF0EeN4SzOo0umQgW6u6RZv1fOFA3GJZqE=; b=lionTWXGirl+LKuZP5w3WsHBo1Wt/83iNy2xtSJSAPgRH2ADCwP1H84jQrwxSkDXNK A7RiNzPSGf4eDcvcygA5Z9bAm020+n9F6DLGH5nbj28zQJf/padSS4MFIv0SxM69FnAu OORHxgBT/IPzA8/qCgeMvvWtXICXpphLpUNNj+Vw9tqhluLLOEULaxMOkUSU3SPLZtv6 gyB6XdNFIgPjrTJ8it33wuFzNd6zbilYfGQDh83c+FwuGhysR/0VcoLtkP1fJNlztp53 E8+UVR9GrZkkeN4ntL9xZsMxPZvPXfGR5bo2Lk3Fvvtt2+qJicbr1T3W8bJzNVySsS4V w8Zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:user-agent:date:subject:from:to:message-id :thread-topic:references:in-reply-to:mime-version; bh=3KVlWCHURfF0EeN4SzOo0umQgW6u6RZv1fOFA3GJZqE=; b=Ye8oloYDOx28tvPssgZBGdS2DD16hBQhzzMXPuCk9DgKc8QW6fHkIxgRDm7C8b6dB8 rCgbVvOkPegN8UE1wCKDKkyUzEC2Wsca7hqxq0Pdd5HNSB+nufWeiNzs7r9Df43i6GZa Rlkc9ba5YCzAagOiXjB5cemYYnBwOgW9l+gQhiwquICi0cpuRyspsunv5H5Kr4WJDd4J TYwycheGfc/an0r4Ge4c1w6qil84ZBnlutpH5yGlKcFevkblbMcZK9JxO32ObCAIaelQ qOkNPZLKQV9HxmBWPAvFsa4YnY80L/7t1b9+ElFPVpPv1SNilA+8fCaOPnDGWATmLGe8 CbTg== X-Gm-Message-State: APf1xPDgsjfRB+wwjw5Xqt9TupFPyiPTnMnnCT0Zb9OfsfMjUo3ZTDKO XuV68C2P1AzTo5uryIcU/GTvWQ== X-Google-Smtp-Source: AH8x224211+p92mGv+AgFxq4J6BEMJTX9yXM5SEz2DINrQmsTEQrAPO8pZJHDsPWgC174hoS2LfdQQ== X-Received: by 10.129.161.130 with SMTP id y124mr2587234ywg.69.1517961698826; Tue, 06 Feb 2018 16:01:38 -0800 (PST) Received: from [135.227.239.108] ([66.201.62.254]) by smtp.gmail.com with ESMTPSA id x71sm74137ywd.92.2018.02.06.16.01.37 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 16:01:38 -0800 (PST) User-Agent: Microsoft-MacOutlook/10.9.0.180116 Date: Tue, 06 Feb 2018 16:01:36 -0800 From: Jeff Tantsura To: joel jaeggli , Message-ID: <21887B77-7F6A-4B12-9F53-E7B66285A9AB@gmail.com> Thread-Topic: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 References: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com> In-Reply-To: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com> Mime-version: 1.0 Content-type: multipart/alternative; boundary="B_3600777697_1820993565" Archived-At: Subject: Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 00:01:41 -0000 > This message is in MIME format. Since your mail reader does not understand this format, some or all of this message may not be legible. --B_3600777697_1820993565 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: 7bit Yes/support On 2/6/18 3:47 PM, joel jaeggli wrote: Hi, This is the start of a *two* week poll on making draft-rtgyangdt-netmod-module-tags-02 a working group document. https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 This document was most recently discussed at IETF 100. Please send email to the list indicating "yes/support" or "no/do not support". If indicating no, please state your reservations with the document. If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document. This poll ends on February 8. Thank you! Joel Jaeggli and IETF NETMOD Co-Chairs _______________________________________________ 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 --B_3600777697_1820993565 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Yes/support=

 

On 2/6/18 3:47 PM, joel jaeggli wrote:

Hi,

This is the start of a *two* week poll = on making draft-rtgyangdt-netmod-module-tags-02 a working group document.&nb= sp; 

https://tools.ietf.or= g/html/draft-rtgyangdt-netmod-module-tags-02=

This d= ocument was most recently discussed at IETF 100.

Please send email to the list indi= cating "yes/support" or "no/do not support".  If in= dicating no, please state your reservations with the document.  If yes,= please also feel free to provide comments you'd like to see addressed once = the document is a WG document.

This poll ends on February 8.
Thank you!

Joel Jaeggli and IETF NETMOD Co-Chairs




______________=
_________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.or=
g/mailman/listinfo/netmod<=
/pre>

_______________________________________________ netmod mailing lis=
t netmod@ietf.org https://www.ietf.org/mailman/listinfo/netmod <=
/o:p>
--B_3600777697_1820993565-- From nobody Tue Feb 6 16:26:21 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FC912DA1A for ; Tue, 6 Feb 2018 16:26:19 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9zaAVgIUebOt for ; Tue, 6 Feb 2018 16:26:17 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 69D83126DFB for ; Tue, 6 Feb 2018 16:26:17 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id v188so5307513lfa.11 for ; Tue, 06 Feb 2018 16:26:17 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=8PWg88Ba0+/Coe+72h28C0ln892TuQ0oEiqHb1Cxp8M=; b=FaxSkhRwwl/gxCLSbajLndmYpYwDULD4BfRy8t2ElZxeMPe2JS3i+1PkYx9FsmHPrX mptynA9Rlapt+MtXomSo4UUfXir5qmf8ONPj6zh77xB5+uRIdMq1b8wOr4tCs81rYfrl Joi0+5knUjch7Q0v9/GEcpFGZXar4wYpKgOCyjShat1xJtj71UdEUTcZ1ylf3M9oO9l3 /r4ad3LCB5TpHXGJnHFXDCS7LGyqNAQH5bg2qbt+HwZUXTH8UAKLkQ+YLr+iOky8cOqz 1Li1ukAr9Agx7OfyVE3h/VDBphB1qyLRd0O/nGg6CAbWVlKoWzwZdQ1i6Jiex/O39c4u iXfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=8PWg88Ba0+/Coe+72h28C0ln892TuQ0oEiqHb1Cxp8M=; b=Y/Wrxvi7bmcLJlGOZOT5v285Srs4otF/IYvAadmGhoRy1roGUJiT1PTye+CN2cpRXr xTQyJf5AQNdInDAqCNfVIke2pbtC6OVqq5DHx7pT7ITZSGb6GTa2UG99hH2xPAelv2x2 1D8g6RaZttFiRmvBFJK2TOOEO2oEljJPRX/AL8FhiViX9y7gvOKJyU3v4NoQKLC9wj5r OzW0LEZHzEWQgopaaZRd8DcsPEsO2KETHGd03rtkVgv/1T3SRpYv4cn77OBDHDir/zXy 4MvaE5X9dNFPZEQqkOgoioFDPQpAfvORNx35fzJZrtdfn3ZguoyqgQDaeZmyx38jtpsK gQ+Q== X-Gm-Message-State: APf1xPAUbY80UnocOe8SWaOYrrDrHpU7OZ6AVAnl8cI21BKuOfpbtzYm IuXf6doYGiO5CGFrnuTA6LSAWXuFtptn7wdkhvIxAg== X-Google-Smtp-Source: AH8x226S9f/VD8ptqTuZfh9HDkCY1nedc0JLcu0YbQgKjgYlzLDnJPko7IkO1X1Ewvb7Oo5GhSULJJN3Zmac62sZz4k= X-Received: by 10.46.21.6 with SMTP id s6mr2992901ljd.106.1517963175575; Tue, 06 Feb 2018 16:26:15 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.143.6 with HTTP; Tue, 6 Feb 2018 16:26:14 -0800 (PST) In-Reply-To: References: From: Andy Bierman Date: Tue, 6 Feb 2018 16:26:14 -0800 Message-ID: To: joel jaeggli Cc: NETMOD Working Group Content-Type: multipart/alternative; boundary="f403045f72f4dcda6b05649457da" Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 00:26:20 -0000 --f403045f72f4dcda6b05649457da Content-Type: text/plain; charset="UTF-8" Hi, support starting this work. The draft avoids discussion of any useful operations based on tags. Setting and clearing tags is fine, but what about ? What about NACM rules based on tags? If protocol operations using tags are out of scope, then the draft should say that. (And don't forget NMDA compliance ;-) Andy On Tue, Feb 6, 2018 at 3:47 PM, joel jaeggli wrote: > Hi, > > This is the start of a **two** week poll on making > draft-rtgyangdt-netmod-module-tags-02 a working group document. > > https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 > > This document was most recently discussed at IETF 100. > > Please send email to the list indicating "yes/support" or "no/do not > support". If indicating no, please state your reservations with the > document. If yes, please also feel free to provide comments you'd like to > see addressed once the document is a WG document. > > This poll ends on February 8. > > Thank you! > > Joel Jaeggli and IETF NETMOD Co-Chairs > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > > --f403045f72f4dcda6b05649457da Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

support starting this work.
The draft avoids discussion of any useful operations based on tags.
Setting and clearing tags is fine, but what about <get-data>?
What about NACM rules based on tags?
If protocol operati= ons using tags are out of scope, then the draft should say that.
=
(And don't forget NMDA compliance ;-)


Andy


On Tue, Feb 6, 2018 at 3:47 PM, joel ja= eggli <joelja@bogus.com> wrote:
=20 =20 =20

Hi,

This is the start of a *two* week poll on making draft-rtgyangdt-netmod-module-tags-02 a working group document.= =C2=A0=C2=A0

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-t= ags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or = "no/do not support".=C2=A0 If indicating no, please state your reservat= ions with the document.=C2=A0 If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-Chairs


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

--f403045f72f4dcda6b05649457da-- From nobody Tue Feb 6 16:27:06 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E4B1912DA1A for ; Tue, 6 Feb 2018 16:27:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.12 X-Spam-Level: X-Spam-Status: No, score=-1.12 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eetPEefn1lf7 for ; Tue, 6 Feb 2018 16:27:03 -0800 (PST) Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6288F126DFB for ; Tue, 6 Feb 2018 16:27:03 -0800 (PST) Received: from [::1] (port=40532) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1ejDZm-0002sI-P6; Wed, 07 Feb 2018 03:27:02 +0300 To: joel jaeggli , netmod@ietf.org References: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com> From: Lou Berger Message-ID: Date: Tue, 6 Feb 2018 19:27:01 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-AntiAbuse: This header was added to track abuse, please include it with any abuse report X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz X-AntiAbuse: Original Domain - ietf.org X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12] X-AntiAbuse: Sender Address Domain - labn.net X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com X-Source: X-Source-Args: X-Source-Dir: Archived-At: Subject: Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 00:27:05 -0000 yes/support no, I don't know of any IPR that applies to this document... Lou (as co-author) On 2/6/2018 6:57 PM, joel jaeggli wrote: > > Sorry, Feb 20th is the end date for the adoption call. > > regards > > joel > > > On 2/6/18 3:47 PM, joel jaeggli wrote: >> >> Hi, >> >> This is the start of a *two* week poll on making >> draft-rtgyangdt-netmod-module-tags-02 a working group document. >> >> https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 >> >> This document was most recently discussed at IETF 100. >> >> Please send email to the list indicating "yes/support" or "no/do not >> support".  If indicating no, please state your reservations with the >> document.  If yes, please also feel free to provide comments you'd >> like to see addressed once the document is a WG document. >> >> This poll ends on February 8. >> >> Thank you! >> >> Joel Jaeggli and IETF NETMOD Co-Chairs >> >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Tue Feb 6 16:31:44 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3028212DA1A for ; Tue, 6 Feb 2018 16:31:43 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rR3kUQiEC9pA for ; Tue, 6 Feb 2018 16:31:41 -0800 (PST) Received: from mail-pf0-x22e.google.com (mail-pf0-x22e.google.com [IPv6:2607:f8b0:400e:c00::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3FCAF12711A for ; Tue, 6 Feb 2018 16:31:41 -0800 (PST) Received: by mail-pf0-x22e.google.com with SMTP id b25so1394494pfd.9 for ; Tue, 06 Feb 2018 16:31:41 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-transfer-encoding:content-language; bh=zsNIRhZqn23JI0AIhwTEM7HxHpRFbVb6m4QQS98u8Cs=; b=ryONXDXVG6in/iz/24SJhHrqA/eSjgdHzDWsGaxPSX9a+iGuf5ZoijxeNvi2A7uRzS OIIFtcKQB3WCDtkNEuKJr+r+fvAwWwFBYTpdIz/dVAgoK2aIVd/QD3TR/udJtlfstwl1 6ylOjY230C0FmpZRX9Mx6MCmrsVq8h7GdoCPl90oJ97ikVsjUN7zeZfbLWyq9L1QDtfG kcAqgQx29kFpOtDslGQWcQt8fjZjYl9X7XiYAkNo1Qfgz6sSrgc56aAGqPcG/DCvGcQt 8gV7bgMqw2IsrgQ/zkFoBSIod74UDDM1JaHZrGOj7BASyufJ8FhULp3MI4ZDRzOxRPdx gGxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-transfer-encoding:content-language; bh=zsNIRhZqn23JI0AIhwTEM7HxHpRFbVb6m4QQS98u8Cs=; b=DDiDoowuu9PFidPfuLNeNlB+qTwT62vuS524jUgOdFMk+6LGfNIgHgwEuEfBA6Bn5r AatEe7sPQsh+/PyFyl2lyHYLrhscinni69DsFtFf4H+VnHxYoF+bUTUIQMzXorQU6qZ4 2eutkq9H8OpQmp3Cn3uaBh37+8kU8bmifFpuLux826aQSiGQFbkpdQzsgZmFYwC2Gdmp JBUjOTfUDLwH+fpb1RTEMvJCtsGlkTRWLCueW83/hklSLPcQefUxlxcaK+GD/ymlNVK3 ePWHiwtXLlMmBkRXR8bCtUPcJ+e8hPfLYSgomFzUQ7byZgxKkZ0q5QDdW2gOQcldOUxw +32w== X-Gm-Message-State: APf1xPAsGvqqREnHvgcl4R81vW2hzh4ZDzIxKYRRgUmyB0L81O0F+eFr WpT/xLR5Ze/8knZkGZqKOiQgbWKx X-Google-Smtp-Source: AH8x226+d5HC2pofesVHsQmsgvRHdw1SDsSTr56Ld4T+IjrUEAPq4wQ4Td9dw12dH3CGwYSuJNJlxg== X-Received: by 10.99.147.70 with SMTP id w6mr3481024pgm.410.1517963500244; Tue, 06 Feb 2018 16:31:40 -0800 (PST) Received: from MBP.local ([2620:11a:c081:20:384b:fe8:2d52:19df]) by smtp.gmail.com with ESMTPSA id h64sm379444pfh.28.2018.02.06.16.31.39 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 16:31:39 -0800 (PST) To: NETMOD Working Group From: joel jaeggli Message-ID: <84973474-c804-4b44-86c9-80443b6550d2@gmail.com> Date: Tue, 6 Feb 2018 16:31:38 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: [netmod] IPR call draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 00:31:43 -0000 If any authors or participants are aware of IPR covering the proposed working-group item: draft-rtgyangdt-netmod-module-tags-02 https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 Now would be a good time to declare it. Thanks joel From nobody Tue Feb 6 16:38:40 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E099212711A for ; Tue, 6 Feb 2018 16:38:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MEyTc5O92_je for ; Tue, 6 Feb 2018 16:38:37 -0800 (PST) Received: from mail-yw0-x231.google.com (mail-yw0-x231.google.com [IPv6:2607:f8b0:4002:c05::231]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D8970126DFB for ; Tue, 6 Feb 2018 16:38:36 -0800 (PST) Received: by mail-yw0-x231.google.com with SMTP id q6so2731408ywg.3 for ; Tue, 06 Feb 2018 16:38:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QoFBX9xsya3YL5LuAaAj4uqEELkxFOCuiuRMJw+tTng=; b=J2yxkcBBOAeAHvAB8oZdl93UCotrVMwgRfcshX6dUFy6rGVv5St6YStEp6/TrFFm5Q p50JVjizRNHp1LH8hkTBwi85LLPkwFWFMiOzO6tET6NxDHBUEF++c9W8ua6BVsWcPXsZ 0TJi59zry+T/wvr3Ib4q+IBAMxUrU773Q1fbMtO0Ypvw4LwCv+WwnhXi5VyloHPkBCnp grKCN5iZLh+uzOxe5O8BNWQp6LaOgxM+LniBXc0OTET97NrLV04SUJPVgvz+7jjmeRfG SYZZYMtG1X3RZLMi/Y3YYbJYe0iKtTLz9th/GyUCcViwFb86KMAgrkWkq4GfZMoxEe7m M+dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=QoFBX9xsya3YL5LuAaAj4uqEELkxFOCuiuRMJw+tTng=; b=RwrSN+swneoBvIav81VM2SYfuuNoNstoDLTcDOZ5aOBKUNWKS2brpwQXzYzKBEglgo n6YgLWr7vWu/4dF+YjyqrztOaN3oAHNKO6zCrDlNgA6Sq5H7HVczThcKoxS4koF0CrAm uuA66jEByjhZAHsX4wfSy1ZprxSXkewMeFh9N/zmBWsvDtVofXyhcXOxv0dvWVW+0ang XUdNNFV9N3CiFyMV+Rqo2w0m+9YLmHEzMnOQJOEhXzKWJ3XzHxeLAarEa0cfjcKl1btx LbnsVvOMXFzBvqe4L4HpliisNQpYhlgMPhLQS1ahCCypf/2Z7LOJKQpXZrCmnHP7GQBB 98yA== X-Gm-Message-State: APf1xPCeQ2mcUOtvl5FVF2zWbdlxJWcKhBzuFPGWcvgbcWDYe8/8lK8k wwGicThJSp+tQn7ACnNCG9c3utFn X-Google-Smtp-Source: AH8x2257eQaSBoxJ959DbiRzuPqc9mm2nY6dsxiT75zaOCcRCQ84PmXFCNZAHonT7zHC6rcEPXzMkA== X-Received: by 10.37.185.140 with SMTP id r12mr2770976ybg.283.1517963915583; Tue, 06 Feb 2018 16:38:35 -0800 (PST) Received: from ?IPv6:2607:fb90:7d73:37ca:10a1:9888:72b2:8a99? ([2607:fb90:7d73:37ca:10a1:9888:72b2:8a99]) by smtp.gmail.com with ESMTPSA id e140sm105363ywa.77.2018.02.06.16.38.34 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 06 Feb 2018 16:38:35 -0800 (PST) Content-Type: multipart/alternative; boundary=Apple-Mail-D5512288-612F-4C8F-9E3C-78A6EC306024 Mime-Version: 1.0 (1.0) From: Dean Bogdanovic X-Mailer: iPhone Mail (15D60) In-Reply-To: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com> Date: Tue, 6 Feb 2018 19:38:34 -0500 Cc: netmod@ietf.org Content-Transfer-Encoding: 7bit Message-Id: <33D58F71-586C-494B-ABE8-CEB3FA4B1FCE@gmail.com> References: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com> To: joel jaeggli Archived-At: Subject: Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 00:38:39 -0000 --Apple-Mail-D5512288-612F-4C8F-9E3C-78A6EC306024 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable yes/support no, I'm not aware of any IPR that applies to this document... Dean > On Feb 6, 2018, at 18:57, joel jaeggli wrote: >=20 > Sorry, Feb 20th is the end date for the adoption call. >=20 > regards >=20 > joel >=20 >> On 2/6/18 3:47 PM, joel jaeggli wrote: >> Hi,=20 >>=20 >> This is the start of a *two* week poll on making draft-rtgyangdt-netmod-m= odule-tags-02 a working group document. =20 >>=20 >> https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 >> This document was most recently discussed at IETF 100. >>=20 >> Please send email to the list indicating "yes/support" or "no/do not supp= ort". If indicating no, please state your reservations with the document. I= f yes, please also feel free to provide comments you'd like to see addressed= once the document is a WG document.=20 >>=20 >> This poll ends on February 8.=20 >>=20 >> Thank you!=20 >> Joel Jaeggli and IETF NETMOD Co-Chairs >>=20 >>=20 >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --Apple-Mail-D5512288-612F-4C8F-9E3C-78A6EC306024 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 7bit

yes/support

no, I'm not aware of any IPR that applies to this document...

Dean
On Feb 6, 2018, at 18:57, joel jaeggli <joelja@bogus.com> wrote:

Sorry, Feb 20th is the end date for the adoption call.

regards

joel


On 2/6/18 3:47 PM, joel jaeggli wrote:

Hi,

This is the start of a *two* week poll on making draft-rtgyangdt-netmod-module-tags-02 a working group document.  

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or "no/do not support".  If indicating no, please state your reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-Chairs



_______________________________________________
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
--Apple-Mail-D5512288-612F-4C8F-9E3C-78A6EC306024-- From nobody Tue Feb 6 16:43:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A9A412711A for ; Tue, 6 Feb 2018 16:43:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.529 X-Spam-Level: X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFKWO0--jnZv for ; Tue, 6 Feb 2018 16:42:59 -0800 (PST) Received: from alln-iport-3.cisco.com (alln-iport-3.cisco.com [173.37.142.90]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ABC90126DFB for ; Tue, 6 Feb 2018 16:42:59 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10552; q=dns/txt; s=iport; t=1517964179; x=1519173779; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Abc8H72avPDBYpFPA9xEOXASkK+H3vYxHRqUv8UqD6w=; b=knF+U86EHX+6at4x+s3abLLYhV9ya87wJSqRLPS2dpJJdXiLnNp1/35N ivU7mMyfvtmHZRN6KjHa+mg/GP6rr1s9OHdFrlDXJNKRz00oUeqmrfMXh I41k5BUl5myKzB24F0X3/BPZ1wVhulMwN7akWkTQzl5o+7Hmkaf/i+uVP Q=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DIAAA6Snpa/4wNJK1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJZeGZwKAqDW4okjjGBWyeRc4VVFYIDChgBCoRJTwIagkJUGAE?= =?us-ascii?q?BAQEBAQEBAmsohSMBAQEEAQEhSxsCAQgRAwECJAQDAgICJQsUCQgCBAESiVFkE?= =?us-ascii?q?LNrgieIeIIKAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWEaoIVg2gMgnmBSYFmAQE?= =?us-ascii?q?CAYE7ARIBPxaCYTGCNAWLcY4yigsCiBiNWoIehieLd41xiWICERkBgTsBHzklO?= =?us-ascii?q?3BwFT0qAYIbCYJYKYFteItLgSWBFwEBAQ?= X-IronPort-AV: E=Sophos; i="5.46,471,1511827200"; d="scan'208,217"; a="67417651" Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2018 00:42:58 +0000 Received: from XCH-RTP-012.cisco.com (xch-rtp-012.cisco.com [64.101.220.152]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w170gwhN025306 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Feb 2018 00:42:58 GMT Received: from xch-rtp-015.cisco.com (64.101.220.155) by XCH-RTP-012.cisco.com (64.101.220.152) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 6 Feb 2018 19:42:57 -0500 Received: from xch-rtp-015.cisco.com ([64.101.220.155]) by XCH-RTP-015.cisco.com ([64.101.220.155]) with mapi id 15.00.1320.000; Tue, 6 Feb 2018 19:42:57 -0500 From: "Acee Lindem (acee)" To: joel jaeggli , "netmod@ietf.org" Thread-Topic: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 Thread-Index: AQHTn6ZUrtbTDXotsUKKSfQKeLrWyqOYGeCA Date: Wed, 7 Feb 2018 00:42:57 +0000 Message-ID: <03C60C5F-C0EE-4463-B95C-8E475BBA0452@cisco.com> References: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com> In-Reply-To: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.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.195] Content-Type: multipart/alternative; boundary="_000_03C60C5FC0EE4463B95C8E475BBA0452ciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 00:43:01 -0000 --_000_03C60C5FC0EE4463B95C8E475BBA0452ciscocom_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSBzdXBwb3J0IG5ldG1vZCBXRyBhZG9wdGlvbi4NClRoYW5rcywNCkFjZWUNCg0KRnJvbTogbmV0 bW9kIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGpvZWwgamFlZ2dsaSA8 am9lbGphQGJvZ3VzLmNvbT4NCkRhdGU6IFR1ZXNkYXksIEZlYnJ1YXJ5IDYsIDIwMTggYXQgNjo1 OCBQTQ0KVG86ICJuZXRtb2RAaWV0Zi5vcmciIDxuZXRtb2RAaWV0Zi5vcmc+DQpTdWJqZWN0OiBb bmV0bW9kXSBDb3JyZWN0aW9uLCBkYXRlIEl0IGVuZHMgRmViIDIwdGggUmU6IEFkb3B0aW9uIFBv bGw6IGRyYWZ0LXJ0Z3lhbmdkdC1uZXRtb2QtbW9kdWxlLXRhZ3MtMDINCg0KDQpTb3JyeSwgRmVi IDIwdGggaXMgdGhlIGVuZCBkYXRlIGZvciB0aGUgYWRvcHRpb24gY2FsbC4NCg0KcmVnYXJkcw0K DQpqb2VsDQoNCk9uIDIvNi8xOCAzOjQ3IFBNLCBqb2VsIGphZWdnbGkgd3JvdGU6DQoNCkhpLA0K DQpUaGlzIGlzIHRoZSBzdGFydCBvZiBhICp0d28qIHdlZWsgcG9sbCBvbiBtYWtpbmcgZHJhZnQt cnRneWFuZ2R0LW5ldG1vZC1tb2R1bGUtdGFncy0wMiBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQu DQoNCmh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1ydGd5YW5nZHQtbmV0bW9kLW1v ZHVsZS10YWdzLTAyDQoNClRoaXMgZG9jdW1lbnQgd2FzIG1vc3QgcmVjZW50bHkgZGlzY3Vzc2Vk IGF0IElFVEYgMTAwLg0KDQpQbGVhc2Ugc2VuZCBlbWFpbCB0byB0aGUgbGlzdCBpbmRpY2F0aW5n ICJ5ZXMvc3VwcG9ydCIgb3IgIm5vL2RvIG5vdCBzdXBwb3J0Ii4gIElmIGluZGljYXRpbmcgbm8s IHBsZWFzZSBzdGF0ZSB5b3VyIHJlc2VydmF0aW9ucyB3aXRoIHRoZSBkb2N1bWVudC4gIElmIHll cywgcGxlYXNlIGFsc28gZmVlbCBmcmVlIHRvIHByb3ZpZGUgY29tbWVudHMgeW91J2QgbGlrZSB0 byBzZWUgYWRkcmVzc2VkIG9uY2UgdGhlIGRvY3VtZW50IGlzIGEgV0cgZG9jdW1lbnQuDQoNClRo aXMgcG9sbCBlbmRzIG9uIEZlYnJ1YXJ5IDguDQoNClRoYW5rIHlvdSENCg0KSm9lbCBKYWVnZ2xp IGFuZCBJRVRGIE5FVE1PRCBDby1DaGFpcnMNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX18NCg0KbmV0bW9kIG1haWxpbmcgbGlzdA0KDQpuZXRt b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCg0KaHR0cHM6Ly93d3cuaWV0Zi5v cmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCg0KDQo= --_000_03C60C5FC0EE4463B95C8E475BBA0452ciscocom_ Content-Type: text/html; charset="utf-8" Content-ID: <44F28B9945ED844DA6E9E271D8F96EA4@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQtZmFtaWx5OkNvbnNvbGFz Ow0KCXBhbm9zZS0xOjIgMTEgNiA5IDIgMiA0IDMgMiA0O30NCi8qIFN0eWxlIERlZmluaXRpb25z ICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9ybWFsDQoJe21hcmdpbjow aW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1m YW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFuLk1zb0h5cGVybGluaw0K CXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0ZXh0LWRlY29yYXRpb246 dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtGb2xsb3dlZA0KCXttc28t c3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRl cmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tc3R5bGUtbGluazoi SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4w MDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30N CnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1hbDANCgl7bXNvLXN0eWxl LW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRvOw0KCW1hcmdpbi1yaWdo dDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFyZ2luLWxlZnQ6MGluOw0K CWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0K c3Bhbi5tb3otdHh0LXRhZw0KCXttc28tc3R5bGUtbmFtZTptb3otdHh0LXRhZzt9DQpzcGFuLkhU TUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBD aGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJl Zm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb25zb2xhczt9DQpzcGFuLkVtYWlsU3R5bGUyMg0K CXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIs c2Fucy1zZXJpZjsNCgljb2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1z dHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7fQ0KQHBhZ2UgV29yZFNl Y3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBpbiAxLjBpbiAxLjBpbiAx LjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5 bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBs ZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSBz dXBwb3J0IG5ldG1vZCBXRyBhZG9wdGlvbi4gPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIj5UaGFua3MsPGJyPg0KQWNlZTxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItdG9wOnNvbGlkICNCNUM0REYgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PGI+PHNwYW4gc3R5 bGU9ImZvbnQtc2l6ZToxMi4wcHQ7Y29sb3I6YmxhY2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFu IHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5uZXRtb2QgJmx0O25ldG1vZC1i b3VuY2VzQGlldGYub3JnJmd0OyBvbiBiZWhhbGYgb2Ygam9lbCBqYWVnZ2xpICZsdDtqb2VsamFA Ym9ndXMuY29tJmd0Ozxicj4NCjxiPkRhdGU6IDwvYj5UdWVzZGF5LCBGZWJydWFyeSA2LCAyMDE4 IGF0IDY6NTggUE08YnI+DQo8Yj5UbzogPC9iPiZxdW90O25ldG1vZEBpZXRmLm9yZyZxdW90OyAm bHQ7bmV0bW9kQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwvYj5bbmV0bW9kXSBDb3Jy ZWN0aW9uLCBkYXRlIEl0IGVuZHMgRmViIDIwdGggUmU6IEFkb3B0aW9uIFBvbGw6IGRyYWZ0LXJ0 Z3lhbmdkdC1uZXRtb2QtbW9kdWxlLXRhZ3MtMDI8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+ PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48YSBuYW1lPSJfTWFpbE9yaWdpbmFsQm9keSI+U29ycnksIEZlYiAyMHRoIGlzIHRoZSBlbmQg ZGF0ZSBmb3IgdGhlIGFkb3B0aW9uIGNhbGwuPG86cD48L286cD48L2E+PC9wPg0KPHAgc3R5bGU9 Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPnJlZ2FyZHM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxl ZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+am9l bDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01h aWxPcmlnaW5hbEJvZHkiPk9uIDIvNi8xOCAzOjQ3IFBNLCBqb2VsIGphZWdnbGkgd3JvdGU6PG86 cD48L286cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIHN0eWxlPSJtYXJnaW4tbGVmdDouNWlu Ij48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5IaSwgPGJyPg0K PGJyPg0KVGhpcyBpcyB0aGUgc3RhcnQgb2YgYSA8c3BhbiBjbGFzcz0ibW96LXR4dC10YWciPjxi Pio8L2I+PC9zcGFuPjxiPnR3bzxzcGFuIGNsYXNzPSJtb3otdHh0LXRhZyI+Kjwvc3Bhbj48L2I+ IHdlZWsgcG9sbCBvbiBtYWtpbmcgZHJhZnQtcnRneWFuZ2R0LW5ldG1vZC1tb2R1bGUtdGFncy0w MiBhIHdvcmtpbmcgZ3JvdXAgZG9jdW1lbnQuJm5ic3A7Jm5ic3A7PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21h cms6X01haWxPcmlnaW5hbEJvZHkiPjwvc3Bhbj48YSBocmVmPSJodHRwczovL3Rvb2xzLmlldGYu b3JnL2h0bWwvZHJhZnQtcnRneWFuZ2R0LW5ldG1vZC1tb2R1bGUtdGFncy0wMiI+PHNwYW4gc3R5 bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+aHR0cHM6Ly90b29scy5pZXRmLm9y Zy9odG1sL2RyYWZ0LXJ0Z3lhbmdkdC1uZXRtb2QtbW9kdWxlLXRhZ3MtMDI8L3NwYW4+PHNwYW4g c3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjwvYT48c3BhbiBz dHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48bzpwPjwvbzpwPjwvc3Bhbj48 L3A+DQo8cCBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+VGhpcyBkb2N1bWVudCB3YXMgbW9zdCByZWNlbnRseSBkaXNj dXNzZWQgYXQgSUVURiAxMDAuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgc3R5bGU9Im1hcmdp bi1sZWZ0Oi41aW4iPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHki PlBsZWFzZSBzZW5kIGVtYWlsIHRvIHRoZSBsaXN0IGluZGljYXRpbmcgJnF1b3Q7eWVzL3N1cHBv cnQmcXVvdDsgb3IgJnF1b3Q7bm8vZG8gbm90IHN1cHBvcnQmcXVvdDsuJm5ic3A7IElmIGluZGlj YXRpbmcgbm8sIHBsZWFzZSBzdGF0ZSB5b3VyIHJlc2VydmF0aW9ucyB3aXRoIHRoZSBkb2N1bWVu dC4mbmJzcDsgSWYgeWVzLCBwbGVhc2UgYWxzbyBmZWVsIGZyZWUgdG8gcHJvdmlkZQ0KIGNvbW1l bnRzIHlvdSdkIGxpa2UgdG8gc2VlIGFkZHJlc3NlZCBvbmNlIHRoZSBkb2N1bWVudCBpcyBhIFdH IGRvY3VtZW50LiA8YnI+DQo8YnI+DQpUaGlzIHBvbGwgZW5kcyBvbiBGZWJydWFyeSA4LiA8YnI+ DQo8YnI+DQpUaGFuayB5b3UhIDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIHN0eWxlPSJtYXJn aW4tbGVmdDouNWluIj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5 Ij5Kb2VsIEphZWdnbGkgYW5kIElFVEYgTkVUTU9EIENvLUNoYWlyczxvOnA+PC9vOnA+PC9zcGFu PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48c3Bh biBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48YnI+DQo8YnI+DQo8YnI+ DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cHJlIHN0eWxlPSJtYXJnaW4tbGVmdDouNWluIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxvOnA+PC9vOnA+PC9zcGFuPjwvcHJl Pg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFy azpfTWFpbE9yaWdpbmFsQm9keSI+bmV0bW9kIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFu PjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1i b29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFuPjxhIGhyZWY9Im1haWx0bzpuZXRtb2RA aWV0Zi5vcmciPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPm5l dG1vZEBpZXRmLm9yZzwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2lu YWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5h bEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPHByZSBzdHlsZT0ibWFyZ2luLWxlZnQ6 LjVpbiI+PHNwYW4gc3R5bGU9Im1zby1ib29rbWFyazpfTWFpbE9yaWdpbmFsQm9keSI+PC9zcGFu PjxhIGhyZWY9Imh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIj48 c3BhbiBzdHlsZT0ibXNvLWJvb2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDwvc3Bhbj48c3BhbiBzdHlsZT0ibXNvLWJv b2ttYXJrOl9NYWlsT3JpZ2luYWxCb2R5Ij48L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJtc28tYm9v a21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxvOnA+PC9vOnA+PC9zcGFuPjwvcHJlPg0KPC9ibG9j a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1sZWZ0Oi41aW4iPjxz cGFuIHN0eWxlPSJtc28tYm9va21hcms6X01haWxPcmlnaW5hbEJvZHkiPjxicj4NCjxicj4NCjwv c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K --_000_03C60C5FC0EE4463B95C8E475BBA0452ciscocom_-- From nobody Tue Feb 6 16:49:57 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E0D9C126DFB for ; Tue, 6 Feb 2018 16:49:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.7 X-Spam-Level: X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cj81xQCTMbzx for ; Tue, 6 Feb 2018 16:49:53 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 4B914128896 for ; Tue, 6 Feb 2018 16:49:53 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w170mt63002266; Tue, 6 Feb 2018 16:49:52 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=ANHH63/ddF3R1JU2rgzI2Atj77o8La4tYvBYFH+4eE0=; b=NO2daI6SdpzHj/tXCTTY0xGdJ3hHIM0oFCc88eB5MF3Cjy3Q+mfZnukjDSblLQY8jxZJ NnDeJOqFoNcFXdSUSiM1h1b8Ur+ahTlCQEfoQUu1r65VKwPrK0Cj9HD0D05+qmydYOWo mQca1rjNuTzZMGkjpBrI/fIMqIomPc7nPm4dgR4PFAZBSgtn9Z07fvR9f9GTPAgXHiXP myvZpiSlgqueAdwjsVR74VJIV+whSworZZ5M+l5V/xmSL8/mSyZCWwxwxKzr+nsfBlkQ u8LO/rsaLzYSOjLbJIdJ92H/3IWJg4YPLl92ZdScNBTjr333EPRRwu3s3MVkOk7tP5li +g== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0017.outbound.protection.outlook.com [216.32.181.17]) by mx0a-00273201.pphosted.com with ESMTP id 2fyn3y86q0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 06 Feb 2018 16:49:52 -0800 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3323.namprd05.prod.outlook.com (10.174.191.38) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Wed, 7 Feb 2018 00:49:50 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0485.009; Wed, 7 Feb 2018 00:49:50 +0000 From: Kent Watsen To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt Thread-Index: AQHTi/jgm64n1kE5c0S5iq2VpQaBSqN2at0AgAznHmeAFJ1egA== Date: Wed, 7 Feb 2018 00:49:50 +0000 Message-ID: References: <151579789446.21777.985631371557420470@ietfa.amsl.com> <045f01d39534$c02ba480$4001a8c0@gateway.2wire.net> In-Reply-To: <045f01d39534$c02ba480$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3323; 7:HoRxHhNW5jsJgTetCLXcsHY7Sm59ybjTlIRlj/L1+v5XC3WhLRFBxxoeu0nbpwRVpaetoJLPWwBCvs+jHimwO20fp6xnoPDMxi/7kVWtrV/DeCS6KWLsIvorH4j7XdCSaXeolLjrpdhZgaEYXZZDbq5/FVJ7+w+zHEMUznH1PylvxBpPwLQRH45lIh9iNjzPMo6XYPj9MKofavxN5uR4dUbIfNLw96bbN5Nfa4b7AxJ4JUzTKeadvJYR9lkuvuip x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: f90d91c2-b66e-41e1-eea6-08d56dc4b19f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3323; x-ms-traffictypediagnostic: DM5PR05MB3323: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(209352067349851)(192374486261705)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR05MB3323; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3323; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39380400002)(39860400002)(366004)(346002)(376002)(51444003)(52314003)(13464003)(199004)(189003)(58126008)(966005)(68736007)(110136005)(105586002)(229853002)(6116002)(2906002)(316002)(2900100001)(14454004)(575784001)(478600001)(3846002)(2950100002)(33656002)(83506002)(99286004)(5660300001)(3280700002)(86362001)(8676002)(53936002)(2501003)(186003)(97736004)(25786009)(6506007)(6512007)(83716003)(3660700001)(6246003)(77096007)(6346003)(26005)(82746002)(81156014)(81166006)(102836004)(66066001)(7736002)(106356001)(8936002)(76176011)(305945005)(6436002)(36756003)(6486002)(6306002)(59450400001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3323; H:DM5PR05MB3484.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) x-microsoft-antispam-message-info: qcH38qAgmq+21/5sV4UxI0ihoEbIqZHi+2CLw2r0IG9imZTUZ2WwhScHQAQhrqvB7ociyxNRXqR/4VAWVRrGpg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <539C261BF424424AAF186F8A3F6850C9@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: f90d91c2-b66e-41e1-eea6-08d56dc4b19f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 00:49:50.3078 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3323 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-06_10:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070008 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 00:49:56 -0000 SGkgQ2x5ZGUsDQoNClRoZSBjaGFpcnMgd2VyZSBkaXNjdXNzaW5nIHRoZSBISVNUT1JJQyByZWZl cmVuY2UgdG8gUkZDIDY1ODcuICAgQXMgd2UgdW5kZXJzdGFuZCBpdCwgUkZDIDY1ODcgd2FzIGFj dHVhbGx5IG9yaWdpbmFsbHkgcHVibGlzaGVkIGFzIGEgSElTVE9SSUMgZG9jdW1lbnQgdG8gYWNj b21tb2RhdGUgU2VjdXJpdHkgYXJlYSBjb25jZXJucy4gIEFwcGFyZW50bHksIEJlbm9pdCB3YXMg QUQgYXQgdGhlIHRpbWUsIHNvIGhlIG1heSByZWNhbGwuICBUaGUgSUVURiB0b29rIHNwZWNpYWwg ZWZmb3J0IHRvIHB1Ymxpc2ggUkZDIDY1ODcgYW55d2F5LCBsaWtlbHkgZHVlIHRvIFRDUCBiZWlu ZyBpbiBjb21tb24gdXNlLiAgQW55d2F5LCB3ZSdyZSB3b25kZXJpbmcsIG11c3QgdGhpcyBkb2N1 bWVudCBoYXZlIGEgbm9ybWF0aXZlIHJlZmVyZW5jZSB0byBSRkMgNjU4Nz8gIC0gY291bGQgaXQg YmUgbWFkZSBJbmZvcm1hdGlvbmFsIGluc3RlYWQ/ICBJcyB1bmRlcnN0YW5kaW5nIFJGQyA2NTg3 IG5lY2Vzc2FyeSB0byBpbXBsZW1lbnQgdGhlIHN5c2xvZyBkcmFmdD8NCg0KV2UgYWxzbyBkaXNj dXNzZWQgdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIHRvIHRoZSBrZXlzdG9yZS1hbmQtZnJpZW5k cyBkcmFmdHMuICAgQXMgaXQgc3RhbmRzLCBteSBzaGVwaGVyZCB3cml0ZS11cCBpcyBnb2luZyB0 byBoYXZlIHRvIGNhbGwgdGhlc2Ugb3V0IGFzIHVuc3RhYmxlIGRlcGVuZGVuY2llcy4gICBJIGtu b3cgdGhhdCBpdCB3YXMgZGlzY3Vzc2VkIGJlZm9yZSwgYnV0IHdvdWxkIHlvdSBoYXZlIGFueSBh cHBldGl0ZSB0byByZXZpc2l0IGhhdmluZyBUTFMgaW4gdGhlIGZpcnN0IHZlcnNpb24gb2YgdGhp cyBtb2R1bGU/ICBQZXJoYXBzIGl0IGNvdWxkIGJlIHBpY2tlZCBpdCB1cCBpbiBhIGJpcz8NCg0K V2hlbiBjYW4geW91IHBvc3QgYW4gdXBkYXRlPyAgV291bGQgeW91IHJhdGhlciB1cyBhcHBvaW50 IGFuIEVkaXRvciB0byBoZWxwIGdldCBpdCBkb25lIHNvb25lcj8gIEkgdGhpbmsgdGhhdCB3ZSd2 ZSBiZWVuIGluIHRoaXMgcG9zdC1MQyBwaGFzZSBmb3IgbmVhcmx5IGZvdXIgbW9udGhzIG5vdy4u Lg0KDQpLZW50IC8vIHNoZXBoZXJkDQoNCg0KPT09PT0gb3JpZ2luYWwgbWVzc2FnZSA9PT09PQ0K DQpLZW50DQoNCk15IHJlcXVlc3QgZm9yIGEgcmVmZXJlbmNlIGZvciBQb3NpeCBocyBiZWVuIGZp eGVkIGluIC0xOS4NCg0KVG9tIFBldGNoDQoNCi0tLS0tIE9yaWdpbmFsIE1lc3NhZ2UgLS0tLS0N CkZyb206ICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+DQpUbzogPG5ldG1vZEBp ZXRmLm9yZz4NClNlbnQ6IFR1ZXNkYXksIEphbnVhcnkgMTYsIDIwMTggNDo1OSBQTQ0KDQo+IENs eWRlLA0KPg0KPiBUaGlzIGRyYWZ0IHN0aWxsIGlzbid0IHBhc3NpbmcgaWRuaXRzLiAgSSBwcm92 aWRlZCB0aGUgbGluayB0byBpZG5pdHMNCnByZXZpb3VzbHksIGJ1dCBoZXJlIGl0IGlzIGFnYWlu OiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3 dy5pZXRmLm9yZ190b29sc19pZG5pdHMmZD1Ed0lDQXcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVq QlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2 aklTbGFKZGNabyZtPXZCOEdlbnU0STduT3U5QjdsS3o1bVdXWUNCdXVId21nbjBISXplUEFrNlEm cz1ISGE0S2c3Wm9YT3o2dUM5VmtpVF8tak1lR2RXOUtiZm8xQ3lkaVQ0Yk04JmU9Lg0KQmVsb3cg aXMgdGhlIGlkbml0cyBvdXRwdXQgZm9yIC0xOSB3aXRoIGlubGluZWQgY29tbWVudHMuDQo+DQo+ IFBTOiBJIGRpZG4ndCBhbHNvIGNoZWNrZWQgdGhlIG90aGVyIGlzc3VlcyB3ZSdyZSB0cmFja2lu ZywgYnV0IHdpbGwNCndoZW4gd2UgZ2V0IHBhc3QgdGhlc2UgaWRuaXRzIGlzc3Vlcy4NCj4NCj4g S2VudA0KPg0KPg0KPiA9PT09PSBTVEFSVCA9PT09PQ0KPiBpZG5pdHMgMi4xNS4wMA0KPg0KPiAv dG1wL2RyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xOS50eHQ6DQo+DQo+ICAgQ2hlY2tp bmcgYm9pbGVycGxhdGUgcmVxdWlyZWQgYnkgUkZDIDUzNzggYW5kIHRoZSBJRVRGIFRydXN0IChz ZWUNCj4gICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3RydXN0ZWUuaWV0Zi5vcmdfbGljZW5zZS0yRGluZm8mZD1Ed0lDQXcmYz1IQWtZdWg2M3Jz dWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZ aHFuMmdzQllhR1R2aklTbGFKZGNabyZtPXZCOEdlbnU0STduT3U5QjdsS3o1bVdXWUNCdXVId21n bjBISXplUEFrNlEmcz1MOTVrOHJEZU5LYVNaWGtDcHF4Mmh3em1HRHc4dHJtem1ZT1QwU0xVLWZR JmU9KToNCj4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0NCj4NCj4gICAgICBObyBpc3N1ZXMgZm91 bmQgaGVyZS4NCj4NCj4gICBDaGVja2luZyBuaXRzIGFjY29yZGluZyB0bw0KaHR0cHM6Ly91cmxk ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaWQt MkRpbmZvXzFpZC0yRGd1aWRlbGluZXMudHh0JmQ9RHdJQ0F3JmM9SEFrWXVoNjNyc3VocjZTY2Jm aDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ YUdUdmpJU2xhSmRjWm8mbT12QjhHZW51NEk3bk91OUI3bEt6NW1XV1lDQnV1SHdtZ24wSEl6ZVBB azZRJnM9d3JtbzRqVmNCYjctX0xGSDd0eS1UT3BHODB0ZmUzcFdiZkNTRlphVDZlWSZlPToNCj4g ICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0NCj4NCj4gICAgICBObyBpc3N1ZXMgZm91bmQgaGVyZS4N Cj4NCj4gICBDaGVja2luZyBuaXRzIGFjY29yZGluZyB0byBodHRwczovL3VybGRlZmVuc2UucHJv b2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19pZC0yRGluZm9fY2hl Y2tsaXN0JmQ9RHdJQ0F3JmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNX em9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT12QjhH ZW51NEk3bk91OUI3bEt6NW1XV1lDQnV1SHdtZ24wSEl6ZVBBazZRJnM9X3NlU2FDS2Z6eFllYjNi MXRmWDJScVVrN0NLYk9zUnIzcFJWSnJROGxFYyZlPSA6DQo+ICAgLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0t LS0tDQo+DQo+ICAgKiogVGhlcmUgaXMgMSBpbnN0YW5jZSBvZiB0b28gbG9uZyBsaW5lcyBpbiB0 aGUgZG9jdW1lbnQsIHRoZQ0KbG9uZ2VzdCBvbmUNCj4gICAgICBiZWluZyAxIGNoYXJhY3RlciBp biBleGNlc3Mgb2YgNzIuDQo+DQo+IEtlbnQ6IHRoaXMgaXNuJ3QgYSBiaWcgZGVhbCBJTU8sIGJ1 dCBpZiBpdCdzIGVhc3kgdG8gZml4LCBpdCBzYXZlcyB0aGUNClJGQyBlZGl0b3IgYSBzdGVwIGxh dGVyIG9uLg0KPg0KPg0KPiAgIE1pc2NlbGxhbmVvdXMgd2FybmluZ3M6DQo+ICAgLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCi0tLS0tLS0tDQo+DQo+ICAgPT0gTGluZSAzNTIgaGFzIHdlaXJkIHNwYWNpbmc6ICcuLi5n b3JpdGhtICAgIGlkZS4uLicNCj4NCj4gS2VudDogdGhpcyBpcyBmaW5lLiAgaXQgaXMgaW4gYSB0 cmVlIGRpYWdyYW0uDQo+DQo+DQo+ICAgPT0gVGhlIGRvY3VtZW50IHNlZW1zIHRvIGxhY2sgdGhl IHJlY29tbWVuZGVkIFJGQyAyMTE5IGJvaWxlcnBsYXRlLA0KZXZlbiBpZg0KPiAgICAgIGl0IGFw cGVhcnMgdG8gdXNlIFJGQyAyMTE5IGtleXdvcmRzIC0tIGhvd2V2ZXIsIHRoZXJlJ3MgYQ0KcGFy YWdyYXBoIHdpdGgNCj4gICAgICBhIG1hdGNoaW5nIGJlZ2lubmluZy4gQm9pbGVycGxhdGUgZXJy b3I/DQo+DQo+ICAgICAgKFRoZSBkb2N1bWVudCBkb2VzIHNlZW0gdG8gaGF2ZSB0aGUgcmVmZXJl bmNlIHRvIFJGQyAyMTE5IHdoaWNoDQp0aGUNCj4gICAgICBJRC1DaGVja2xpc3QgcmVxdWlyZXMp Lg0KPg0KPiBLZW50OiBJIGNhbid0IGZpbmQgdGhlIGVycm9yLiAgTG9va2luZyBhdCB0aGUgeG1s LCBpdCBpcyB2ZXJiYXRpbSB3aGF0DQpJIGhhdmUgaW4gdGhlIHplcm90b3VjaCBkcmFmdC4gIG15 IGd1ZXNzIGlzIHRoYXQgdGhpcyBpcyBhIHRvb2xpbmcgZXJyb3INCmFuZCB3ZSBzaG91bGQgaWdu b3JlIGl0Lg0KPg0KPg0KPiAgIC0tIFRoZSBkb2N1bWVudCBkYXRlIChKYW51YXJ5IDEyLCAyMDE4 KSBpcyA0IGRheXMgaW4gdGhlIHBhc3QuICBJcw0KdGhpcw0KPiAgICAgIGludGVudGlvbmFsPw0K Pg0KPiBLZW50OiB0aGlzIGlzIGZpbmUsIGl0IGlzIGludGVudGlvbmFsLg0KPg0KPg0KPiAgIENo ZWNraW5nIHJlZmVyZW5jZXMgZm9yIGludGVuZGVkIHN0YXR1czogUHJvcG9zZWQgU3RhbmRhcmQN Cj4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLQ0KLS0tLS0tLS0NCj4NCj4gICAgICAoU2VlIFJGQ3MgMzk2NyBhbmQg NDg5NyBmb3IgaW5mb3JtYXRpb24gYWJvdXQgdXNpbmcgbm9ybWF0aXZlDQpyZWZlcmVuY2VzDQo+ ICAgICAgdG8gbG93ZXItbWF0dXJpdHkgZG9jdW1lbnRzIGluIFJGQ3MpDQo+DQo+ICAgPT0gVW51 c2VkIFJlZmVyZW5jZTogJ0ktRC5pZXRmLW5ldGNvbmYta2V5c3RvcmUnIGlzIGRlZmluZWQgb24g bGluZQ0KMTM4NiwNCj4gICAgICBidXQgbm8gZXhwbGljaXQgcmVmZXJlbmNlIHdhcyBmb3VuZCBp biB0aGUgdGV4dA0KPg0KPiBLZW50OiBsb29raW5nIGF0IHRoZSBYTUwsIEkgc2VlIHRoYXQgdGhl IGVudGlyZSBwYXJhZ3JhcGggdXNlcyAnWycgYW5kDQonXScgYXMgb3Bwb3NlZCB0byA8eHJlZiAu Li4vPi4gIFBsZWFzZSBmaXggdGhpcy4NCj4NCj4NCj4gICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAn UkZDNzg5NScgaXMgZGVmaW5lZCBvbiBsaW5lIDE0NTYsIGJ1dCBubw0KZXhwbGljaXQNCj4gICAg ICByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0DQo+DQo+IEtlbnQ6IGxvb2tpbmcgYXQg dGhlIFhNTCwgSSBzZWUgdHdvIGluc3RhbmNlcyBvZiBhbiB1bndhbnRlZCAiLyZndDsiDQpzdHJp bmcuICBGb3IgaW5zdGFuY2U6IDx4cmVmIHRhcmdldD0iUkZDNzg5NSIvPi8mZ3Q7ICBQbGVhc2Ug Zml4IHRoaXMuDQo+DQo+DQo+ICAgKiogRG93bnJlZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBh biBIaXN0b3JpYyBSRkM6IFJGQyA2NTg3DQo+DQo+IEtlbnQ6IGhtbW0sIHdoYXQncyBnb2luZyBv biBoZXJlPyAgVGhpcyBZQU5HIG1vZHVsZSBpcyBwcm92aWRpbmcgYW4NCmFiaWxpdHkgdG8gY29u ZmlndXJlIHRoZSAidGNwIiB0cmFuc3BvcnQsIGV2ZW4gdGhvdWdoIHRoZSBJRVNHIG1hZGUgdGhh dA0KYWJpbGl0eSBoaXN0b3JpYyBpbiAyMDEyIChzZWUgSUVTRyBOb3RlIGJlbG93KS4gIFNlYXJj aGluZyBvbmxpbmUsIGl0DQpsb29rcyBsaWtlIENpc2NvIHN1cHBvcnRzIHRoaXMsIGJ1dCBKdW5p cGVyIGRvZXMgbm90LiAgV2hhdCBhYm91dCBvdGhlcg0KdmVuZG9ycywgaXMgaXQgd2lkZWx5IHN1 cHBvcnRlZD8gIFdhcyB0aGlzIGRpc2N1c3NlZCBpbiB0aGUgV0c/DQpBbnN3ZXJpbmcgbXkgb3du IHF1ZXN0aW9uLCBzZWFyY2hpbmcgbXkgbG9jYWwgbWFpbGJveCwgSSBkb24ndCBzZWUgdGhpcw0K ZXZlciBiZWluZyBkaXNjdXNzZWQgYmVmb3JlLCBvdGhlciB0aGFuIE1hcnRpbiBxdWVzdGlvbmlu ZyBpZiBpdCB3YXMgYQ0KZ29vZCBpZGVhIGluIE1hciAyMDE2IChubyByZXNwb25zZSkuICBQbGVh c2Ugc3RhcnQgYSB0aHJlYWQgb24gdGhlIGxpc3QNCnRvIGdldCBXRyBvcGluaW9uIGlmIGl0J3Mg b2theSBmb3IgdGhlIGRyYWZ0IHRvIHByb2NlZWQgYXMgaXMgb3Igbm90Lg0KSGVyZSdzIHRoZSBJ RVNHIE5vdGUgZnJvbSBSRkMgNjU4NzoNCj4NCj4gICAgSUVTRyBOb3RlDQo+DQo+ICAgIFRoZSBJ RVNHIGRvZXMgbm90IHJlY29tbWVuZCBpbXBsZW1lbnRpbmcgb3IgZGVwbG95aW5nIHN5c2xvZyBv dmVyDQo+ICAgIHBsYWluIHRjcCwgd2hpY2ggaXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQs IGJlY2F1c2UgaXQgbGFja3MNCnRoZQ0KPiAgICBhYmlsaXR5IHRvIGVuYWJsZSBzdHJvbmcgc2Vj dXJpdHkgW1JGQzMzNjVdLg0KPg0KPiAgICBJbXBsZW1lbnRhdGlvbiBvZiB0aGUgVExTIHRyYW5z cG9ydCBbUkZDNTQyNV0gaXMgcmVjb21tZW5kZWQgc28NCnRoYXQNCj4gICAgYXBwcm9wcmlhdGUg c2VjdXJpdHkgZmVhdHVyZXMgYXJlIGF2YWlsYWJsZSB0byBvcGVyYXRvcnMgd2hvIHdhbnQNCnRv DQo+ICAgIGRlcGxveSBzZWN1cmUgc3lzbG9nLiAgU2ltaWxhcmx5LCB0aG9zZSBzZWN1cml0eSBm ZWF0dXJlcyBjYW4gYmUNCj4gICAgdHVybmVkIG9mZiBmb3IgdGhvc2Ugd2hvIGRvIG5vdCB3YW50 IHRoZW0uDQo+DQo+DQo+DQo+DQo+DQo+ICAgICAgU3VtbWFyeTogMiBlcnJvcnMgKCoqKSwgMCBm bGF3cyAofn4pLCA0IHdhcm5pbmdzICg9PSksIDEgY29tbWVudA0KKC0tKS4NCj4NCj4gICAgICBS dW4gaWRuaXRzIHdpdGggdGhlIC0tdmVyYm9zZSBvcHRpb24gZm9yIG1vcmUgZGV0YWlsZWQNCmlu Zm9ybWF0aW9uIGFib3V0DQo+ICAgICAgdGhlIGl0ZW1zIGFib3ZlLg0KPiA9PT09PSBFTkQgPT09 PT0NCj4NCj4gVGhhbmtzLA0KPiBLZW50IC8vIHNoZXBoZXJkDQo+DQo+DQo+DQo+IF9fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+IG5ldG1vZCBtYWlsaW5n IGxpc3QNCj4gbmV0bW9kQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50 LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0 bW9kJmQ9RHdJQ0F3JmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9D SSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT12QjhHZW51 NEk3bk91OUI3bEt6NW1XV1lDQnV1SHdtZ24wSEl6ZVBBazZRJnM9Q29JRGNOeUxZaDYtTjZKbUwy dVNSMk1tMlVoMWtBT09wWVA4WURiMG1tYyZlPQ0KDQoNCg0K From nobody Tue Feb 6 17:27:41 2018 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 089AF124B18; Tue, 6 Feb 2018 17:27:34 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Eric Rescorla To: "The IESG" Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org, Joel Jaeggli , netmod-chairs@ietf.org, joelja@gmail.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151796685402.25802.4513091478449946769.idtracker@ietfa.amsl.com> Date: Tue, 06 Feb 2018 17:27:34 -0800 Archived-At: Subject: [netmod] Eric Rescorla's No Objection on draft-ietf-netmod-yang-tree-diagrams-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 01:27:40 -0000 Eric Rescorla has entered the following ballot position for draft-ietf-netmod-yang-tree-diagrams-05: No Objection When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ There are no remarks associated with this position. From nobody Tue Feb 6 18:33:51 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 33322127342 for ; Tue, 6 Feb 2018 18:33:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QLdBQhG5WLrB for ; Tue, 6 Feb 2018 18:33:41 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 7DFA112421A for ; Tue, 6 Feb 2018 18:33:40 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id v188so5618515lfa.11 for ; Tue, 06 Feb 2018 18:33:40 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=DMkQQfc3PeeEkWYFWT/43YKPmQYDCCwPG7SZbSi0WS0=; b=zFbJL7TsDwPz5MwDOuCVmAau3wicuhWOc+34eNPT9YoXSEBGABHWr69e/hxs6l0Bzv B9YQoA0XtE0JUpTCFA66tRfQCR8JFpfumS447MhqIKj4QqGFNwyDlR1HGP9Cdj0HTelA K15UlPX/AbUWl7efg4n2ufzRMFpta5aGAVUjiZ4U5CJx5I6Lvstr9fyZbgBZ+Tun6xp7 FWXiTApn9W4UnCrAKsVe7yzzfTfxJl33JzNcXgrZ4UUIWFKxFcg2ntF/oeCqF3vopYFL peJiPVhmVhpGyiQ0atHOzpstO17cv8SJx8yRalL6BVEL3i0tkPsycROSGZ9ZO+rJwTvI U1Ug== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=DMkQQfc3PeeEkWYFWT/43YKPmQYDCCwPG7SZbSi0WS0=; b=cW6jfGujiKMDxUVFbnNpUjbw6O/wcuYcOOVUj50HSEfFBe8jM/9XOcxq+VnnOKZjlN z41lgxJuDLA5iXnoMuhM1HGSF5y67abXAc9OYVui+z3IuoANmUpwNbYrdH8j6IUI/b8y BiyucXfT6JHsvXX/D9qC5oCgaPb5xTskJiGluAlOrk5HWuHimh+1kNqBN+3GTccNhows IZeHlF7CDvf7sxZ1N6Tzph5kuMQKVeH+TDEyOIQOCraf3x+Mt4qmY/rtcPv6w2UUKP8A 2CtxWQ/jACE+BVj9R+/J5jSwJXfBEoVNiAJDqDjfLcJb18pSdcwV4ges6akeu1xhYAPN ct9A== X-Gm-Message-State: APf1xPA6DtajYM5GiHGcgRUKg6BgvuPjFkjKnKjct1oLZTSt3I+RCE/S cBk7hqoMB/LoMUM8mzpkPJ3uT0IUxthoFiZUuV9spQ== X-Google-Smtp-Source: AH8x227+K1SJyAoqWFZ0QYTKdGixMgcyXI2TkR4x3HIHjFvEKpan5xuxkpdM6C/qWZJn8bPa1O7Fq3SU76Ng+CrHWwI= X-Received: by 10.25.201.81 with SMTP id z78mr2834829lff.74.1517970818539; Tue, 06 Feb 2018 18:33:38 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.143.6 with HTTP; Tue, 6 Feb 2018 18:33:37 -0800 (PST) In-Reply-To: <39203004-C003-4C07-A376-006B6F7969D6@gmail.com> References: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com> <20180131181619.ziqdv5peqdeeuhl4@elstar.local> <20180205.184312.338993520253253388.mbj@tail-f.com> <39203004-C003-4C07-A376-006B6F7969D6@gmail.com> From: Andy Bierman Date: Tue, 6 Feb 2018 18:33:37 -0800 Message-ID: To: Mahesh Jethanandani Cc: Martin Bjorklund , Netconf , NetMod WG Content-Type: multipart/alternative; boundary="001a114b798c6b3c610564961fa4" Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 02:33:45 -0000 --001a114b798c6b3c610564961fa4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani wrote: > For folks that provided comments as part of LC, please verify that your > comments have been adequately addressed by -03 version of the draft. > > Most comments have been addressed. The "with-defaults" parameter does not apply when interacting with an operational datastore. There is no explanation of why the with-defaults parameter does not apply to . This is confusing. The solution that has been a standard for years still applies to all datastores, except a completely different mechanism (origin-filter) is used instead for 1 datastore. If the server code can identify a default so it can be tagged origin=3Dor:default, then it can also support with-defaults. I prefer the sentence above be changed, so that a server MAY implement with-defaults for . If the client sends it should be OK to honor it instead of returning an error. Andy > Thanks > > Mahesh Jethanandani > mjethanandani@gmail.com > > > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund wrote: > > > > Hi, > > > > Mahesh Jethanandani wrote: > >> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF. > >> > >> As part of the LC, there were a couple of comments/questions > >> raised. In particular > >> > >> - Vladmir reported an error, which Martin said is fixed in his local > copy. > > > > Fixed. > > > >> - Robert suggested that =E2=80=9C/yang-library/checksum=E2=80=9D shoul= d be a > >> reference. Juergen supported that comment, so I am assuming that > >> that will be incorporated into the draft. > > > > Yes, fixed. > > > >> - Andy had questions around datastore set to =E2=80=9Cconventional=E2= =80=9D > > > > Fixed. > > > >> , about origin filter limited to 1 source > > > > Fixed. > > > >> and the behavior of with-defaults. > > > > There were no additional changes to the document from the discussion > > about this. > > > >> I see some discussion around it with the authors > >> agreeing that some of them need some text clarifying the > >> position. Can the authors please post the suggested text/additions > >> for the WG to review. > >> - Anything else?? > >> > >> Once an updated draft has been posted, I will do a writeup on the > >> drafts and send it to IESG. > > > > The issues above are now addressed, in > > draft-ietf-netconf-nmda-netconf-03. > > > > There were no additional comments on > > draft-ietf-netconf-nmda-restconf-02, so I believe this version is > > ready. > > > > > > /martin > > > > > >> > >> Thanks. > >> > >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > >>> > >>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote: > >>>> > >>>> I do have one additional thought below on draft-ietf-netmod-revised-= datastores > section 5.3 default handling process. See in-line... > >>>> > >>> > >>> Well, this document is with the RFC editor now. I do not think it nee= ds > >>> clarification. It already has text in 5.3 such as: > >>> > >>> Requests to retrieve nodes from always return the valu= e > >>> in use if the node exists, regardless of any default value specified > >>> in the YANG module. If no value is returned for a given node, then > >>> this implies that the node is not used by the device. > >>> > >>> /js > >>> > >>>> From: Robert Wilton -X, January 31, 2018 6:31 AM > >>>> > >>>> > >>>> Hi Andy, > >>>> > >>>> On 31/01/2018 09:22, Andy Bierman wrote: > >>>> > >>>> > >>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de jacobs-university.de> j.schoenwaelder@jacobs-university.de>>> wrote: > >>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: > >>>>> Hi, > >>>>> > >>>>> I have some questions about these drafts. > >>>>> > >>>>> 1) what if datastore set to "conventional"? > >>>>> There are many places where a datastore-ref type is used. > >>>>> However, "conventional" is valid for base "datastore", even thoug= h > >>>>> it is ambiguous as a datastore selector. > >>>> > >>>> We can add explicit text that an identity that does not resolve to a > >>>> datastore implemented by the server results in an invalid value erro= r. > >>>> > >>>> > >>>> OK > >>>> > >>>> > >>>>> 2) origin filter is limited to 1 source > >>>>> This filtering seems rather limited. A client must retrieve > >>>>> and check > >>>>> all the values in use, then make repeated requests for each sourc= e > as a > >>>>> different > >>>>> leaf > >>>> > >>>> If the client does , then it has all origin information > >>>> and it can filter locally. That said, we could make origin-filter a > >>>> leaf-list which is logically ORed so that one can retrieve > >>>> origin-filter=3Dor:system or origin-filter=3Dor:learned in one reque= st. > >>>> > >>>> > >>>> OK > >>>> > >>>>> 3) with-defaults broken > >>>>> The operational datastore does not support with-defaults. > >>>>> Instead, the client must use origin-filter=3Dor:default or > with-origin > >>>>> and check all the origin attributes. Since a client needs to us= e > >>>>> with-defaults for other datastores, this special handling of > >>>>> > >>>>> seems unhelpful. > >>>> > >>>> I think the with-defaults semantics for conventional configuration > >>>> datastores are much more complicated than necessary for the > >>>> operational state datastore. Note that that the operational state > >>>> datastore reports in-use values not really defaults: > >>>> > >>>> foo > >>>> > >>>> This reports that the value 'foo' is in use and that it originates > >>>> from a default value. Note that this could also be > >>>> > >>>> foo > >>>> > >>>> in case the intended configuration datastore configured the value > >>>> 'foo' (despite this value matching the default). The with-defaults > >>>> solution is pretty complex because it tries to handle how different > >>>> systems deal with configuration defaults. The idea is to not carry > >>>> this complexity over to in-use values in the operational state > >>>> datastore. > >>>> > >>>> > >>>> Before NMDA, the client could decide if it wanted to retrieve defaul= t > nodes or not. > >>>> This client-choice has been removed from NMDA, which is a problem. > >>>> We tried to reach a sensible compromise on the data returned from > operational (defined in section 5.3 of the NMDA architecture): > >>>> - it should return explicit values for everything that is affecting > the actual running state of the device (regardless of whether the > operational value matches a schema default value). > >>>> - it does not need to, and should not, return operational values for > stuff that isn't actually in use, i.e. don't return needless and unwanted > data. > >>>> > >>>> In particular, if no value is returned from a particular data node i= n > then, barring mgmt protocol errors, a client can assume tha= t > any functionality associated with that data node is off (i.e. not in use)= . > >>>> > >>>> Some examples to illustrate the behavior: > >>>> > >>>> (i) If a protocol, e.g. OSPF, is not enabled/running then > does not need to return any data for it. It would be > reasonable to return a flag to indicate that OSPF is not enabled/running. > >>>> > >>>> (ii) If you have some funky widget on an interface that defaults to > being off and isn't being used then don't need to return an= y > data for it. > >>>> > >>>> (iii) But, if you have some funky widget on an interface that > defaults to being on, then the server should return data for it. If it is > actually enabled, then it would indicate that it is on and return any > associated values with its operational state, or if it is disabled then i= t > should explicitly report that it is off. > >>>> > >>>> (iv) I would regard that all applied configuration is "in use" by th= e > system, even if it matches the default value, and hence it should be > reported. > >>>> > >>>> > >>>> This behavior for is obviously slightly different from > the existing with-default handling that is supported for configuration > datastores. As I recall, there were a couple of reasons that we decided = to > have a different behavior for : > >>>> (a) to have consistent semantics for all servers, rather than > different servers supporting different with-defaults behaviors (which mak= es > life harder for clients because they must cope with all variants). > >>>> (b) to remove any potential ambiguity if data isn't returned. I.e. > with the existing with-defaults semantics it is not clear to me that > servers will always return an explicit value to indicate that a particula= r > widget is off if the schema defines that the default it that is enabled. > If the server doesn't support a given widget at all, it is quite plausibl= e > that it will just return no data for it. In theory features/deviations > should handle this, but those don't work so well if different linecards > have different capabilities. Hence being explicit about stuff that is in > use seems more robust. > >>>> > >>>> These are good examples. It would be great if section 5.3 > could be tweaked to make clearer the relationship between running datasto= re > defaults and other operational datastore defaults for the same tree. > >>>> > >>>> For example, let=E2=80=99s say I create a configured subscription, a= nd the > default transport protocol is NETCONF. NETCONF will be used for that > subscription even though the node might not be populated. In this case, > the object would not appear in the running datastore, but MUST* appear in > the operational datastore with the default origin (as it is in-use). > >>>> > >>>> This to me is the desired behavior as it doesn=E2=80=99t incorrectly= add > information to the running datastore, but shows what is in-use within > operational. I suspect other such relationships for other operational > tree defaults could be asserted, perhaps based on the origin. > >>>> > >>>> (* Maybe =E2=80=98MUST eventually=E2=80=99, as obviously there is a = temporal > relationship between the two datastores.) > >>>> > >>>> Eric > >>>> > >>>> Thanks, > >>>> Rob > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> /js > >>>> > >>>> Andy > >>>> > >>>> -- > >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny > >>>> Fax: +49 421 200 3103 > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> > >>>> netmod mailing list > >>>> > >>>> netmod@ietf.org > > >>>> > >>>> https://www.ietf.org/mailman/listinfo/netmod < > https://www.ietf.org/mailman/listinfo/netmod> > >>>> > >>> > >>>> _______________________________________________ > >>>> netmod mailing list > >>>> netmod@ietf.org > >>>> https://www.ietf.org/mailman/listinfo/netmod < > https://www.ietf.org/mailman/listinfo/netmod> > >>> > >>> > >>> -- > >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | German= y > >>> Fax: +49 421 200 3103 https://www.jacobs-university.de/>> > >>> > >>> _______________________________________________ > >>> netmod mailing list > >>> netmod@ietf.org > >>> https://www.ietf.org/mailman/listinfo/netmod < > https://www.ietf.org/mailman/listinfo/netmod> > >> Mahesh Jethanandani > >> mjethanandani@gmail.com > >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > --001a114b798c6b3c610564961fa4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani &= lt;mjethananda= ni@gmail.com> wrote:
For folks that provided comments as part of LC, please verify = that your comments have been adequately addressed by -03 version of the dra= ft.



Most comments have been= addressed.


    The "with-defaults" parameter does not apply when inter=
acting with an=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 operational datastore.


There is no explanation of why the with-def= aults parameter does not apply to <operational>.
This is co= nfusing. The solution that has been a standard for years still applies to
all datastores, except a completely different mechanism (origin-fi= lter) is used instead
for 1 datastore.

I= f the server code can identify a default so it can be tagged origin=3Dor:de= fault, then it can
also support with-defaults.

I prefer the sentence above be changed, so that a server MAY impleme= nt with-defaults
for <operational>.=C2=A0 If the client sen= ds <with-defaults> it should be OK to honor it instead
of r= eturning an error.


Andy
<= br>

=C2=A0
Thanks

Mahesh Jethanandani
mjethanandani@gmail.com

> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Hi,
>
> Mahesh Jethanandani <mje= thanandani@gmail.com> wrote:
>> This closes the LC for the two NDMA drafts for NETCONF and RESTCON= F.
>>
>> As part of the LC, there were a couple of comments/questions
>> raised. In particular
>>
>> - Vladmir reported an error, which Martin said is fixed in his loc= al copy.
>
> Fixed.
>
>> - Robert suggested that =E2=80=9C/yang-library/checksum=E2=80=9D s= hould be a
>>=C2=A0 reference. Juergen supported that comment, so I am assuming = that
>>=C2=A0 that will be incorporated into the draft.
>
> Yes, fixed.
>
>> - Andy had questions around datastore set to =E2=80=9Cconventional= =E2=80=9D
>
> Fixed.
>
>>=C2=A0 , about origin filter limited to 1 source
>
> Fixed.
>
>>=C2=A0 and the behavior of with-defaults.
>
> There were no additional changes to the document from the discussion > about this.
>
>>=C2=A0 I see some discussion around it with the authors
>>=C2=A0 agreeing that some of them need some text clarifying the
>>=C2=A0 position. Can the authors please post the suggested text/add= itions
>>=C2=A0 for the WG to review.
>> - Anything else??
>>
>> Once an updated draft has been posted, I will do a writeup on the<= br> >> drafts and send it to IESG.
>
> The issues above are now addressed, in
> draft-ietf-netconf-nmda-netconf-03.
>
> There were no additional comments on
> draft-ietf-netconf-nmda-restconf-02, so I believe this version is=
> ready.
>
>
> /martin
>
>
>>
>> Thanks.
>>
>>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>
>>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wr= ote:
>>>>
>>>> I do have one additional thought below on draft-ietf-netmo= d-revised-datastores section 5.3 default handling process.=C2=A0 See i= n-line...
>>>>
>>>
>>> Well, this document is with the RFC editor now. I do not think= it needs
>>> clarification. It already has text in 5.3 such as:
>>>
>>>=C2=A0 Requests to retrieve nodes from <operational> alwa= ys return the value
>>>=C2=A0 in use if the node exists, regardless of any default val= ue specified
>>>=C2=A0 in the YANG module.=C2=A0 If no value is returned for a = given node, then
>>>=C2=A0 this implies that the node is not used by the device. >>>
>>> /js
>>>
>>>> From: Robert Wilton -X, January 31, 2018 6:31 AM
>>>>
>>>>
>>>> Hi Andy,
>>>>
>>>> On 31/01/2018 09:22, Andy Bierman wrote:
>>>>
>>>>
>>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder &l= t;j.schoenwaelder@j= acobs-university.de <mailto:j.schoenwaelder@jacobs-university.de><m= ailto:j.schoen= waelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de= >>> wrote:
>>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman= wrote:
>>>>> Hi,
>>>>>
>>>>> I have some questions about these drafts.
>>>>>
>>>>> 1) what if datastore set to "conventional"?<= br> >>>>>=C2=A0 =C2=A0There are many places where a datastore-re= f type is used.
>>>>>=C2=A0 =C2=A0However, "conventional" is valid= for base "datastore", even though
>>>>>=C2=A0 =C2=A0it is ambiguous as a datastore selector. >>>>
>>>> We can add explicit text that an identity that does not re= solve to a
>>>> datastore implemented by the server results in an invalid = value error.
>>>>
>>>>
>>>> OK
>>>>
>>>>
>>>>> 2) origin filter is limited to 1 source
>>>>>=C2=A0 This filtering seems rather limited.=C2=A0 A cli= ent must retrieve
>>>>> <with-origin> and check
>>>>>=C2=A0 =C2=A0all the values in use, then make repeated = requests for each source as a
>>>>> different
>>>>>=C2=A0 =C2=A0<origin-filter> leaf
>>>>
>>>> If the client does <with-origin>, then it has all or= igin information
>>>> and it can filter locally. That said, we could make origin= -filter a
>>>> leaf-list which is logically ORed so that one can retrieve=
>>>> origin-filter=3Dor:system or origin-filter=3Dor:learned in= one request.
>>>>
>>>>
>>>> OK
>>>>
>>>>> 3) with-defaults broken
>>>>>=C2=A0 =C2=A0The operational datastore does not support= with-defaults.
>>>>>=C2=A0 =C2=A0 Instead, the client must use origin-filte= r=3Dor:default or with-origin
>>>>>=C2=A0 =C2=A0 and check all the origin attributes.=C2= =A0 Since a client needs to use
>>>>>=C2=A0 =C2=A0 with-defaults for other datastores, this = special handling of
>>>>> <operational>
>>>>>=C2=A0 =C2=A0 seems unhelpful.
>>>>
>>>> I think the with-defaults semantics for conventional confi= guration
>>>> datastores are much more complicated than necessary for th= e
>>>> operational state datastore. Note that that the operationa= l state
>>>> datastore reports in-use values not really defaults:
>>>>
>>>> <leaf or:origin=3D'default'>foo</leaf>=
>>>>
>>>> This reports that the value 'foo' is in use and th= at it originates
>>>> from a default value. Note that this could also be
>>>>
>>>> <leaf or:origin=3D'intended'>foo</le= af>
>>>>
>>>> in case the intended configuration datastore configured th= e value
>>>> 'foo' (despite this value matching the default). T= he with-defaults
>>>> solution is pretty complex because it tries to handle how = different
>>>> systems deal with configuration defaults. The idea is to n= ot carry
>>>> this complexity over to in-use values in the operational s= tate
>>>> datastore.
>>>>
>>>>
>>>> Before NMDA, the client could decide if it wanted to retri= eve default nodes or not.
>>>> This client-choice has been removed from NMDA, which is a = problem.
>>>> We tried to reach a sensible compromise on the data return= ed from operational (defined in section 5.3 of the NMDA architecture):
>>>> - it should return explicit values for everything that is = affecting the actual running state of the device (regardless of whether the= operational value matches a schema default value).
>>>> - it does not need to, and should not, return operational = values for stuff that isn't actually in use, i.e. don't return need= less and unwanted data.
>>>>
>>>> In particular, if no value is returned from a particular d= ata node in <operational> then, barring mgmt protocol errors, a clien= t can assume that any functionality associated with that data node is off (= i.e. not in use).
>>>>
>>>> Some examples to illustrate the behavior:
>>>>
>>>> (i) If a protocol, e.g. OSPF,=C2=A0 is not enabled/running= then <operational> does not need to return any data for it.=C2=A0 It= would be reasonable to return a flag to indicate that OSPF is not enabled/= running.
>>>>
>>>> (ii) If you have some funky widget on an interface that de= faults to being off and isn't being used then <operational> don&#= 39;t need to return any data for it.
>>>>
>>>> (iii) But, if you have some funky widget on an interface t= hat defaults to being on, then the server should return data for it. If it = is actually enabled, then it would indicate that it is on and return any as= sociated values with its operational state, or if it is disabled then it sh= ould explicitly report that it is off.
>>>>
>>>> (iv) I would regard that all applied configuration is &quo= t;in use" by the system, even if it matches the default value, and hen= ce it should be reported.
>>>>
>>>>
>>>> This behavior for <operational> is obviously slightl= y different from the existing with-default handling that is supported for c= onfiguration datastores.=C2=A0 As I recall, there were a couple of reasons = that we decided to have a different behavior for <operational>:
>>>> (a) to have consistent semantics for all servers, rather t= han different servers supporting different with-defaults behaviors (which m= akes life harder for clients because they must cope with all variants).
>>>> (b) to remove any potential ambiguity if data isn't re= turned.=C2=A0 I.e. with the existing with-defaults semantics it is not clea= r to me that servers will always return an explicit value to indicate that = a particular widget is off if the schema defines that the default it that i= s enabled.=C2=A0 If the server doesn't support a given widget at all, i= t is quite plausible that it will just return no data for it.=C2=A0 In theo= ry features/deviations should handle this, but those don't work so well= if different linecards have different capabilities.=C2=A0 Hence being expl= icit about stuff that is in use seems more robust.
>>>>
>>>> <eric> These are good examples.=C2=A0 It would be gr= eat if section 5.3 could be tweaked to make clearer the relationship betwee= n running datastore defaults and other operational datastore defaults for t= he same tree.
>>>>
>>>> For example, let=E2=80=99s say I create a configured subsc= ription, and the default transport protocol is NETCONF.=C2=A0 NETCONF will = be used for that subscription even though the node might not be populated.= =C2=A0 In this case, the object would not appear in the running datastore, = but MUST* appear in the operational datastore with the default origin (as i= t is in-use).
>>>>
>>>> This to me is the desired behavior as it doesn=E2=80=99t i= ncorrectly add information to the running datastore, but shows what is in-u= se within operational.=C2=A0 =C2=A0I suspect other such relationships for o= ther operational tree defaults could be asserted, perhaps based on the orig= in.
>>>>
>>>> (* Maybe =E2=80=98MUST eventually=E2=80=99, as obviously t= here is a temporal relationship between the two datastores.)
>>>>
>>>> Eric
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> /js
>>>>
>>>> Andy
>>>>
>>>> --
>>>> 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=A0C= ampus Ring 1 | 28759 Bremen | Germany
>>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0<https://www.jacobs-university.de/>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> netmod mailing list
>>>>
>>>> netmod@ietf.org <= ;mailto:netmod@ietf.org><= mailto:netmod@ietf.org <mailto:netmod@ietf.org>>
>>>>
>>>> https://www.ietf.org/mailman/listi= nfo/netmod <https://www.ietf.org/mailman/lis= tinfo/netmod>
>>>>
>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org <= ;mailto:netmod@ietf.org>
>>>> https://www.ietf.org/mailman/listi= nfo/netmod <https://www.ietf.org/mailman/lis= tinfo/netmod>
>>>
>>>
>>> --
>>> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= Jacobs University Bremen gGmbH
>>> Phone: +49 421 200 3587=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Campu= s Ring 1 | 28759 Bremen | Germany
>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0<https://www.jacobs-university.de/ <ht= tps://www.jacobs-university.de/>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org <mai= lto:netmod@ietf.org>
>>> https://www.ietf.org/mailman/listinf= o/netmod <https://www.ietf.org/mailman/listi= nfo/netmod>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com=
>>

_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf<= br>

--001a114b798c6b3c610564961fa4-- From nobody Wed Feb 7 00:07:52 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 365BD12421A for ; Wed, 7 Feb 2018 00:07:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SJA4tPUnWK9q for ; Wed, 7 Feb 2018 00:07:49 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8D6B01200C1 for ; Wed, 7 Feb 2018 00:07:49 -0800 (PST) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 3CEB71AE0118; Wed, 7 Feb 2018 09:07:48 +0100 (CET) Date: Wed, 07 Feb 2018 09:07:47 +0100 (CET) Message-Id: <20180207.090747.1266359942414260960.mbj@tail-f.com> To: joelja@bogus.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 08:07:51 -0000 Hi, I support this document as a working group document. I do have some things to discuss, e.g., should we try to use a decentralized approach to tags instead of the proposed IANA registry (as it happens we have a mechanism for decentralized, hierarchical identifiers available :) One use case that I would like to solve is tagging of mutually exclusive sets of modules, e.g., ietf vs openconfig vs native models. /martin joel jaeggli wrote: > Hi, > = > This is the start of a *two* week poll on making > draft-rtgyangdt-netmod-module-tags-02 a working group document.=A0=A0= > = > https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 > = > This document was most recently discussed at IETF 100. > = > Please send email to the list indicating "yes/support" or "no/do not > support".=A0 If indicating no, please state your reservations with th= e > document.=A0 If yes, please also feel free to provide comments you'd = like > to see addressed once the document is a WG document. > = > This poll ends on February 8. > = > Thank you! > = > Joel Jaeggli and IETF NETMOD Co-Chairs > = From nobody Wed Feb 7 01:32:28 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D5B126BF0 for ; Wed, 7 Feb 2018 01:32:26 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id F-tZg5eiwuoA for ; Wed, 7 Feb 2018 01:32:24 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 603DB126CC7 for ; Wed, 7 Feb 2018 01:32:24 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id 1C2811820412; Wed, 7 Feb 2018 10:31:11 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id B97A218203F6 for ; Wed, 7 Feb 2018 10:31:09 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org Mail-Followup-To: netmod@ietf.org Date: Wed, 07 Feb 2018 10:32:20 +0100 Message-ID: <87bmh1i1qz.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] inline mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 09:32:27 -0000 Hi, before proceeding with the schema mount draft, we need to clarify the concept of "inline" mount because it causes a lot of confusion, and the current text (in sec. 3.2) clearly doesn't work for NMDA. I believe there are some hidden assumptions about how it is supposed to work that have to be made explicit. In particular, the inline mount seems to require that an instance of the mount point plus YANG library data be placed in as a side effect of creating the corresponding mount point instance in any datastore. Perhaps it would be possible to approach it from the opposite direction and start with creating the necessary data in as a result of an explicit mount event. For example, when provisioning a new VM instance, the server would "mount" the following data in : - the mount pount instance - the YLbis data that defines the mounted schema for all datastores - any other state data that are needed. The above step basically creates a new system-controlled resource that can be configured after that in the same way as other system-controlled resources such as physical interfaces. The advantage of this approach is that we needn't speculate about whether and when the embedded YL data magically appears in - it is the mount event that does exactly this, and only after that the mounted resource can be configured. This concept would also be more alike to the mount operation known from Unix filesystems. Comments? Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 7 01:48:52 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 93E1D126BF0 for ; Wed, 7 Feb 2018 01:48:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vn2jYGl_CxuH for ; Wed, 7 Feb 2018 01:48:48 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 508AB1243F3 for ; Wed, 7 Feb 2018 01:48:48 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 5378F673; Wed, 7 Feb 2018 10:48:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id XV_PRxezmqnK; Wed, 7 Feb 2018 10:48:46 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 7 Feb 2018 10:48:46 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 38F9A2014B; Wed, 7 Feb 2018 10:48:46 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id xz_nYu_0jOxv; Wed, 7 Feb 2018 10:48:45 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B046B20149; Wed, 7 Feb 2018 10:48:45 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 7886C423B71F; Wed, 7 Feb 2018 10:48:45 +0100 (CET) Date: Wed, 7 Feb 2018 10:48:45 +0100 From: Juergen Schoenwaelder To: Robert Wilton Cc: Martin Bjorklund , kwatsen@juniper.net, netmod@ietf.org Message-ID: <20180207094845.ift6vhoomsp4d7kk@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Robert Wilton , Martin Bjorklund , kwatsen@juniper.net, netmod@ietf.org References: <53639272-C297-4757-A225-E1DAE123CBFB@juniper.net> <20180206083344.o5vqjwwtkq7awrxy@elstar.local> <20180206.101949.156510094898094470.mbj@tail-f.com> <20180206141655.6iast3lbhubk6rk5@elstar.local> <3f3f9984-0797-1ded-ded4-17543382f628@cisco.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f3f9984-0797-1ded-ded4-17543382f628@cisco.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 09:48:51 -0000 On Tue, Feb 06, 2018 at 03:25:52PM +0000, Robert Wilton wrote: > > I think that the term "external" could also be confusing, since I think that > sort of implies peer mount like semantics. The "inline" mount concept seems to subsume peer mounts. From the model perspective, is there a difference whether the mounted data is local or remote (and what does local/remove mean for a VM)? > I would suggest the term "dynamic" instead of "inline " but that could > easily be confused with dynamic datastores. Yes, I think this is not a good word either. > Perhaps rather than "inline" another choice could be "discoverable", i.e. > the schema is not known, and is dynamically discoverable inline at the mount > point. > Equally, rather than "use-schema", perhaps a better choice would be "known", > i.e. the schema is already known, and made available as part of YANG > library. Perhaps integrated schema vs. mounted schema. > Whether it would be right to change these at this time, I've no idea ... Yep. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 7 02:14:51 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F1AA81243F3 for ; Wed, 7 Feb 2018 02:14:49 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ijz-WB_OKRUg for ; Wed, 7 Feb 2018 02:14:47 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 70D06120727 for ; Wed, 7 Feb 2018 02:14:47 -0800 (PST) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 5936E1AE0118; Wed, 7 Feb 2018 11:14:43 +0100 (CET) Date: Wed, 07 Feb 2018 11:14:41 +0100 (CET) Message-Id: <20180207.111441.1066018064701748797.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: rwilton@cisco.com, kwatsen@juniper.net, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180207094845.ift6vhoomsp4d7kk@elstar.local> References: <20180206141655.6iast3lbhubk6rk5@elstar.local> <3f3f9984-0797-1ded-ded4-17543382f628@cisco.com> <20180207094845.ift6vhoomsp4d7kk@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 10:14:50 -0000 Juergen Schoenwaelder wrote: > On Tue, Feb 06, 2018 at 03:25:52PM +0000, Robert Wilton wrote: > > > > I think that the term "external" could also be confusing, since I think that > > sort of implies peer mount like semantics. > > The "inline" mount concept seems to subsume peer mounts. From the > model perspective, is there a difference whether the mounted data is > local or remote (and what does local/remove mean for a VM)? > > > I would suggest the term "dynamic" instead of "inline " but that could > > easily be confused with dynamic datastores. > > Yes, I think this is not a good word either. > > > Perhaps rather than "inline" another choice could be "discoverable", i.e. > > the schema is not known, and is dynamically discoverable inline at the mount > > point. > > Equally, rather than "use-schema", perhaps a better choice would be "known", > > i.e. the schema is already known, and made available as part of YANG > > library. > > Perhaps integrated schema vs. mounted schema. I like the term "integrated" better than "use-schema". But both cases are mounted, so we need another term than "mounted" for "inline". "segregated" doesn't sound quite right ;-) /martin > > > Whether it would be right to change these at this time, I've no idea ... > > Yep. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > From nobody Wed Feb 7 02:21:39 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80AEF1243F3 for ; Wed, 7 Feb 2018 02:21:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZnxFgtHIQ7BG for ; Wed, 7 Feb 2018 02:21:37 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E599C120727 for ; Wed, 7 Feb 2018 02:21:36 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AF16C673; Wed, 7 Feb 2018 11:21:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id XVlSXuqmmXtY; Wed, 7 Feb 2018 11:21:35 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Wed, 7 Feb 2018 11:21:35 +0100 (CET) Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 9528B2014B; Wed, 7 Feb 2018 11:21:35 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id kHd_S5SmCIOt; Wed, 7 Feb 2018 11:21:35 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3080920149; Wed, 7 Feb 2018 11:21:35 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 74890423B925; Wed, 7 Feb 2018 11:21:33 +0100 (CET) Date: Wed, 7 Feb 2018 11:21:33 +0100 From: Juergen Schoenwaelder To: Martin Bjorklund Cc: rwilton@cisco.com, kwatsen@juniper.net, netmod@ietf.org Message-ID: <20180207102133.s2tc35f6oxo4lk6t@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Martin Bjorklund , rwilton@cisco.com, kwatsen@juniper.net, netmod@ietf.org References: <20180206141655.6iast3lbhubk6rk5@elstar.local> <3f3f9984-0797-1ded-ded4-17543382f628@cisco.com> <20180207094845.ift6vhoomsp4d7kk@elstar.local> <20180207.111441.1066018064701748797.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180207.111441.1066018064701748797.mbj@tail-f.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 10:21:38 -0000 On Wed, Feb 07, 2018 at 11:14:41AM +0100, Martin Bjorklund wrote: > > Perhaps integrated schema vs. mounted schema. > > I like the term "integrated" better than "use-schema". But both cases > are mounted, so we need another term than "mounted" for "inline". > "segregated" doesn't sound quite right ;-) > integrated schema vs. separated schema /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 7 02:29:28 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7444B120727 for ; Wed, 7 Feb 2018 02:29:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FP3_N_niSs6Z for ; Wed, 7 Feb 2018 02:29:23 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9774A126C19 for ; Wed, 7 Feb 2018 02:29:23 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:9001:c4ff:fe87:6c8]) by mail.nic.cz (Postfix) with ESMTPSA id F3371620CF for ; Wed, 7 Feb 2018 11:29:21 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1517999362; bh=47rzlMnzSCQW7omCrMe+ggpunIvVd3mL3GuKTNToIls=; h=From:To:Date; b=RAaw2SahMbUfUbhgmpYkveTKjT+I+yElFLnITjyrWAXulWsfCcKMyMhgxF7W93fwU F+fKT+6RhM/tfHPWv5bJjcVRSUjzM65Q2mG2XJaAFqkQ356HHFOC/mhY0reB8NJZ09 Kk+t+yy6gr080DfN11BV4owXg9Hu7cS0at8wWREs= Message-ID: <1517999361.22328.33.camel@nic.cz> From: Ladislav Lhotka To: netmod@ietf.org Date: Wed, 07 Feb 2018 11:29:21 +0100 In-Reply-To: <20180207.111441.1066018064701748797.mbj@tail-f.com> References: <20180206141655.6iast3lbhubk6rk5@elstar.local> <3f3f9984-0797-1ded-ded4-17543382f628@cisco.com> <20180207094845.ift6vhoomsp4d7kk@elstar.local> <20180207.111441.1066018064701748797.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 10:29:27 -0000 On Wed, 2018-02-07 at 11:14 +0100, Martin Bjorklund wrote: > Juergen Schoenwaelder wrote: > > On Tue, Feb 06, 2018 at 03:25:52PM +0000, Robert Wilton wrote: > > > > > > I think that the term "external" could also be confusing, since I think > > > that > > > sort of implies peer mount like semantics. > > > > The "inline" mount concept seems to subsume peer mounts. From the > > model perspective, is there a difference whether the mounted data is > > local or remote (and what does local/remove mean for a VM)? > > > > > I would suggest the term "dynamic" instead of "inline " but that could > > > easily be confused with dynamic datastores. > > > > Yes, I think this is not a good word either. > > > > > Perhaps rather than "inline" another choice could be "discoverable", i.e. > > > the schema is not known, and is dynamically discoverable inline at the > > > mount > > > point. > > > Equally, rather than "use-schema", perhaps a better choice would be > > > "known", > > > i.e. the schema is already known, and made available as part of YANG > > > library. > > > > Perhaps integrated schema vs. mounted schema. > > I like the term "integrated" better than "use-schema". But both cases > are mounted, so we need another term than "mounted" for "inline". > "segregated" doesn't sound quite right ;-) I would prefer to use the term "mount" only for the inline case and find something else for the use-schema case. The term "mount" evokes that some *instance* data being added, which is what happens in the "inline" case but not for "use-schema". Lada > > > /martin > > > > > > Whether it would be right to change these at this time, I've no idea ... > > > > Yep. > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 7 02:38:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 45909126C19 for ; Wed, 7 Feb 2018 02:38:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KcqN1ddeQYRz for ; Wed, 7 Feb 2018 02:37:58 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3625C124D6C for ; Wed, 7 Feb 2018 02:37:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6732; q=dns/txt; s=iport; t=1517999878; x=1519209478; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=qNrrPTeJBDsruOpk4Gh9L2XvpRPw5ZqfXSMtZoDOO5U=; b=dMZ6Jm1biFUA7wf1IW+Kd9O5aYE67YSzGrSDtmcb1n/bcUlMUnObrKnV +PdEUQlEMHcL3m4xn/8SJM9oicjEcZKuhcEZn8oR6+Z8YPd4RRrB0F8eW tigGhzhx8w7F+arXznzCPrOD1ruAKoCwIL4m2+RteQPFKkJmd2QkDhe/q g=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B3AQDK1Xpa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYMggRdwKINlixiPDCeReYVuggMKGAEKgV6Ca08Cgz0UAQIBAQE?= =?us-ascii?q?BAQECayiFJAEBBAEBIUsbCxIGKgICJyIOBgEMBgIBAYoxELIUgicmhFqDeIIKA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAWEdYNsgWgpDIJ5gy8BAQIBgTsBEgEHAQE?= =?us-ascii?q?JgySCZQWaJIoFCYgdjV2CHoYng3OIBo16gXmIF4E8NiIlO3AzGggbFT2CRoR3Q?= =?us-ascii?q?TeLTQ0YgiQBAQE?= X-IronPort-AV: E=Sophos;i="5.46,473,1511827200"; d="scan'208,217";a="1914472" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2018 10:37:56 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w17AbtS0017283; Wed, 7 Feb 2018 10:37:56 GMT To: joel jaeggli , NETMOD Working Group References: From: Robert Wilton Message-ID: Date: Wed, 7 Feb 2018 10:37:55 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------8D733B936FFAB4B19429B2F8" Content-Language: en-US Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 10:38:01 -0000 This is a multi-part message in MIME format. --------------8D733B936FFAB4B19429B2F8 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi, I conditionally support WG adoption of this draft, with the condition being that I think that there are technical areas of this draft that should be changed (I've mentioned these previously). My interpretation of the approach currently documented in the draft assumes that the tags are treated as a special type of configuration that don't quite adhere to normal configuration rules.  In particular, the approach assumes that the server will pre-populate the running configuration with the server default tags.  A client can then fetch and modify these and push them back to the server.  However, I think that this approach will both bloat the configuration and violates the principal that the contents of the configuration should be owned by the client, not the server.  And probably raise various other corner case conditions as well (e.g. what do you do if the server software is upgraded and the tags change? how do you merge the current client and new server defaults together?) Instead, I think that the tags should make use of the NMDA architecture and be treated entirely as regular configuration: - would always report the current set of tags in effect (system default values, overridden by any tags add/removed/modified via configuration). - would only contain any configured changes to the tags (additional tags could be added, or existing tags could be marked as being changed or deleted). - No reset IPC is required, since it is just regular configuration. I think that the draft should also support NMDA by augmenting YANG library bis. Thanks, Rob On 06/02/2018 23:47, joel jaeggli wrote: > > Hi, > > This is the start of a *two* week poll on making > draft-rtgyangdt-netmod-module-tags-02 a working group document. > > https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 > > This document was most recently discussed at IETF 100. > > Please send email to the list indicating "yes/support" or "no/do not > support".  If indicating no, please state your reservations with the > document.  If yes, please also feel free to provide comments you'd > like to see addressed once the document is a WG document. > > This poll ends on February 8. > > Thank you! > > Joel Jaeggli and IETF NETMOD Co-Chairs > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod --------------8D733B936FFAB4B19429B2F8 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi,

I conditionally support WG adoption of this draft, with the condition being that I think that there are technical areas of this draft that should be changed (I've mentioned these previously).

My interpretation of the approach currently documented in the draft assumes that the tags are treated as a special type of configuration that don't quite adhere to normal configuration rules.  In particular, the approach assumes that the server will pre-populate the running configuration with the server default tags.  A client can then fetch and modify these and push them back to the server.  However, I think that this approach will both bloat the configuration and violates the principal that the contents of the configuration should be owned by the client, not the server.  And probably raise various other corner case conditions as well (e.g. what do you do if the server software is upgraded and the tags change? how do you merge the current client and new server defaults together?)

Instead, I think that the tags should make use of the NMDA architecture and be treated entirely as regular configuration:
- <operational> would always report the current set of tags in effect (system default values, overridden by any tags add/removed/modified via configuration).
- <running> would only contain any configured changes to the tags (additional tags could be added, or existing tags could be marked as being changed or deleted).
- No reset IPC is required, since it is just regular configuration.

I think that the draft should also support NMDA by augmenting YANG library bis.

Thanks,
Rob


On 06/02/2018 23:47, joel jaeggli wrote:

Hi,

This is the start of a *two* week poll on making draft-rtgyangdt-netmod-module-tags-02 a working group document.  

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Please send email to the list indicating "yes/support" or "no/do not support".  If indicating no, please state your reservations with the document.  If yes, please also feel free to provide comments you'd like to see addressed once the document is a WG document.

This poll ends on February 8.

Thank you!

Joel Jaeggli and IETF NETMOD Co-Chairs



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

--------------8D733B936FFAB4B19429B2F8-- From nobody Wed Feb 7 03:12:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA36124235 for ; Wed, 7 Feb 2018 03:12:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id j-Jt6Z8vrJ4d for ; Wed, 7 Feb 2018 03:12:37 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0125.outbound.protection.outlook.com [104.47.0.125]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5863F124D6C for ; Wed, 7 Feb 2018 03:12:36 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=QZPAArncnxmGQ0VpLiHfy98l1gEZVou0f/igHQQTB+E=; b=Y6I69BZHedihX/PP72ZCZW362Jwx0G/74jRl3NZ8ryJXN9QKPSXd8Tdi2bsYJ1D4pIklZTe3JSwRdfW3I/tfw2I6+T6PM8nTXTOsWn+9k9VzKcAHDrL2BXDNmOjCeoJ5dJNuBDhegFX4RdWOuRDNvV/d/aes8xIuY8EpzGaqBWs= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.169.153.236) by DB6PR0701MB2999.eurprd07.prod.outlook.com (2603:10a6:4:73::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Wed, 7 Feb 2018 11:12:33 +0000 Message-ID: <01e201d3a004$50a23f40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "t.petch" , "NETMOD Working Group" , "Benoit Claise" Date: Wed, 7 Feb 2018 11:08:50 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: DB6P190CA0033.EURP190.PROD.OUTLOOK.COM (2603:10a6:6:2f::46) To DB6PR0701MB2999.eurprd07.prod.outlook.com (2603:10a6:4:73::9) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1d649e2e-8dd6-47f1-293c-08d56e1bafce X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(2017052603307)(7193020); SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 3:6r6H0uZR74QTJHPIOV1Yoe2V63iVKRM5Ag6+aJnq+9n3Ou7X3O013WSogqw9vX2KuC9oIwzar5uDXhi6sEuRBiHa9CQTru034Z3FopnwW2cjMO63Z50VknfkM1LbNZUC2SMv8l1Jc/bVeWrj6EdaNSiefJq5kC1ww7/jZXy4dTZjBxdGjghWryKhgP5F4BIo8T5bNT0JPUKPVO9M7qwC02QbVbiDRPOz6HvDmz6ew3P0wzO54PLxbtskoebokmfx; 25:AGJlCdUeA2L9KJC1vPlBrJS+3V8CDhZ829w114XVKJH8nyw4hHh961POcLbx/c6PiSF78cHSuUT4RDJUvSqyii+Z/hzYnKXIWt8Uvv6/cXvM8eMg2fm2DtSF2RSXjTFQvfTdz2k1dl1AxmqP0DiCc15X+NmTPRlwHeY1UNkSSAtBt8rgHpd4InAgkalLM24IhNqWGzBOW5d8IRlBmnNHnZeyGkOSTX9qseez5UX/VF4KOWt6grjyC3s2S/Fpo8Z4+dOFjRsUFB6w4TF3K0osSjsk/RGVl8z1tvDhsYZVd3O5L3WSZL4F8fIpqiiVXAV7e9AsnRXbsYF9KmRNNlXF3A==; 31:jKLFkgP+og4c9mJpi5eM+TAQkvpB3Ah/9LTl6ZfmedPTKjFY2XT05ivomNAfNw5Pq4Fou4ZrRIAwrfz0jidj+HJpwKj8XzO6Eh6ulY+WlmqnqDFrMEW5gAZMLba4fmo85p9XGib3cN0RdPDkRoJ01p6kObbt90KNsLIBIiT4QF9gJGwKmH5edn96EM+pdHa9vmardk76wwHyHQ5BdNDLzYVdVq7hBwfjpf3ST7B3o+c= X-MS-TrafficTypeDiagnostic: DB6PR0701MB2999: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123562045)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DB6PR0701MB2999; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2999; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 4:hNVjyyCGA8dB0RG9vTqjw4qHtVvMLeZdEEdl3oB/SLnLcF3ofNsEjLDQbX/y9ER2Oe3TWprz34B+9wjb1uDMLG735vTqtzH5fVVrGTEBghHSy1KzICzGTZIUWXhSN+GIJWsm3zbHwgN0Yhxh0qe4ZmabNcp+e5IfSg+duUJN/oiBRQ0oZfiLK8SpWboJfoZaf0rrwAg05p+SK8IKyExFRYafLOYc3tkVAFgAGSt5YXRCOQrxH3bJBWSMm7B/NKPNZV2tXXQE19dkV8NT2RjRGw== X-Forefront-PRVS: 0576145E86 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(366004)(376002)(39380400002)(396003)(39860400002)(346002)(51444003)(189003)(199004)(110136005)(4720700003)(2906002)(47776003)(84392002)(50466002)(68736007)(66066001)(316002)(296002)(62236002)(5660300001)(44716002)(25786009)(81686011)(81816011)(105586002)(33896004)(386003)(305945005)(6116002)(3846002)(230700001)(6666003)(7736002)(8936002)(50226002)(106356001)(61296003)(14496001)(81166006)(81156014)(26005)(478600001)(8676002)(16526019)(97736004)(8666007)(23756003)(6496006)(86362001)(1556002)(9686003)(52116002)(44736005)(6486002)(53936002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2999; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; DB6PR0701MB2999; 23:DslKK6J2FOeXOdIsQiWSkvYqPxcgWYFU1cgQc?= =?iso-8859-1?Q?VqykWTZUjqqPEFDlXB9vfUOUU1RJqdaagTwIoOpJ0z3H35iSyGEqNwIF4W?= =?iso-8859-1?Q?92+kyeTzcvN6ChG0FzCSwhjfPfgXT1zAxZDKVjg5zsjoY2A17WGF1sB+66?= =?iso-8859-1?Q?NYdQDgEr4SM/bCmfKbJWDbPj4bweoAKkHuk/SRdacdnOoIh0HSsSWsEwi1?= =?iso-8859-1?Q?4MlSxfnZCJ6LjBCr2tFwalRNMO9AbfP1OI6e4TPCH6Zlt3pJJun9BA+JGb?= =?iso-8859-1?Q?TTbqM+AI/1P7GK3oe78AwAcBnLZOdstBFHqzUUu2c57YywfEws+gH2Qc7O?= =?iso-8859-1?Q?S4eQKWrgwNuDSQm1loWxSBRT/0dY6NsUQ7LFt9qjvwDYSrvSjbnKU8x3RG?= =?iso-8859-1?Q?5O46wjRgYX12pF/TDXddve56+Abs2Zkuwk/cHD0UtV3lZwfDlgjpEG1u29?= =?iso-8859-1?Q?Zx8HMYmFkLKKrwADKOCJC3ypOl24LQF5IJ/3rRqlqUmeZREuDxHUSrQA2B?= =?iso-8859-1?Q?QdivlnNduUOeyIoXJi9ge5tlaxC6+bEOie86DFiFp+ouLFIz6pk8GqIZiL?= =?iso-8859-1?Q?LKy3mWbuQWtfrabxYazSBgMc1niVNsPD5Zib4wd+YkTv7OkYz5joR91c67?= =?iso-8859-1?Q?pN+Pn4q575mmT7vYMrUKwE6DdiIFrNDZ0UU6E4xPL+2dkavT4/+n+BRv0x?= =?iso-8859-1?Q?zDgj0x/50IgKtN5YXTNxrFmGReVklF0jqDOBjNm+Fx23U/XMRdZcDbR5cC?= =?iso-8859-1?Q?8T9Ry5MCoVDgK0q+3tjKlVNZBk06vnZqHbeQDXSqPehA+oEEvav8cP+Ym5?= =?iso-8859-1?Q?+v+aaRv5HoVzir8YOwBjx4RKDTt/vO+waRqGxCxyI2xcwUe/DbRUdnZ6Uf?= =?iso-8859-1?Q?RwQR+wbaM+Kixe2w2AuXUUN/j2SnUPcjPVyKliefV+7FJNTiQivbUkUFfx?= =?iso-8859-1?Q?he/uf6BYIjnCl2qGS181fYGx82emCfkuS1juU4OqDEJuZKdV2QUnCpdwox?= =?iso-8859-1?Q?uGLUU3lwEna9OOcbsO8hIVd7QEnl/UVd9wmUlQiLFF1PxxGWz49SP6h4ql?= =?iso-8859-1?Q?q/azMiuuR4Os1yFV4Flq62d1cJ+p/u1UfbGvX8kE/f72MrQOHRQNIKv5qu?= =?iso-8859-1?Q?2sFhi+635TISl3EVtFKDznc+QBvGeC0UuV+Hm1/9Xgg/czvvBuylrHfT/f?= =?iso-8859-1?Q?/4Fr4NqL8+yU2n4VU+g0tJzLWX8zXHorfG4O38iGf2uG1G1DmIUsFaZu+W?= =?iso-8859-1?Q?jFEZzOhSW0tiT1oviN2OzDTdVC8WyxwbLhgNgxDYgx4i3Bbv5Bx6RcJn5Q?= =?iso-8859-1?Q?hNKMeyuq/XILNpwrR/VRWJBxUq4psFgcCbQF3jrWODd03obQpTC0pHWtOj?= =?iso-8859-1?Q?ToANfGTKic=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2999; 6:PPLr03pSz4wbgncgy2PBoktKnkCCo2AGEA4yzn6WQHq75QbJOQxZVLZX8SHw8ISuuD0fMzhGlURey2xfk59lBYPmhTUtPFxblkSNjUsWD0DnwwTFYRjRAzcwmRxFY0gd8clVo8VLX0f5hThBzZI7RYnZk2lAIeLAxW0Xbus0uI4cCMKBLuIb+12geX/yeXQyQkPE5pzzdUejS8DddERj0016f0dKqtqH2aTQcq4yc42/Vo+vsogrw6TAwBDDn6dGnEEKiE8dPaqUTE3csuBUqU224ydZO+BAmOc1Z9q5QISzgsZMyTUGsZ605WYsqcGsh7qeJ0KkMZzAdmtyQPOIU1vvboj43Gq6UkrfmnZss8k=; 5:U7IhyuDxtNsGwWJqAICVvO737elSitsjkYvkuqcw/LsnllNkg5JEaD6PeddNHRazbgmpVe0aG2kPFMrRAslbNugePgc6Vi6mArG1wIBusk/CSTYa+B0UWEoyT+lHVGj4c4bfSmlX156MhzRMW2a3RiaHUKmDWvq0NxV+7BGN4tU=; 24:xBMopAGWNtQuQxRLrvlBB5lu1QUSpjPWH+KYdBSncmJDtkPJ13lr3FGHxKTNVpZhrhM38AQ+G5n88MV4rASOhegsCHSLvK+ZnTNcrFJDu24=; 7:H4XCUr42+5UZKIOPMINHcqgwNHG//8gHY/ebrkfMhyY1uI8D2F5EJD7TpEl6wcD/ZS9gcOx9zJrcnm71xMU2xI7MwrsgSqzZg7+GnA64BLxt2tgF1XzpoAVeV82tstpDMQ0U9OFmVjTIkrMGulyNJxtuX9agGNxhf1vJKw5nDIXC90wKcbjTyK8g3rn7Oiw3bmZJO0UuhwGXBMyTKBO4ttVApvQuSPQX2S2y7TGQp83YYXbbAcY9yGwWFVCpawYP SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2018 11:12:33.2989 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1d649e2e-8dd6-47f1-293c-08d56e1bafce X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2999 Archived-At: Subject: [netmod] draft-ietf-dhc-dhcpv6-yang-05 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 11:12:40 -0000 As and when this comes to a YANG Doctor review, the reviewer might like to note that while there are 28 RFC referenced in the Reference or Description clauses of the YANG modules, 6 do not appear in the either Reference section, namely RFC826 (Description clause) RFC2464 (Description clause) RFC3989 RFC 4122 (Description clause) RFC4822 RFC7824 Also, the way in which the RFC are referred to in these clauses is inconsistent, e.g. RFC826 [RFC0826] RFC2464 RFC 3315 [RFC3315] I think that RFC826 is correct but YMMV. The 19 that are referenced as Informative References are RFC3319 8.2 RFC3646 8.2 RFC3898 8.2 RFC4075 8.2 RFC4242 8.2 RFC4704 8.2 RFC4833 8.2 RFC5908 8.2 RFC5970 8.2 RFC6334 8.2 RFC6422 8.2 RFC6440 8.2 RFC6784 8.2 RFC6939 8.2 RFC7078 8.2 RFC7083 8.2 RFC7227 8.2 RFC7291 8.2 I am not - and do not want to be -subscribed to the DHCP list. I will look out for this at IETF Last Call but may miss it. Tom Petch From nobody Wed Feb 7 03:15:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B80124235; Wed, 7 Feb 2018 03:15:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hwit3025lvjW; Wed, 7 Feb 2018 03:15:03 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 40E5912778D; Wed, 7 Feb 2018 03:15:02 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=46334; q=dns/txt; s=iport; t=1518002102; x=1519211702; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=BjcF6vNsLiUyQO/5dHWiT94A3EW4zXYwoV3JpKb9A5M=; b=OI22OoKDUkpYjqPydZT25aOQNSQu1ghQaxYa2N4L5jIw/GjA9QPennEj glmGD0MztZb4W9JhwJj+jbrl9HOwRMSa4W8SubJc5aysSUAk7KhECsru+ +fv6HnpQJT6up/DDY0tGH/BZykr0PMp61a5s9lUi4uk1KrteT8Pz/nqXD Y=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B1AQBT33pa/xbLJq1SAQYDGQEBAQEBA?= =?us-ascii?q?QEBAQEBAQcBAQEBAYJZR4EXcCiDZYsYjzOJFY5SggADChgBCoM6gQ9PAoM9FQE?= =?us-ascii?q?CAQEBAQEBAmsohSMBAQEDAQEBGAlLBAcFCQIJAhACAwMNDAIFAQYDAgIbBgYfA?= =?us-ascii?q?w4GAQwGAgEBFQKKAgMNCBCUFZ10gicmhFqCOg2BMYIKAQEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBGAUFhHCDbIFoKYF3gQ6Ca0QBAQKBRAEDDwI3Jg8HgjqCZQWaDReJU?= =?us-ascii?q?DUJkHOFB4IehieDc4FlhiGOQoExiBeBPDUjgVAzGggbFT2CRoIcORyCBkE3cIp?= =?us-ascii?q?bAiWCJAEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,473,1511827200"; d="scan'208,217";a="1863589" Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2018 11:14:59 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w17BEwGf016271; Wed, 7 Feb 2018 11:14:59 GMT To: Andy Bierman , Mahesh Jethanandani , Netconf Cc: NetMod WG References: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com> <20180131181619.ziqdv5peqdeeuhl4@elstar.local> <20180205.184312.338993520253253388.mbj@tail-f.com> <39203004-C003-4C07-A376-006B6F7969D6@gmail.com> From: Robert Wilton Message-ID: <8d90fd4c-711a-1b90-529b-778f81e80bf5@cisco.com> Date: Wed, 7 Feb 2018 11:14:58 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------5BC41D1C223CB253F73D2AE4" Content-Language: en-US Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 11:15:08 -0000 This is a multi-part message in MIME format. --------------5BC41D1C223CB253F73D2AE4 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi Andy, On 07/02/2018 02:33, Andy Bierman wrote: > > > On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani > > wrote: > > For folks that provided comments as part of LC, please verify that > your comments have been adequately addressed by -03 version of the > draft. > > > > Most comments have been addressed. > > > The "with-defaults" parameter does not apply when interacting with an >     operational datastore. > > > There is no explanation of why the with-defaults parameter does not > apply to . > This is confusing. The solution that has been a standard for years > still applies to > all datastores, except a completely different mechanism > (origin-filter) is used instead > for 1 datastore. > > If the server code can identify a default so it can be tagged > origin=or:default, then it can > also support with-defaults. > > I prefer the sentence above be changed, so that a server MAY implement > with-defaults > for .  If the client sends it should be > OK to honor it instead > of returning an error. I have two concerns with changing this to a MAY: (1) The most useful "with-defaults" behavior differs for vs the configuration datastores, but with-defaults only allows a single standard behavior to be specified. E.g. for configuration datastores the most appropriate semantics (if the client doesn't explicitly ask for something else) is "explicit". i.e. you give back exactly what was put in. But, for operational, the most appropriate semantics (if the client doesn't explicitly ask for something else) is something like "report-all", i.e. the device reports the precise current state including any defaults.  However, we felt that this would return too much unnecessary data, hence why the datastore architecture defines "in-use" data, allowing the server to prune out any data that is clearly irrelevant. (2) is a new datastore.  I personally don't want each server choosing how the data is returned, which requires that clients must handle all variants.  It would be better for the draft to specify the standard semantics to use unless a client has explicitly requested something else. I'm not opposed to a "with-defaults-bis", or a new draft covering "with-defaults" for ", but I think that: (i) We shouldn't delay the NMDA protocol drafts for this, this can be done as separate draft adding extra optional functionality. (ii) The semantics for retrieving data from operational (or notifications) should be as defined by "in-use" in the NMDA architecture, unless a client has explicitly specified, or configured, a different behavior. (iii) Probably the only existing option defined in "with-defaults" that makes sense for is a variant of "trim" that is specified to return what is defined as returning the "in-use" values, but also excluding any values that match a default value specified in the schema. Thanks, Rob > > > Andy > > > Thanks > > Mahesh Jethanandani > mjethanandani@gmail.com > > > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund > wrote: > > > > Hi, > > > > Mahesh Jethanandani > wrote: > >> This closes the LC for the two NDMA drafts for NETCONF and > RESTCONF. > >> > >> As part of the LC, there were a couple of comments/questions > >> raised. In particular > >> > >> - Vladmir reported an error, which Martin said is fixed in his > local copy. > > > > Fixed. > > > >> - Robert suggested that “/yang-library/checksum†should be a > >>  reference. Juergen supported that comment, so I am assuming that > >>  that will be incorporated into the draft. > > > > Yes, fixed. > > > >> - Andy had questions around datastore set to “conventional†> > > > Fixed. > > > >>  , about origin filter limited to 1 source > > > > Fixed. > > > >>  and the behavior of with-defaults. > > > > There were no additional changes to the document from the discussion > > about this. > > > >>  I see some discussion around it with the authors > >>  agreeing that some of them need some text clarifying the > >>  position. Can the authors please post the suggested text/additions > >>  for the WG to review. > >> - Anything else?? > >> > >> Once an updated draft has been posted, I will do a writeup on the > >> drafts and send it to IESG. > > > > The issues above are now addressed, in > > draft-ietf-netconf-nmda-netconf-03. > > > > There were no additional comments on > > draft-ietf-netconf-nmda-restconf-02, so I believe this version is > > ready. > > > > > > /martin > > > > > >> > >> Thanks. > >> > >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder > > wrote: > >>> > >>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote: > >>>> > >>>> I do have one additional thought below on > draft-ietf-netmod-revised-datastores section 5.3 default handling > process.  See in-line... > >>>> > >>> > >>> Well, this document is with the RFC editor now. I do not think > it needs > >>> clarification. It already has text in 5.3 such as: > >>> > >>>  Requests to retrieve nodes from always return > the value > >>>  in use if the node exists, regardless of any default value > specified > >>>  in the YANG module.  If no value is returned for a given > node, then > >>>  this implies that the node is not used by the device. > >>> > >>> /js > >>> > >>>> From: Robert Wilton -X, January 31, 2018 6:31 AM > >>>> > >>>> > >>>> Hi Andy, > >>>> > >>>> On 31/01/2018 09:22, Andy Bierman wrote: > >>>> > >>>> > >>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder > > > > >>> wrote: > >>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: > >>>>> Hi, > >>>>> > >>>>> I have some questions about these drafts. > >>>>> > >>>>> 1) what if datastore set to "conventional"? > >>>>>   There are many places where a datastore-ref type is used. > >>>>>   However, "conventional" is valid for base "datastore", > even though > >>>>>   it is ambiguous as a datastore selector. > >>>> > >>>> We can add explicit text that an identity that does not > resolve to a > >>>> datastore implemented by the server results in an invalid > value error. > >>>> > >>>> > >>>> OK > >>>> > >>>> > >>>>> 2) origin filter is limited to 1 source > >>>>>  This filtering seems rather limited.  A client must retrieve > >>>>> and check > >>>>>   all the values in use, then make repeated requests for > each source as a > >>>>> different > >>>>>    leaf > >>>> > >>>> If the client does , then it has all origin > information > >>>> and it can filter locally. That said, we could make > origin-filter a > >>>> leaf-list which is logically ORed so that one can retrieve > >>>> origin-filter=or:system or origin-filter=or:learned in one > request. > >>>> > >>>> > >>>> OK > >>>> > >>>>> 3) with-defaults broken > >>>>>   The operational datastore does not support with-defaults. > >>>>>    Instead, the client must use origin-filter=or:default or > with-origin > >>>>>    and check all the origin attributes.  Since a client > needs to use > >>>>>    with-defaults for other datastores, this special handling of > >>>>> > >>>>>    seems unhelpful. > >>>> > >>>> I think the with-defaults semantics for conventional > configuration > >>>> datastores are much more complicated than necessary for the > >>>> operational state datastore. Note that that the operational state > >>>> datastore reports in-use values not really defaults: > >>>> > >>>> foo > >>>> > >>>> This reports that the value 'foo' is in use and that it > originates > >>>> from a default value. Note that this could also be > >>>> > >>>> foo > >>>> > >>>> in case the intended configuration datastore configured the value > >>>> 'foo' (despite this value matching the default). The > with-defaults > >>>> solution is pretty complex because it tries to handle how > different > >>>> systems deal with configuration defaults. The idea is to not > carry > >>>> this complexity over to in-use values in the operational state > >>>> datastore. > >>>> > >>>> > >>>> Before NMDA, the client could decide if it wanted to retrieve > default nodes or not. > >>>> This client-choice has been removed from NMDA, which is a > problem. > >>>> We tried to reach a sensible compromise on the data returned > from operational (defined in section 5.3 of the NMDA architecture): > >>>> - it should return explicit values for everything that is > affecting the actual running state of the device (regardless of > whether the operational value matches a schema default value). > >>>> - it does not need to, and should not, return operational > values for stuff that isn't actually in use, i.e. don't return > needless and unwanted data. > >>>> > >>>> In particular, if no value is returned from a particular data > node in then, barring mgmt protocol errors, a client > can assume that any functionality associated with that data node > is off (i.e. not in use). > >>>> > >>>> Some examples to illustrate the behavior: > >>>> > >>>> (i) If a protocol, e.g. OSPF,  is not enabled/running then > does not need to return any data for it.  It would > be reasonable to return a flag to indicate that OSPF is not > enabled/running. > >>>> > >>>> (ii) If you have some funky widget on an interface that > defaults to being off and isn't being used then > don't need to return any data for it. > >>>> > >>>> (iii) But, if you have some funky widget on an interface that > defaults to being on, then the server should return data for it. > If it is actually enabled, then it would indicate that it is on > and return any associated values with its operational state, or if > it is disabled then it should explicitly report that it is off. > >>>> > >>>> (iv) I would regard that all applied configuration is "in > use" by the system, even if it matches the default value, and > hence it should be reported. > >>>> > >>>> > >>>> This behavior for is obviously slightly > different from the existing with-default handling that is > supported for configuration datastores.  As I recall, there were a > couple of reasons that we decided to have a different behavior for > : > >>>> (a) to have consistent semantics for all servers, rather than > different servers supporting different with-defaults behaviors > (which makes life harder for clients because they must cope with > all variants). > >>>> (b) to remove any potential ambiguity if data isn't > returned.  I.e. with the existing with-defaults semantics it is > not clear to me that servers will always return an explicit value > to indicate that a particular widget is off if the schema defines > that the default it that is enabled.  If the server doesn't > support a given widget at all, it is quite plausible that it will > just return no data for it.  In theory features/deviations should > handle this, but those don't work so well if different linecards > have different capabilities.  Hence being explicit about stuff > that is in use seems more robust. > >>>> > >>>> These are good examples.  It would be great if section > 5.3 could be tweaked to make clearer the relationship between > running datastore defaults and other operational datastore > defaults for the same tree. > >>>> > >>>> For example, let’s say I create a configured subscription, > and the default transport protocol is NETCONF.  NETCONF will be > used for that subscription even though the node might not be > populated. In this case, the object would not appear in the > running datastore, but MUST* appear in the operational datastore > with the default origin (as it is in-use). > >>>> > >>>> This to me is the desired behavior as it doesn’t incorrectly > add information to the running datastore, but shows what is in-use > within operational.  I suspect other such relationships for other > operational tree defaults could be asserted, perhaps based on the > origin. > >>>> > >>>> (* Maybe ‘MUST eventually’, as obviously there is a temporal > relationship between the two datastores.) > >>>> > >>>> Eric > >>>> > >>>> Thanks, > >>>> Rob > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> /js > >>>> > >>>> Andy > >>>> > >>>> -- > >>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH > >>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen > | Germany > >>>> Fax:   +49 421 200 3103        >   > > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> > >>>> netmod mailing list > >>>> > >>>> netmod@ietf.org > > >> > >>>> > >>>> https://www.ietf.org/mailman/listinfo/netmod > > > > >>>> > >>> > >>>> _______________________________________________ > >>>> 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 > > > > >> Mahesh Jethanandani > >> mjethanandani@gmail.com > >> > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf --------------5BC41D1C223CB253F73D2AE4 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit

Hi Andy,


On 07/02/2018 02:33, Andy Bierman wrote:


On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
For folks that provided comments as part of LC, please verify that your comments have been adequately addressed by -03 version of the draft.



Most comments have been addressed.


    The "with-defaults" parameter does not apply when interacting with an 
        operational datastore.


There is no explanation of why the with-defaults parameter does not apply to <operational>.
This is confusing. The solution that has been a standard for years still applies to
all datastores, except a completely different mechanism (origin-filter) is used instead
for 1 datastore.

If the server code can identify a default so it can be tagged origin=or:default, then it can
also support with-defaults.

I prefer the sentence above be changed, so that a server MAY implement with-defaults
for <operational>.  If the client sends <with-defaults> it should be OK to honor it instead
of returning an error.
I have two concerns with changing this to a MAY:

(1) The most useful "with-defaults" behavior differs for <operational> vs the configuration datastores, but with-defaults only allows a single standard behavior to be specified.

E.g. for configuration datastores the most appropriate semantics (if the client doesn't explicitly ask for something else) is "explicit". i.e. you give back exactly what was put in.

But, for operational, the most appropriate semantics (if the client doesn't explicitly ask for something else) is something like "report-all", i.e. the device reports the precise current state including any defaults.  However, we felt that this would return too much unnecessary data, hence why the datastore architecture defines "in-use" data, allowing the server to prune out any data that is clearly irrelevant.

(2) <operational> is a new datastore.  I personally don't want each server choosing how the data is returned, which requires that clients must handle all variants.  It would be better for the draft to specify the standard semantics to use unless a client has explicitly requested something else.

I'm not opposed to a "with-defaults-bis", or a new draft covering "with-defaults" for <operational>", but I think that:
(i) We shouldn't delay the NMDA protocol drafts for this, this can be done as separate draft adding extra optional functionality.
(ii) The semantics for retrieving data from operational (or notifications) should be as defined by "in-use" in the NMDA architecture, unless a client has explicitly specified, or configured, a different behavior.
(iii) Probably the only existing option defined in "with-defaults" that makes sense for <operational> is a variant of "trim" that is specified to return what is defined as returning the "in-use" values, but also excluding any values that match a default value specified in the schema.

Thanks,
Rob




Andy


 
Thanks

Mahesh Jethanandani
mjethanandani@gmail.com

> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Hi,
>
> Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
>> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.
>>
>> As part of the LC, there were a couple of comments/questions
>> raised. In particular
>>
>> - Vladmir reported an error, which Martin said is fixed in his local copy.
>
> Fixed.
>
>> - Robert suggested that “/yang-library/checksum†should be a
>>  reference. Juergen supported that comment, so I am assuming that
>>  that will be incorporated into the draft.
>
> Yes, fixed.
>
>> - Andy had questions around datastore set to “conventionalâ€
>
> Fixed.
>
>>  , about origin filter limited to 1 source
>
> Fixed.
>
>>  and the behavior of with-defaults.
>
> There were no additional changes to the document from the discussion
> about this.
>
>>  I see some discussion around it with the authors
>>  agreeing that some of them need some text clarifying the
>>  position. Can the authors please post the suggested text/additions
>>  for the WG to review.
>> - Anything else??
>>
>> Once an updated draft has been posted, I will do a writeup on the
>> drafts and send it to IESG.
>
> The issues above are now addressed, in
> draft-ietf-netconf-nmda-netconf-03.
>
> There were no additional comments on
> draft-ietf-netconf-nmda-restconf-02, so I believe this version is
> ready.
>
>
> /martin
>
>
>>
>> Thanks.
>>
>>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>
>>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote:
>>>>
>>>> I do have one additional thought below on draft-ietf-netmod-revised-datastores section 5.3 default handling process.  See in-line...
>>>>
>>>
>>> Well, this document is with the RFC editor now. I do not think it needs
>>> clarification. It already has text in 5.3 such as:
>>>
>>>  Requests to retrieve nodes from <operational> always return the value
>>>  in use if the node exists, regardless of any default value specified
>>>  in the YANG module.  If no value is returned for a given node, then
>>>  this implies that the node is not used by the device.
>>>
>>> /js
>>>
>>>> From: Robert Wilton -X, January 31, 2018 6:31 AM
>>>>
>>>>
>>>> Hi Andy,
>>>>
>>>> On 31/01/2018 09:22, Andy Bierman wrote:
>>>>
>>>>
>>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de><mailto:j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de>>> wrote:
>>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
>>>>> Hi,
>>>>>
>>>>> I have some questions about these drafts.
>>>>>
>>>>> 1) what if datastore set to "conventional"?
>>>>>   There are many places where a datastore-ref type is used.
>>>>>   However, "conventional" is valid for base "datastore", even though
>>>>>   it is ambiguous as a datastore selector.
>>>>
>>>> We can add explicit text that an identity that does not resolve to a
>>>> datastore implemented by the server results in an invalid value error.
>>>>
>>>>
>>>> OK
>>>>
>>>>
>>>>> 2) origin filter is limited to 1 source
>>>>>  This filtering seems rather limited.  A client must retrieve
>>>>> <with-origin> and check
>>>>>   all the values in use, then make repeated requests for each source as a
>>>>> different
>>>>>   <origin-filter> leaf
>>>>
>>>> If the client does <with-origin>, then it has all origin information
>>>> and it can filter locally. That said, we could make origin-filter a
>>>> leaf-list which is logically ORed so that one can retrieve
>>>> origin-filter=or:system or origin-filter=or:learned in one request.
>>>>
>>>>
>>>> OK
>>>>
>>>>> 3) with-defaults broken
>>>>>   The operational datastore does not support with-defaults.
>>>>>    Instead, the client must use origin-filter=or:default or with-origin
>>>>>    and check all the origin attributes.  Since a client needs to use
>>>>>    with-defaults for other datastores, this special handling of
>>>>> <operational>
>>>>>    seems unhelpful.
>>>>
>>>> I think the with-defaults semantics for conventional configuration
>>>> datastores are much more complicated than necessary for the
>>>> operational state datastore. Note that that the operational state
>>>> datastore reports in-use values not really defaults:
>>>>
>>>> <leaf or:origin='default'>foo</leaf>
>>>>
>>>> This reports that the value 'foo' is in use and that it originates
>>>> from a default value. Note that this could also be
>>>>
>>>> <leaf or:origin='intended'>foo</leaf>
>>>>
>>>> in case the intended configuration datastore configured the value
>>>> 'foo' (despite this value matching the default). The with-defaults
>>>> solution is pretty complex because it tries to handle how different
>>>> systems deal with configuration defaults. The idea is to not carry
>>>> this complexity over to in-use values in the operational state
>>>> datastore.
>>>>
>>>>
>>>> Before NMDA, the client could decide if it wanted to retrieve default nodes or not.
>>>> This client-choice has been removed from NMDA, which is a problem.
>>>> We tried to reach a sensible compromise on the data returned from operational (defined in section 5.3 of the NMDA architecture):
>>>> - it should return explicit values for everything that is affecting the actual running state of the device (regardless of whether the operational value matches a schema default value).
>>>> - it does not need to, and should not, return operational values for stuff that isn't actually in use, i.e. don't return needless and unwanted data.
>>>>
>>>> In particular, if no value is returned from a particular data node in <operational> then, barring mgmt protocol errors, a client can assume that any functionality associated with that data node is off (i.e. not in use).
>>>>
>>>> Some examples to illustrate the behavior:
>>>>
>>>> (i) If a protocol, e.g. OSPF,  is not enabled/running then <operational> does not need to return any data for it.  It would be reasonable to return a flag to indicate that OSPF is not enabled/running.
>>>>
>>>> (ii) If you have some funky widget on an interface that defaults to being off and isn't being used then <operational> don't need to return any data for it.
>>>>
>>>> (iii) But, if you have some funky widget on an interface that defaults to being on, then the server should return data for it. If it is actually enabled, then it would indicate that it is on and return any associated values with its operational state, or if it is disabled then it should explicitly report that it is off.
>>>>
>>>> (iv) I would regard that all applied configuration is "in use" by the system, even if it matches the default value, and hence it should be reported.
>>>>
>>>>
>>>> This behavior for <operational> is obviously slightly different from the existing with-default handling that is supported for configuration datastores.  As I recall, there were a couple of reasons that we decided to have a different behavior for <operational>:
>>>> (a) to have consistent semantics for all servers, rather than different servers supporting different with-defaults behaviors (which makes life harder for clients because they must cope with all variants).
>>>> (b) to remove any potential ambiguity if data isn't returned.  I.e. with the existing with-defaults semantics it is not clear to me that servers will always return an explicit value to indicate that a particular widget is off if the schema defines that the default it that is enabled.  If the server doesn't support a given widget at all, it is quite plausible that it will just return no data for it.  In theory features/deviations should handle this, but those don't work so well if different linecards have different capabilities.  Hence being explicit about stuff that is in use seems more robust.
>>>>
>>>> <eric> These are good examples.  It would be great if section 5.3 could be tweaked to make clearer the relationship between running datastore defaults and other operational datastore defaults for the same tree.
>>>>
>>>> For example, let’s say I create a configured subscription, and the default transport protocol is NETCONF.  NETCONF will be used for that subscription even though the node might not be populated.  In this case, the object would not appear in the running datastore, but MUST* appear in the operational datastore with the default origin (as it is in-use).
>>>>
>>>> This to me is the desired behavior as it doesn’t incorrectly add information to the running datastore, but shows what is in-use within operational.   I suspect other such relationships for other operational tree defaults could be asserted, perhaps based on the origin.
>>>>
>>>> (* Maybe ‘MUST eventually’, as obviously there is a temporal relationship between the two datastores.)
>>>>
>>>> Eric
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> /js
>>>>
>>>> Andy
>>>>
>>>> --
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> netmod mailing list
>>>>
>>>> netmod@ietf.org <mailto:netmod@ietf.org><mailto:netmod@ietf.org <mailto:netmod@ietf.org>>
>>>>
>>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>>>>
>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/netmod <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         <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>

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



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

--------------5BC41D1C223CB253F73D2AE4-- From nobody Wed Feb 7 03:41:49 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6B21126C0F for ; Wed, 7 Feb 2018 03:41:47 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M3WBQVcXGNEU for ; Wed, 7 Feb 2018 03:41:46 -0800 (PST) Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29B3A124235 for ; Wed, 7 Feb 2018 03:41:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2509; q=dns/txt; s=iport; t=1518003705; x=1519213305; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=odSoqQslCIZWxpxNSVZanHdBHOkvzlZnmqD/XntpeHk=; b=i3h3ajFVi3F2R7zbNt29Mg6as/KI6AnNWM4+gG4hSowQ5ATdDn/W1cdE Fhv79XIaHtH46PyMYqOUN5y/unXUC7o3WIiGQB42UFm+n8MGrq5TNEQH4 tk/tMbtoEERd0KoEeAJLlQ43BFTLIJNgUna+2UPwFKHYb/VWil/oTGrLN w=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAm5Xpa/xbLJq1aAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEN3Aog2WLGI8MJ5lqChgLhElPAoM/FAECAQEBAQEBAmsohSM?= =?us-ascii?q?BAQEDAQEBIQ8BBTYZAgsQCAICJgICGwwwBgEMBgIBAYopCBCxfYInhQCDeIIKA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFgQqDZoNsghEMgnmDLwEBAoIQJoJQgmU?= =?us-ascii?q?FpCkJlXqMOIgGj3OIF4E8NiKBUDMaCBsVPYJGhHdBN44WAQEB?= X-IronPort-AV: E=Sophos;i="5.46,473,1511827200"; d="scan'208";a="1916102" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2018 11:41:43 +0000 Received: from [10.63.23.78] (dhcp-ensft1-uk-vla370-10-63-23-78.cisco.com [10.63.23.78]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w17Bfg8d030143; Wed, 7 Feb 2018 11:41:43 GMT To: Ladislav Lhotka , netmod@ietf.org References: <20180206141655.6iast3lbhubk6rk5@elstar.local> <3f3f9984-0797-1ded-ded4-17543382f628@cisco.com> <20180207094845.ift6vhoomsp4d7kk@elstar.local> <20180207.111441.1066018064701748797.mbj@tail-f.com> <1517999361.22328.33.camel@nic.cz> From: Robert Wilton Message-ID: <93a100e4-146a-122d-0848-9a7a43e0c1f2@cisco.com> Date: Wed, 7 Feb 2018 11:41:42 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <1517999361.22328.33.camel@nic.cz> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 11:41:48 -0000 On 07/02/2018 10:29, Ladislav Lhotka wrote: > On Wed, 2018-02-07 at 11:14 +0100, Martin Bjorklund wrote: >> Juergen Schoenwaelder wrote: >>> On Tue, Feb 06, 2018 at 03:25:52PM +0000, Robert Wilton wrote: >>>> I think that the term "external" could also be confusing, since I think >>>> that >>>> sort of implies peer mount like semantics. >>> The "inline" mount concept seems to subsume peer mounts. From the >>> model perspective, is there a difference whether the mounted data is >>> local or remote (and what does local/remove mean for a VM)? >>> >>>> I would suggest the term "dynamic" instead of "inline " but that could >>>> easily be confused with dynamic datastores. >>> Yes, I think this is not a good word either. >>> >>>> Perhaps rather than "inline" another choice could be "discoverable", i.e. >>>> the schema is not known, and is dynamically discoverable inline at the >>>> mount >>>> point. >>>> Equally, rather than "use-schema", perhaps a better choice would be >>>> "known", >>>> i.e. the schema is already known, and made available as part of YANG >>>> library. >>> Perhaps integrated schema vs. mounted schema. >> I like the term "integrated" better than "use-schema". But both cases >> are mounted, so we need another term than "mounted" for "inline". >> "segregated" doesn't sound quite right ;-) > I would prefer to use the term "mount" only for the inline case and find > something else for the use-schema case. The term "mount" evokes that some > *instance* data being added, which is what happens in the "inline" case but not > for "use-schema". Perhaps the "use-schema" case really is a type of "schema mount", where as the "inline" case is a type of "mount". Perhaps they could/should have entirely separate YANG models to describe them.  Possibly in the "use-schema" case could refer to grafting a schema into a parent schema rather than mounting it. Thanks, Rob > > Lada > >> >> /martin >> >>>> Whether it would be right to change these at this time, I've no idea ... >>> Yep. >>> >>> /js >>> >>> -- >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany >>> Fax: +49 421 200 3103 >>> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Feb 7 03:56:14 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEE7124235 for ; Wed, 7 Feb 2018 03:56:13 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cDZUAFTXQzxy for ; Wed, 7 Feb 2018 03:56:11 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1321126CE8 for ; Wed, 7 Feb 2018 03:56:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=550; q=dns/txt; s=iport; t=1518004571; x=1519214171; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=OhvUaHUayrHmfl6JDzFijWdwiJBySmNiXX8neogg8po=; b=hhZyGcY7hAYmtwCq43kZK+MQR+Gaw/Tw5RSlPx1211ZOqsj4ieSS8zS+ eeALjztVWGMDYZcrJpZfZcwYLBv4rO4JJHP8RU8eVFg94738jyn2flFV5 +xs7ft7p2W06aU7Gc9VTL1IVSsGfOwORh1KXOBUY4/lTA1RLKr2ix5mep k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQCE6Hpa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUnhA2LGI8MmhEKhTEKAoM/FAECAQEBAQEBAmsohSQGIxVRCxo?= =?us-ascii?q?CJgICVwYBDAgBAYoxshGCJ4UAg3iCCgEBAQEBAQEDAQEBAQEBIoEPg2aDbIIRD?= =?us-ascii?q?IJ5iDmCZQEEpCkJlXqCBYoziAaPc4gXgTw2IoFQMxoIGxWDBIR3QI5NAQEB?= X-IronPort-AV: E=Sophos;i="5.46,473,1511827200"; d="scan'208";a="1864273" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2018 11:56:09 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w17Bu8Ij015367; Wed, 7 Feb 2018 11:56:08 GMT To: "t.petch" , Henrik Levkowetz , NETMOD Working Group References: <26131545-049c-9a1a-eb2b-cdad6fce3190@cisco.com> <036201d39c25$7bb5a060$4001a8c0@gateway.2wire.net> From: Benoit Claise Message-ID: Date: Wed, 7 Feb 2018 12:56:08 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <036201d39c25$7bb5a060$4001a8c0@gateway.2wire.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Missing references X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 11:56:13 -0000 Hi Henrik, Could this check be added to idnits? Regards, Benoit > I just came across (yet) another example of a reference to an RFC in a > description clause of a YANG module that appears nowhere else in the > I-D. > > This seems to be a systematic error that some YANG module authors make; > can the tools be modified to pick it up? The logic is simple enough. > > The latest example is in draft-ietf-rtgwg-yang-rip-09 which fails to > reference RFC5952; I think that the I-D is in the RFC Editor queue. > > Tom Petch > > . > From nobody Wed Feb 7 04:18:37 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ACCAC129C6F for ; Wed, 7 Feb 2018 04:18:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1WKd9msv05WJ for ; Wed, 7 Feb 2018 04:18:29 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 363DA124205 for ; Wed, 7 Feb 2018 04:18:29 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:9001:c4ff:fe87:6c8]) by mail.nic.cz (Postfix) with ESMTPSA id EB5B162469; Wed, 7 Feb 2018 13:18:26 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1518005907; bh=DkXPsHUNaGX1KFASmaUiamIUWPP/riru5k3PQtDffGo=; h=From:To:Date; b=uRfsVXAkgWQYYxyZGixSE8uSeq80XdvwRNjRzrQNk86wVolAJnUVkoyMUmxdr2BYK BOlwCqJfYHw9H+hYGuyzdAq9RvVgMPTZaL9GXIAS8PBlQmnd7BgoWid3ZM/F3jmKDe vVCtbziXjqlE2OIbsLD/DXJkm8DmsqU2DhzCazEY= Message-ID: <1518005906.22328.69.camel@nic.cz> From: Ladislav Lhotka To: Robert Wilton , netmod@ietf.org Date: Wed, 07 Feb 2018 13:18:26 +0100 In-Reply-To: <93a100e4-146a-122d-0848-9a7a43e0c1f2@cisco.com> References: <20180206141655.6iast3lbhubk6rk5@elstar.local> <3f3f9984-0797-1ded-ded4-17543382f628@cisco.com> <20180207094845.ift6vhoomsp4d7kk@elstar.local> <20180207.111441.1066018064701748797.mbj@tail-f.com> <1517999361.22328.33.camel@nic.cz> <93a100e4-146a-122d-0848-9a7a43e0c1f2@cisco.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 12:18:37 -0000 On Wed, 2018-02-07 at 11:41 +0000, Robert Wilton wrote: > > On 07/02/2018 10:29, Ladislav Lhotka wrote: > > On Wed, 2018-02-07 at 11:14 +0100, Martin Bjorklund wrote: > > > Juergen Schoenwaelder wrote: > > > > On Tue, Feb 06, 2018 at 03:25:52PM +0000, Robert Wilton wrote: > > > > > I think that the term "external" could also be confusing, since I > > > > > think > > > > > that > > > > > sort of implies peer mount like semantics. > > > > > > > > The "inline" mount concept seems to subsume peer mounts. From the > > > > model perspective, is there a difference whether the mounted data is > > > > local or remote (and what does local/remove mean for a VM)? > > > > > > > > > I would suggest the term "dynamic" instead of "inline " but that could > > > > > easily be confused with dynamic datastores. > > > > > > > > Yes, I think this is not a good word either. > > > > > > > > > Perhaps rather than "inline" another choice could be "discoverable", > > > > > i.e. > > > > > the schema is not known, and is dynamically discoverable inline at the > > > > > mount > > > > > point. > > > > > Equally, rather than "use-schema", perhaps a better choice would be > > > > > "known", > > > > > i.e. the schema is already known, and made available as part of YANG > > > > > library. > > > > > > > > Perhaps integrated schema vs. mounted schema. > > > > > > I like the term "integrated" better than "use-schema". But both cases > > > are mounted, so we need another term than "mounted" for "inline". > > > "segregated" doesn't sound quite right ;-) > > > > I would prefer to use the term "mount" only for the inline case and find > > something else for the use-schema case. The term "mount" evokes that some > > *instance* data being added, which is what happens in the "inline" case but > > not > > for "use-schema". > > Perhaps the "use-schema" case really is a type of "schema mount", where > as the "inline" case is a type of "mount". This may be quite confusing. My suggestion for "use-schema" is "external augment" - the mount point as a *schema node* plays a very similar role to the target node of an augment. > > Perhaps they could/should have entirely separate YANG models to describe > them. Possibly in the "use-schema" case could refer to grafting a > schema into a parent schema rather than mounting it. I proposed this previously. The inline case could in fact be considerably simplified because the extension statement is all that's needed - no state data. In other words, the "mount-point" extension would immediately indicate the inline mount. In order to distinguish the use-schema case (or whatever we call it) we have then two options: 1. use a different YANG extension for labelling mount points of this type 2. use schema node identifiers as in augments (i.e. no extension at all). Thanks, Lada > > Thanks, > Rob > > > > > > Lada > > > > > > > > /martin > > > > > > > > Whether it would be right to change these at this time, I've no idea > > > > > ... > > > > > > > > Yep. > > > > > > > > /js > > > > > > > > -- > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > Fax: +49 421 200 3103 > > > > > > > > > > _______________________________________________ > > > netmod mailing list > > > netmod@ietf.org > > > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 7 04:27:22 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A0D34129516 for ; Wed, 7 Feb 2018 04:27:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PiHsGuhxa3Tv for ; Wed, 7 Feb 2018 04:27:18 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id A55581241FC for ; Wed, 7 Feb 2018 04:27:18 -0800 (PST) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 938ED1AE03F5; Wed, 7 Feb 2018 13:27:16 +0100 (CET) Date: Wed, 07 Feb 2018 13:27:16 +0100 (CET) Message-Id: <20180207.132716.1275264246183208833.mbj@tail-f.com> To: lhotka@nic.cz Cc: rwilton@cisco.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <1518005906.22328.69.camel@nic.cz> References: <1517999361.22328.33.camel@nic.cz> <93a100e4-146a-122d-0848-9a7a43e0c1f2@cisco.com> <1518005906.22328.69.camel@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: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 12:27:21 -0000 Hi, It seems we're now just reiterating what has previously been discussed *a lot*. IMO, highest prio is to resolve any issues related to YLbis. If we also need other clarifications to make the document easier to understand, that's fine. But I don't think we should fundamentally change the solution that the WG agreed upon. /martin Ladislav Lhotka wrote: > On Wed, 2018-02-07 at 11:41 +0000, Robert Wilton wrote: > > > > On 07/02/2018 10:29, Ladislav Lhotka wrote: > > > On Wed, 2018-02-07 at 11:14 +0100, Martin Bjorklund wrote: > > > > Juergen Schoenwaelder wrote: > > > > > On Tue, Feb 06, 2018 at 03:25:52PM +0000, Robert Wilton wrote: > > > > > > I think that the term "external" could also be confusing, since I > > > > > > think > > > > > > that > > > > > > sort of implies peer mount like semantics. > > > > > > > > > > The "inline" mount concept seems to subsume peer mounts. From the > > > > > model perspective, is there a difference whether the mounted data is > > > > > local or remote (and what does local/remove mean for a VM)? > > > > > > > > > > > I would suggest the term "dynamic" instead of "inline " but that could > > > > > > easily be confused with dynamic datastores. > > > > > > > > > > Yes, I think this is not a good word either. > > > > > > > > > > > Perhaps rather than "inline" another choice could be "discoverable", > > > > > > i.e. > > > > > > the schema is not known, and is dynamically discoverable inline at the > > > > > > mount > > > > > > point. > > > > > > Equally, rather than "use-schema", perhaps a better choice would be > > > > > > "known", > > > > > > i.e. the schema is already known, and made available as part of YANG > > > > > > library. > > > > > > > > > > Perhaps integrated schema vs. mounted schema. > > > > > > > > I like the term "integrated" better than "use-schema". But both cases > > > > are mounted, so we need another term than "mounted" for "inline". > > > > "segregated" doesn't sound quite right ;-) > > > > > > I would prefer to use the term "mount" only for the inline case and find > > > something else for the use-schema case. The term "mount" evokes that some > > > *instance* data being added, which is what happens in the "inline" case but > > > not > > > for "use-schema". > > > > Perhaps the "use-schema" case really is a type of "schema mount", where > > as the "inline" case is a type of "mount". > > This may be quite confusing. My suggestion for "use-schema" is "external > augment" - the mount point as a *schema node* plays a very similar role to the > target node of an augment. > > > > > Perhaps they could/should have entirely separate YANG models to describe > > them. Possibly in the "use-schema" case could refer to grafting a > > schema into a parent schema rather than mounting it. > > I proposed this previously. The inline case could in fact be considerably > simplified because the extension statement is all that's needed - no state data. > In other words, the "mount-point" extension would immediately indicate the > inline mount. > > In order to distinguish the use-schema case (or whatever we call it) we have > then two options: > > 1. use a different YANG extension for labelling mount points of this type > > 2. use schema node identifiers as in augments (i.e. no extension at all). > > Thanks, Lada > > > > > Thanks, > > Rob > > > > > > > > > > Lada > > > > > > > > > > > /martin > > > > > > > > > > Whether it would be right to change these at this time, I've no idea > > > > > > ... > > > > > > > > > > Yep. > > > > > > > > > > /js > > > > > > > > > > -- > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > > > > Fax: +49 421 200 3103 > > > > > > > > > > > > > _______________________________________________ > > > > netmod mailing list > > > > netmod@ietf.org > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > -- > Ladislav Lhotka > Head, CZ.NIC Labs > PGP Key ID: 0xB8F92B08A9F76C67 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Wed Feb 7 04:49:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8C5E127058 for ; Wed, 7 Feb 2018 04:49:07 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -7.01 X-Spam-Level: X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VHn7FhlzTBTG for ; Wed, 7 Feb 2018 04:49:04 -0800 (PST) Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C5E41241FC for ; Wed, 7 Feb 2018 04:49:03 -0800 (PST) Received: from birdie (unknown [IPv6:2001:1488:fffe:6:9001:c4ff:fe87:6c8]) by mail.nic.cz (Postfix) with ESMTPSA id F402C62430 for ; Wed, 7 Feb 2018 13:49:00 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1518007741; bh=dAqjfY02vVXwSInyNUcOB9pIsgEgvtwwICupHYZj5iA=; h=From:To:Date; b=Wb7rrd0kfwQYkjSKgoo+n1yU01ez0Iyqd9jsUCREy49W20oMiaMJ+uEj4kHPmpLC4 L+ZqC8RnFBkJRfJaNqZM+CYJciUQqvI/JV3TdZEBKGfTwqnW+ty23u3dIY+NFXCV8u a1flMl0ECEqlXMyre+BcRrZcj0aMyV81wIOXErGo= Message-ID: <1518007740.22328.88.camel@nic.cz> From: Ladislav Lhotka To: NETMOD WG Date: Wed, 07 Feb 2018 13:49:00 +0100 In-Reply-To: <20180207.132716.1275264246183208833.mbj@tail-f.com> References: <1517999361.22328.33.camel@nic.cz> <93a100e4-146a-122d-0848-9a7a43e0c1f2@cisco.com> <1518005906.22328.69.camel@nic.cz> <20180207.132716.1275264246183208833.mbj@tail-f.com> Organization: CZ.NIC Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5 Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Virus-Scanned: clamav-milter 0.99.2 at mail X-Virus-Status: Clean Archived-At: Subject: Re: [netmod] schema-mount pre09 branch X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 12:49:08 -0000 On Wed, 2018-02-07 at 13:27 +0100, Martin Bjorklund wrote: > Hi, > > It seems we're now just reiterating what has previously been discussed > *a lot*. IMO, highest prio is to resolve any issues related to YLbis. I've always missed a technical merit in those discussions. It has always been like "I prefer that solution", "This is not how our implementation works", "It is good enough for LNE/NI" etc. But maybe I missed something so please point me to discussions that demonstrate why the adopted solution is better than what I am proposing. I am arguing that it is exactly the other way around. The inline and use-schema cases are different concepts and mixing them together makes the whole thing needlessly complex to describe and understand. > If we also need other clarifications to make the document easier to > understand, that's fine. But I don't think we should fundamentally > change the solution that the WG agreed upon. I don't agree that we are *strongly* changing the solution. Simplifications and clarifications are IMO badly needed. Lada > > > /martin > > > > Ladislav Lhotka wrote: > > On Wed, 2018-02-07 at 11:41 +0000, Robert Wilton wrote: > > > > > > On 07/02/2018 10:29, Ladislav Lhotka wrote: > > > > On Wed, 2018-02-07 at 11:14 +0100, Martin Bjorklund wrote: > > > > > Juergen Schoenwaelder wrote: > > > > > > On Tue, Feb 06, 2018 at 03:25:52PM +0000, Robert Wilton wrote: > > > > > > > I think that the term "external" could also be confusing, since I > > > > > > > think > > > > > > > that > > > > > > > sort of implies peer mount like semantics. > > > > > > > > > > > > The "inline" mount concept seems to subsume peer mounts. From the > > > > > > model perspective, is there a difference whether the mounted data is > > > > > > local or remote (and what does local/remove mean for a VM)? > > > > > > > > > > > > > I would suggest the term "dynamic" instead of "inline " but that > > could > > > > > > > easily be confused with dynamic datastores. > > > > > > > > > > > > Yes, I think this is not a good word either. > > > > > > > > > > > > > Perhaps rather than "inline" another choice could be > > "discoverable", > > > > > > > i.e. > > > > > > > the schema is not known, and is dynamically discoverable inline at > > the > > > > > > > mount > > > > > > > point. > > > > > > > Equally, rather than "use-schema", perhaps a better choice would > > be > > > > > > > "known", > > > > > > > i.e. the schema is already known, and made available as part of > > YANG > > > > > > > library. > > > > > > > > > > > > Perhaps integrated schema vs. mounted schema. > > > > > > > > > > I like the term "integrated" better than "use-schema". But both cases > > > > > are mounted, so we need another term than "mounted" for "inline". > > > > > "segregated" doesn't sound quite right ;-) > > > > > > > > I would prefer to use the term "mount" only for the inline case and find > > > > something else for the use-schema case. The term "mount" evokes that > > some > > > > *instance* data being added, which is what happens in the "inline" case > > but > > > > not > > > > for "use-schema". > > > > > > Perhaps the "use-schema" case really is a type of "schema mount", where > > > as the "inline" case is a type of "mount". > > > > This may be quite confusing. My suggestion for "use-schema" is "external > > augment" - the mount point as a *schema node* plays a very similar role to > > the > > target node of an augment. > > > > > > > > Perhaps they could/should have entirely separate YANG models to describe > > > them. Possibly in the "use-schema" case could refer to grafting a > > > schema into a parent schema rather than mounting it. > > > > I proposed this previously. The inline case could in fact be considerably > > simplified because the extension statement is all that's needed - no state > > data. > > In other words, the "mount-point" extension would immediately indicate the > > inline mount. > > > > In order to distinguish the use-schema case (or whatever we call it) we have > > then two options: > > > > 1. use a different YANG extension for labelling mount points of this type > > > > 2. use schema node identifiers as in augments (i.e. no extension at all). > > > > Thanks, Lada > > > > > > > > Thanks, > > > Rob > > > > > > > > > > > > > > Lada > > > > > > > > > > > > > > /martin > > > > > > > > > > > > Whether it would be right to change these at this time, I've no > > idea > > > > > > > ... > > > > > > > > > > > > Yep. > > > > > > > > > > > > /js > > > > > > > > > > > > -- > > > > > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > > > > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > Germany > > > > > > Fax: +49 421 200 3103 > > > > > > > > > > > > > > > > _______________________________________________ > > > > > netmod mailing list > > > > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod > > > > > > > > > > -- > > Ladislav Lhotka > > Head, CZ.NIC Labs > > PGP Key ID: 0xB8F92B08A9F76C67 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Wed Feb 7 05:01:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92CD0126579 for ; Wed, 7 Feb 2018 05:00:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.902 X-Spam-Level: X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KhYp0JLCmBUH for ; Wed, 7 Feb 2018 05:00:56 -0800 (PST) Received: from EUR03-VE1-obe.outbound.protection.outlook.com (mail-eopbgr50135.outbound.protection.outlook.com [40.107.5.135]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BE03126C22 for ; Wed, 7 Feb 2018 05:00:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=scxFwctFoBV9Dp+hyUvaEf93RAsiIsB1tRgt87xfEOM=; b=J5A0acqaA4MlkVVIv4MGXKq4Or2e8n/vZSp/9anhNOE2gtZ2++3kN3TxnTrDEVMjBzs7jWL8Ai5sz6Md+avdU4Smw/qwmeuE58/fyXt9ABzDRx5Kf8JBO2H+S2tD1r+2aK+bzzm/bg3vhG1e6/3CbR+6y1eMmm6CZQRBnboUEq0= Received: from pc6 (86.169.153.236) by HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Wed, 7 Feb 2018 13:00:52 +0000 Message-ID: <01f501d3a013$72e66180$4001a8c0@gateway.2wire.net> From: "t.petch" To: "NETMOD Working Group" , "Andy Bierman" References: <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com> <6BAC6B11-90A9-4CA1-AE53-FFAC084FB76E@juniper.net> <5c2ae0a9-b4b9-3d13-395e-1c779f99f941@cisco.com> Date: Wed, 7 Feb 2018 12:58:46 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.169.153.236] X-ClientProxiedBy: CWXP265CA0052.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:2c::16) To HE1PR0701MB3002.eurprd07.prod.outlook.com (2603:10a6:3:4d::8) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 1f268032-ac76-4709-9f8b-08d56e2ad1f7 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 3:l6WW3yhnGTfnuvjHD2uJVfaWxf3sADLuxiHIGu3QmW65CCENlyQlUzzCE6XNivYLXy4Og3LdC6c4mFgY+h4LyYNR//e1K/8J3oMPV+C8xZ8aFpJR//38peUk2x236Jyym82Pxih+t4Kap5GbBVQhfdcqmP1qGZJHvST5NYheKyMT7emK2GfIiGTR7rHE/IwnnDhRgFUdvLJiQDhv5FETTdBkMVa7zteFJU8BYO6pxKHpMFyWDiyBRoVahkh0TLFC; 25:WOc8odLg3jBZvA0AJ99d4pnKk+8zJvJGmN/uWCpBQm1DHOYRePvLClkpSz8BPGRTAAmYxYumPHtVxAinMqi8UsI2PctTf7rDRe10nN4v5f8TLjt2RLtAlEV8J/eo90dbaKAPGYQR7YojqHlwr63nFMqctBFycXhV477n8uNzy6rWv91ZXJrX8wVNDR+4rqdUbAMiV4sOT3xoWo/Mf75+GGchu3y7s0xtXHimm3obYOiUiFtRohumnHwcaXq+8HTDCdzr07JV6EAs03/uY+TrQdT2F7nCtGn4HsEZfI8ndTb5YwQiCITveQxVjMGEOsB/POiY9kWktTFXYb4HRaqqHQ==; 31:ZZ4jMnt1WQOzjEOQNfc4Le5aP9kNGlguV++ghTHzQTbN81rABTAZHivhYvfl11MWpT7SW7tUacCF24DBeuY0DOqL5Y9zqTImPPpIiswJzVAKssZCEpKoZ+hWSco6itfWyH0n+HPelNUOd4g219krKYp0NLzakUpHa9wvtfXmmdyyALCW5D9u9I3XIPaduiIr2irgp73oEvfI4B+UUlcq645YFYpfazPd3YVvUcqmvVc= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3002: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(3231101)(2400082)(944501161)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:HE1PR0701MB3002; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3002; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 4:yz1efGpPHFS0c+Y3OExZzi1W+evuadnxlOjIAM3pL5uU/PLWpoZmNhDLi/1hH4zo005tuPUndGioSwHqnfeHIEXo7ERgghxel0QDezjzC84Jz8A/4DmIrReK103OUXOTIsww4abQHIrnyaG4h4PXIGO+5k17odEIiUSjVGDID2VL3iLGwN5uyTHBQ257sXuuoNtd75UcxNhYO0sDvrDqCXN2FBp2Ikl21cRbCiRTcLjfICYgLLvStwOFwrb+Q5Mp3mfuNZ3cNSNu6oy0rkd3aQ== X-Forefront-PRVS: 0576145E86 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(39860400002)(346002)(366004)(396003)(376002)(189003)(199004)(44736005)(44716002)(386003)(558084003)(81686011)(8676002)(186003)(53936002)(81816011)(7736002)(110136005)(68736007)(84392002)(33896004)(76176011)(6486002)(16526019)(26005)(2906002)(106356001)(9686003)(62236002)(105586002)(61296003)(97736004)(50466002)(6346003)(4743002)(6666003)(316002)(478600001)(3846002)(6116002)(5660300001)(230700001)(66066001)(1556002)(25786009)(4720700003)(86362001)(14496001)(81156014)(93886005)(81166006)(8936002)(23676004)(2486003)(47776003)(52116002)(305945005)(50226002)(6496006)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3002; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDI7MjM6cENBU0tkQWw2VzFydElxalo1bkhlYjQz?= =?utf-8?B?V3lKYmZlakNqWTBvUWVoNG56TDNTUUVSODJDVzR6OHZDY2ZIdlFRMnhVYm1O?= =?utf-8?B?MGRkQ0Z1eGRPVC9GRTNxQUpVNEp2UXdtYk0vVmNNWGJRdHlEeWcwOUhmdjQ2?= =?utf-8?B?bWlkbVMwT1ZuM20xdFdXeW9hYXVJclJ3WnlHVnJrYmV0L1RYWGVmblhsYUd0?= =?utf-8?B?Q2VxMklRMTB2cFZxZDdlZFF2RkR5cXBGaFM0S1FuRUJaN0JqMk1hWitwRGVm?= =?utf-8?B?L3d6V0ZpRVA5Zjd6S29JZDBGeDN5UitHN1pQd0NzOWNLOFpsaWd4ZFByM1Rk?= =?utf-8?B?UXQ5citTa0ptTjgyUWtjSVNEejNaUkR1Snl3c2s5MXVjZURPSnpCUHlML2VW?= =?utf-8?B?TEZvK21rcEdXNGd1RURyU1lNVWQrVFNjZytPQTl1eFBjbW81MXZMaXhDZis1?= =?utf-8?B?SlhxZTlONS9vMTdTc1ZxcjhtYkRnMWREemhTdXY0elJMV05WYzZNNS9ZRjJt?= =?utf-8?B?ejRFMkhZcWd4M3dmVzEzNC9jUVF2d3U3UFRqT09TSEpFSlpES1l6ekMvRG9R?= =?utf-8?B?RTQ0aUdKRzZMMStDRFMwejI3MHRCWS85bWMreHdGQTVaOFllNnNURVdSQlVW?= =?utf-8?B?SUZOcU0veThTN0tiTmZMOGNuNGdSczQzTjhCNEx0ZjkxQ2NoTEtnbTc0RG1W?= =?utf-8?B?L1F3Nk9qUjF3NlNIVG9xNTl1c0x0TzRpQWw3ZUFJSS9jbU95MHQ2RmR0L3ph?= =?utf-8?B?R3NVeEV4K1R5Z3E2Uml1L01VdWNTQ3ZjQWpwekd2WVB6K1F0VDZKcnBKeFJi?= =?utf-8?B?Y29KYkxEYzVjNHc2RVh2UllXMkdNVHhObkVSNDUvL2tQVGFadldYV1JYUWlo?= =?utf-8?B?T0RpRm9CS0VWY3QzNVEwbDRUZ2EveFJ4cUVpd3FUMHlDN1N5emdYNnN1dzI3?= =?utf-8?B?bGhsTkpRbnFMbFYzam12djB4TmkxdlRhYlNqRTlaNkpNbGFBa09WWUorY2JG?= =?utf-8?B?bmVqMndmVWU3Sld3RUhhMnQwSkw3a01ZMVg1MGxrMWZ6aDdwUWZnR2o1cnll?= =?utf-8?B?eVNpajQ2UDBFQkJ6aU4wUUxHR2J4LzJ1VStQYTRabmlZOUpVa2VaQnVLOU5I?= =?utf-8?B?TmdOVkVWdzRxYW1zZUZNWHNtMlAwQStJTkFZMHllVTRSWkI5dTJYcmhzV2tF?= =?utf-8?B?M0hpWU0yOFJuUERoZEphOXRHOVppTVpUcmprQ09EOEFubFUrOEZJTnhNQldq?= =?utf-8?B?dFh1akhnUFg4WkIzeWR3TUxpY1Q5L3BkWFNpc3FhYzFMa3FmbmFvamF2NE5E?= =?utf-8?B?SUMzV0xRTGZnNDV1WnV6VU4zTlZKeTFReGg1ZGlndmNDTmhwdWovVHUreVlE?= =?utf-8?B?WXlzZU0rZ0tVSGduQnZBL3d3bjFOL3FoQzRQTThWZW1FcHN5VU1kWTVsaVA3?= =?utf-8?B?a2dvOG5Kd1Y5RDROSzloM051cEFSaHhyTGVtVlVrcVhIUmx2b1BsSlkzVis0?= =?utf-8?B?ODlEUFlaTzZlVzJOZjNmN0RldWtDSUs5N3RDb3FJMDJsN1ZtcUxrUjMxS3dS?= =?utf-8?B?UllLWkl6c3c1c1NNRHZnb0dnV0ZOQlE0MnBlbGhUVWNrVHp4STdzVVlXbW1a?= =?utf-8?B?SVZleEI2QjRVckpyeGFBZmk0N3F2NTJyM0J4ZC82TzlNZGtHRS9hcnhYbWZE?= =?utf-8?B?T2pzamdER2pXa2V0QVRWb21TYVFGMExIN0ZPRS82K2ZJZE4rQmFxaWMzeVNS?= =?utf-8?B?VzFlck9weHF3SWJtNkovKzV2TUZKMTJGQ3ZlcWQ1QW51ZTFPNURSVkpNM3Rh?= =?utf-8?B?WXlsNUc0Y0crVGVrSHhxRjBNRnIyUmw5YmJYQ28yK1N2VWhYZXQwM2kxUDNq?= =?utf-8?Q?z4TYvZ4oq+9SXofndfEGUgCejsy2SX605H?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3002; 6:HjaPc7k708rlwJh3x/56u2fLn/2dJQxVt6B+pyxjZy3+bjPhu9OREpn5L4AqgRzYf/C1tZ5f1g3BPoOXeE9qAgreeDLeTriNAp9E20vsznC+qqo0v9ma3q0XhcK6HAuXg4vpC+PQ94YSFwi5jCjv2Go/pMjjjdn1uFLIj3VjMGfQ5yW2evhWBWzO3dD6MMoAyaN5lB26CSoIX+yn1NMMaIXTeGQAHrNloJKgYfZgh/JdGO3rURLYwTsLJiPVZoZqeVy30cQrJj/TiCAK8CvJ+xuPg9MTKHb6JP60Nql05+6pxgB0ulqowQAEppG2wdIwOzIfcO+MoNA5XIDMloza36DrXtgILY2OOSnIkhRmLes=; 5:/9+xG3WBiyCs7XfvKen6BQBLKJFek6Ub4Qh8LbHSyQsCrsrC61sHFGxf41ZW6Z0egAUaBUBRG36ngVIKsxAfsmsg0STqp6RjdrDr+G5rw1tliQ2uKSEJVHhUOJ2wWDoxDKT9rZTgk+Iigb5phBr7LN/ut2vxxPHTSfQc1ZWCKvw=; 24:4TrdzTGpchQiAq+Wkbloa2iG7L/MtzZ8cq2Xdx3LsVMk6mT1RjzcDTgUfHF5QcWR3ZWJ8+SGi2Sw+s571rjRBUoPh0P8ZKVR4+y9jOl9Fd4=; 7:XqcrlpDkNKyMnZp3JRyCdGhlzOzciRX7ra0m4T/4O2QrX3wixzV7CUcaXL9r5eBqGO3mZwCppZScxxyaHYjNUKcDRQQLv8uTFehbrer6ceFCh23h2jyFMDyC32vktcWviJqqsesZGrywUOk5eA9TES1tDRpjB/t4v5OD4BD8UCTb5McTRRKl0YMYPH48Zd+t5Eg8W2s+mcCJ3qxjWAI8M3RqEJMALaWtZeyM3AV4mVFS2oHhRn4D0dR6xwxnmJ3P SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2018 13:00:52.9860 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 1f268032-ac76-4709-9f8b-08d56e2ad1f7 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3002 Archived-At: Subject: [netmod] draft-ietf-netmod-rfc6087bis-16 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 13:00:59 -0000 Andy If an RFC is mentioned in a Description clause, should it also appear in the related Reference clause? draft-ietf-dhc-dhcpv6-yang-05 has examples of this not being the case, as I mention in a recent post. I assumed that they should be but cannot see any discussion of this in RFC6087bis Tom Petch From nobody Wed Feb 7 05:53:46 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7E5CB129C6C for ; Wed, 7 Feb 2018 05:53:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ps5M0X7OCGOB for ; Wed, 7 Feb 2018 05:53:41 -0800 (PST) Received: from Mail2.SpriteLink.NET (Mail2.SpriteLink.NET [195.182.5.83]) by ietfa.amsl.com (Postfix) with ESMTP id C82E71200FC for ; Wed, 7 Feb 2018 05:53:40 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by Mail2.SpriteLink.NET (Postfix) with ESMTP id C926F2619D8; Wed, 7 Feb 2018 14:53:42 +0100 (CET) X-Virus-Scanned: amavisd-new at SpriteLink.NET Received: from Mail2.SpriteLink.NET ([195.182.5.83]) by localhost (Mail2.SpriteLink.NET [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K0Wg7TxQluxA; Wed, 7 Feb 2018 14:53:40 +0100 (CET) Received: from Kristians-MacBook-Pro.local (c-1789e455.014-82-73746f13.cust.bredbandsbolaget.se [85.228.137.23]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: kristian@spritelink.net) by Mail2.SpriteLink.NET (Postfix) with ESMTPSA id 663112618F1; Wed, 7 Feb 2018 14:53:40 +0100 (CET) To: Mahesh Jethanandani Cc: netmod@ietf.org References: <151762118030.14613.16606991699665016537@ietfa.amsl.com> <37914E8C-1A57-4ECF-A865-D8880169F454@gmail.com> <84f42879-1a49-d023-3a62-afbbcb53d73e@spritelink.net> <256632EC-30B7-4353-8B88-045F652432E2@gmail.com> From: Kristian Larsson Message-ID: <28a59fe5-b39c-4535-0cd4-5ca820cf4a6b@spritelink.net> Date: Wed, 7 Feb 2018 14:56:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <256632EC-30B7-4353-8B88-045F652432E2@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-acl-model-16.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 13:53:44 -0000 On 2018-02-06 19:36, Mahesh Jethanandani wrote: > Kristian, > > As I commented on the PR, putting the ‘container’ inside of the ‘choice’ statement allows me to collapse the ‘container’ and the ‘case’ statement into a single ‘container’ statement. With your changes, I see an additional ‘case’ statement, bloating the model in four places. You are right and I see how you have moved the container from the types module. I think I was thrown off by making assumption on how things looked in my branch of the model rather than inspecting your history. The original issue that I disliked here is that you have a container named source-port-range-or-operator which I think is a good name for a choice statement in the schema tree but is a horrible name for a node in the data tree. It should simply be "source-port". Can we please fix that? I did place my containers and choice statements the other way around for even when we use a object reference I imagined that it would be under the source-port container, thus having that at the top makes sense. This is less important though, if we want to repeat that through the object reference augmentations that's fine. Kristian. > > Cheers. > >> On Feb 6, 2018, at 1:42 AM, Kristian Larsson wrote: >> >> Mahesh, >> >> I suppose, since you posted the update Friday night, that I missed my chance of prettifying the source/destination port choice/container structure that was just added. If not, it's in a PR towards your repo - https://github.com/mjethanandani/acl-model/pull/4 >> >> Kind regards, >> Kristian. >> >> >> >> On 2018-02-03 02:41, Mahesh Jethanandani wrote: >>> This update addresses the comments that were received as part of LC. For those of you who commented on the draft during the LC, please verify that your comments have been addressed. >>> Thanks. >>>> On Feb 2, 2018, at 5:26 PM, internet-drafts@ietf.org wrote: >>>> >>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories. >>>> This draft is a work item of the Network Modeling WG of the IETF. >>>> >>>> Title : Network Access Control List (ACL) YANG Data Model >>>> Authors : Mahesh Jethanandani >>>> Lisa Huang >>>> Sonal Agarwal >>>> Dana Blair >>>> Filename : draft-ietf-netmod-acl-model-16.txt >>>> Pages : 54 >>>> Date : 2018-02-02 >>>> >>>> Abstract: >>>> This document describes a data model of Access Control List (ACL) >>>> basic building blocks. >>>> >>>> Editorial Note (To be removed by RFC Editor) >>>> >>>> This draft contains many placeholder values that need to be replaced >>>> with finalized values at the time of publication. This note >>>> summarizes all of the substitutions that are needed. Please note >>>> that no other RFC Editor instructions are specified anywhere else in >>>> this document. >>>> >>>> Artwork in this document contains shorthand references to drafts in >>>> progress. Please apply the following replacements >>>> >>>> o "XXXX" --> the assigned RFC value for this draft both in this >>>> draft and in the YANG models under the revision statement. >>>> >>>> o Revision date in model needs to get updated with the date the >>>> draft gets approved. The date also needs to get reflected on the >>>> line with . >>>> >>>> >>>> The IETF datatracker status page for this draft is: >>>> https://datatracker.ietf.org/doc/draft-ietf-netmod-acl-model/ >>>> >>>> There are also htmlized versions available at: >>>> https://tools.ietf.org/html/draft-ietf-netmod-acl-model-16 >>>> https://datatracker.ietf.org/doc/html/draft-ietf-netmod-acl-model-16 >>>> >>>> A diff from the previous version is available at: >>>> https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-acl-model-16 >>>> >>>> >>>> Please note that it may take a couple of minutes from the time of submission >>>> until the htmlized version and diff are available at tools.ietf.org. >>>> >>>> Internet-Drafts are also available by anonymous FTP at: >>>> ftp://ftp.ietf.org/internet-drafts/ >>>> >>>> _______________________________________________ >>>> netmod mailing list >>>> netmod@ietf.org >>>> https://www.ietf.org/mailman/listinfo/netmod >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>> _______________________________________________ >>> 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 > > Mahesh Jethanandani > mjethanandani@gmail.com > From nobody Wed Feb 7 06:23:42 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E58712DA44 for ; Wed, 7 Feb 2018 06:23:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eF_0C5ug_Ddm for ; Wed, 7 Feb 2018 06:23:27 -0800 (PST) Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 2B6FC12DA41 for ; Wed, 7 Feb 2018 06:23:27 -0800 (PST) Received: by mail-lf0-x234.google.com with SMTP id q194so1566895lfe.13 for ; Wed, 07 Feb 2018 06:23:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=xO3kkaTe6Uczy1M37i1x8WJzhxXR772o4+uKCgSgMJ4=; b=MiRCMEtoqO7x+8DwgfucYW8Px9/VRpTebFHH0fnuDUKWeEv0vHm5WECA4XcOJsnfXw RgxFqptFCSCPl2S5S4fol5jFgi3DByKxQkUfRNoK0peqrNBHmM4wt9MFCKX0qPFBipY8 eowuZLer+L6Rru8VDBpdjforlX4jVpfkp4vZkaCWDxTaDIl5/tEhKrpHgcG5FO/3/uXx RworQjnzQQ3sl7AAkTXteDLk+YGE+fnFxAVRtcF0o8YHuRc49bxsaI5s5/XikWebK0Jf n3EbmkxJwEahiihSqnzxVszVHjfkeURXzNYAA/dKtvifBREd1ooq7Hz4ZzHLxR9nM1Vt 147g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=xO3kkaTe6Uczy1M37i1x8WJzhxXR772o4+uKCgSgMJ4=; b=QKR+OTesOvV7GZZpT8F69iHAiKA1s1IvX54ZhwKPfrEawFQ+qWMBDOD3xH8rZeWnH6 5gowGjocl+i50nCfDIcjzxXrVhS1P2Dn3j6EQatezVsXONwjadPJ6EkkSN5nQg+FQdIx xlwcvzc1iqPh/08jCTcMyfnggIarHWQnhapCac/2qq2/FHzkmoMlX4HdzOeHli2FkbA2 YrNuPxaTXGcq+XJP8WfQq3Sj4HAuHXUmBrHp7bb+lpTKD8y1vpeCJgNrSoztDoNlBsZc hKMab7AdKcDCqQi7Gs2IPd91ZUyEGJ+BQiUpDjY0v+oplc0IDeBBSp5bJHzxrMTApcd8 8rmA== X-Gm-Message-State: APf1xPD1zfS4HAbpy/IUez+UOElTXXBPjizJm+aA/NF92pqdGBHIuWfs LJk7fecqPVrtiAWHR4xnX8IWYJjV2bB0MupoG/uCew== X-Google-Smtp-Source: AH8x225KaRk8YWq70tt1TU6S+GiTXQWS/WozaeGxc+wSWJ64TKTkAjUaImD3LSzeRQsoMMIOE9b/QNNTIKR8b6VGSMs= X-Received: by 10.25.20.168 with SMTP id 40mr4519709lfu.23.1518013403882; Wed, 07 Feb 2018 06:23:23 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.143.6 with HTTP; Wed, 7 Feb 2018 06:23:22 -0800 (PST) In-Reply-To: <8d90fd4c-711a-1b90-529b-778f81e80bf5@cisco.com> References: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com> <20180131181619.ziqdv5peqdeeuhl4@elstar.local> <20180205.184312.338993520253253388.mbj@tail-f.com> <39203004-C003-4C07-A376-006B6F7969D6@gmail.com> <8d90fd4c-711a-1b90-529b-778f81e80bf5@cisco.com> From: Andy Bierman Date: Wed, 7 Feb 2018 06:23:22 -0800 Message-ID: To: Robert Wilton Cc: Mahesh Jethanandani , Netconf , NetMod WG Content-Type: multipart/alternative; boundary="001a113fb118b3feb60564a00994" Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 14:23:37 -0000 --001a113fb118b3feb60564a00994 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton wrote: > Hi Andy, > > On 07/02/2018 02:33, Andy Bierman wrote: > > > > On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > >> For folks that provided comments as part of LC, please verify that your >> comments have been adequately addressed by -03 version of the draft. >> >> > > Most comments have been addressed. > > > The "with-defaults" parameter does not apply when interacting with an > > operational datastore. > > > There is no explanation of why the with-defaults parameter does not apply > to . > This is confusing. The solution that has been a standard for years still > applies to > all datastores, except a completely different mechanism (origin-filter) i= s > used instead > for 1 datastore. > > If the server code can identify a default so it can be tagged > origin=3Dor:default, then it can > also support with-defaults. > > I prefer the sentence above be changed, so that a server MAY implement > with-defaults > for . If the client sends it should be OK t= o > honor it instead > of returning an error. > > I have two concerns with changing this to a MAY: > > (1) The most useful "with-defaults" behavior differs for vs > the configuration datastores, but with-defaults only allows a single > standard behavior to be specified. > > E.g. for configuration datastores the most appropriate semantics (if the > client doesn't explicitly ask for something else) is "explicit". i.e. you > give back exactly what was put in. > > But, for operational, the most appropriate semantics (if the client > doesn't explicitly ask for something else) is something like "report-all"= , > i.e. the device reports the precise current state including any defaults. > However, we felt that this would return too much unnecessary data, hence > why the datastore architecture defines "in-use" data, allowing the server > to prune out any data that is clearly irrelevant. > > (2) is a new datastore. I personally don't want each serve= r > choosing how the data is returned, which requires that clients must handl= e > all variants. It would be better for the draft to specify the standard > semantics to use unless a client has explicitly requested something else. > > I'm not opposed to a "with-defaults-bis", or a new draft covering > "with-defaults" for ", but I think that: > (i) We shouldn't delay the NMDA protocol drafts for this, this can be don= e > as separate draft adding extra optional functionality. > (ii) The semantics for retrieving data from operational (or notifications= ) > should be as defined by "in-use" in the NMDA architecture, unless a clien= t > has explicitly specified, or configured, a different behavior. > (iii) Probably the only existing option defined in "with-defaults" that > makes sense for is a variant of "trim" that is specified to > return what is defined as returning the "in-use" values, but also excludi= ng > any values that match a default value specified in the schema. > > I think your approach violates the Postel Principle. "Be liberal in what you accept" is about robustness. Rejecting parameters for no good reason is about fragility. I never said change the behavior for if no is present. If the parameter is provided it is trivial for the server to honor it. The most useful value (report-all) is the default, not leave out all defaults, like . > Thanks, > Rob > > > Andy > > > Andy > > > > >> Thanks >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund wrote: >> > >> > Hi, >> > >> > Mahesh Jethanandani wrote: >> >> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF. >> >> >> >> As part of the LC, there were a couple of comments/questions >> >> raised. In particular >> >> >> >> - Vladmir reported an error, which Martin said is fixed in his local >> copy. >> > >> > Fixed. >> > >> >> - Robert suggested that =E2=80=9C/yang-library/checksum=E2=80=9D shou= ld be a >> >> reference. Juergen supported that comment, so I am assuming that >> >> that will be incorporated into the draft. >> > >> > Yes, fixed. >> > >> >> - Andy had questions around datastore set to =E2=80=9Cconventional=E2= =80=9D >> > >> > Fixed. >> > >> >> , about origin filter limited to 1 source >> > >> > Fixed. >> > >> >> and the behavior of with-defaults. >> > >> > There were no additional changes to the document from the discussion >> > about this. >> > >> >> I see some discussion around it with the authors >> >> agreeing that some of them need some text clarifying the >> >> position. Can the authors please post the suggested text/additions >> >> for the WG to review. >> >> - Anything else?? >> >> >> >> Once an updated draft has been posted, I will do a writeup on the >> >> drafts and send it to IESG. >> > >> > The issues above are now addressed, in >> > draft-ietf-netconf-nmda-netconf-03. >> > >> > There were no additional comments on >> > draft-ietf-netconf-nmda-restconf-02, so I believe this version is >> > ready. >> > >> > >> > /martin >> > >> > >> >> >> >> Thanks. >> >> >> >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de> wrote: >> >>> >> >>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote: >> >>>> >> >>>> I do have one additional thought below on >> draft-ietf-netmod-revised-datastores section 5.3 default handling >> process. See in-line... >> >>>> >> >>> >> >>> Well, this document is with the RFC editor now. I do not think it >> needs >> >>> clarification. It already has text in 5.3 such as: >> >>> >> >>> Requests to retrieve nodes from always return the val= ue >> >>> in use if the node exists, regardless of any default value specifie= d >> >>> in the YANG module. If no value is returned for a given node, then >> >>> this implies that the node is not used by the device. >> >>> >> >>> /js >> >>> >> >>>> From: Robert Wilton -X, January 31, 2018 6:31 AM >> >>>> >> >>>> >> >>>> Hi Andy, >> >>>> >> >>>> On 31/01/2018 09:22, Andy Bierman wrote: >> >>>> >> >>>> >> >>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder < >> j.schoenwaelder@jacobs-university.de > -university.de>> j.schoenwaelder@jacobs-university.de>>> wrote: >> >>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: >> >>>>> Hi, >> >>>>> >> >>>>> I have some questions about these drafts. >> >>>>> >> >>>>> 1) what if datastore set to "conventional"? >> >>>>> There are many places where a datastore-ref type is used. >> >>>>> However, "conventional" is valid for base "datastore", even thou= gh >> >>>>> it is ambiguous as a datastore selector. >> >>>> >> >>>> We can add explicit text that an identity that does not resolve to = a >> >>>> datastore implemented by the server results in an invalid value >> error. >> >>>> >> >>>> >> >>>> OK >> >>>> >> >>>> >> >>>>> 2) origin filter is limited to 1 source >> >>>>> This filtering seems rather limited. A client must retrieve >> >>>>> and check >> >>>>> all the values in use, then make repeated requests for each >> source as a >> >>>>> different >> >>>>> leaf >> >>>> >> >>>> If the client does , then it has all origin informatio= n >> >>>> and it can filter locally. That said, we could make origin-filter a >> >>>> leaf-list which is logically ORed so that one can retrieve >> >>>> origin-filter=3Dor:system or origin-filter=3Dor:learned in one requ= est. >> >>>> >> >>>> >> >>>> OK >> >>>> >> >>>>> 3) with-defaults broken >> >>>>> The operational datastore does not support with-defaults. >> >>>>> Instead, the client must use origin-filter=3Dor:default or >> with-origin >> >>>>> and check all the origin attributes. Since a client needs to u= se >> >>>>> with-defaults for other datastores, this special handling of >> >>>>> >> >>>>> seems unhelpful. >> >>>> >> >>>> I think the with-defaults semantics for conventional configuration >> >>>> datastores are much more complicated than necessary for the >> >>>> operational state datastore. Note that that the operational state >> >>>> datastore reports in-use values not really defaults: >> >>>> >> >>>> foo >> >>>> >> >>>> This reports that the value 'foo' is in use and that it originates >> >>>> from a default value. Note that this could also be >> >>>> >> >>>> foo >> >>>> >> >>>> in case the intended configuration datastore configured the value >> >>>> 'foo' (despite this value matching the default). The with-defaults >> >>>> solution is pretty complex because it tries to handle how different >> >>>> systems deal with configuration defaults. The idea is to not carry >> >>>> this complexity over to in-use values in the operational state >> >>>> datastore. >> >>>> >> >>>> >> >>>> Before NMDA, the client could decide if it wanted to retrieve >> default nodes or not. >> >>>> This client-choice has been removed from NMDA, which is a problem. >> >>>> We tried to reach a sensible compromise on the data returned from >> operational (defined in section 5.3 of the NMDA architecture): >> >>>> - it should return explicit values for everything that is affecting >> the actual running state of the device (regardless of whether the >> operational value matches a schema default value). >> >>>> - it does not need to, and should not, return operational values fo= r >> stuff that isn't actually in use, i.e. don't return needless and unwante= d >> data. >> >>>> >> >>>> In particular, if no value is returned from a particular data node >> in then, barring mgmt protocol errors, a client can assume >> that any functionality associated with that data node is off (i.e. not i= n >> use). >> >>>> >> >>>> Some examples to illustrate the behavior: >> >>>> >> >>>> (i) If a protocol, e.g. OSPF, is not enabled/running then >> does not need to return any data for it. It would be >> reasonable to return a flag to indicate that OSPF is not enabled/running= . >> >>>> >> >>>> (ii) If you have some funky widget on an interface that defaults to >> being off and isn't being used then don't need to return a= ny >> data for it. >> >>>> >> >>>> (iii) But, if you have some funky widget on an interface that >> defaults to being on, then the server should return data for it. If it i= s >> actually enabled, then it would indicate that it is on and return any >> associated values with its operational state, or if it is disabled then = it >> should explicitly report that it is off. >> >>>> >> >>>> (iv) I would regard that all applied configuration is "in use" by >> the system, even if it matches the default value, and hence it should be >> reported. >> >>>> >> >>>> >> >>>> This behavior for is obviously slightly different fro= m >> the existing with-default handling that is supported for configuration >> datastores. As I recall, there were a couple of reasons that we decided= to >> have a different behavior for : >> >>>> (a) to have consistent semantics for all servers, rather than >> different servers supporting different with-defaults behaviors (which ma= kes >> life harder for clients because they must cope with all variants). >> >>>> (b) to remove any potential ambiguity if data isn't returned. I.e. >> with the existing with-defaults semantics it is not clear to me that >> servers will always return an explicit value to indicate that a particul= ar >> widget is off if the schema defines that the default it that is enabled. >> If the server doesn't support a given widget at all, it is quite plausib= le >> that it will just return no data for it. In theory features/deviations >> should handle this, but those don't work so well if different linecards >> have different capabilities. Hence being explicit about stuff that is i= n >> use seems more robust. >> >>>> >> >>>> These are good examples. It would be great if section 5.3 >> could be tweaked to make clearer the relationship between running datast= ore >> defaults and other operational datastore defaults for the same tree. >> >>>> >> >>>> For example, let=E2=80=99s say I create a configured subscription, = and the >> default transport protocol is NETCONF. NETCONF will be used for that >> subscription even though the node might not be populated. In this case, >> the object would not appear in the running datastore, but MUST* appear i= n >> the operational datastore with the default origin (as it is in-use). >> >>>> >> >>>> This to me is the desired behavior as it doesn=E2=80=99t incorrectl= y add >> information to the running datastore, but shows what is in-use within >> operational. I suspect other such relationships for other operational >> tree defaults could be asserted, perhaps based on the origin. >> >>>> >> >>>> (* Maybe =E2=80=98MUST eventually=E2=80=99, as obviously there is a= temporal >> relationship between the two datastores.) >> >>>> >> >>>> Eric >> >>>> >> >>>> Thanks, >> >>>> Rob >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> /js >> >>>> >> >>>> Andy >> >>>> >> >>>> -- >> >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >> Germany >> >>>> Fax: +49 421 200 3103 >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> >> >>>> netmod mailing list >> >>>> >> >>>> netmod@ietf.org > > >> >>>> >> >>>> https://www.ietf.org/mailman/listinfo/netmod < >> https://www.ietf.org/mailman/listinfo/netmod> >> >>>> >> >>> >> >>>> _______________________________________________ >> >>>> netmod mailing list >> >>>> netmod@ietf.org >> >>>> https://www.ietf.org/mailman/listinfo/netmod < >> https://www.ietf.org/mailman/listinfo/netmod> >> >>> >> >>> >> >>> -- >> >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >> >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germa= ny >> >>> Fax: +49 421 200 3103 > https://www.jacobs-university.de/>> >> >>> >> >>> _______________________________________________ >> >>> netmod mailing list >> >>> netmod@ietf.org >> >>> https://www.ietf.org/mailman/listinfo/netmod < >> https://www.ietf.org/mailman/listinfo/netmod> >> >> Mahesh Jethanandani >> >> mjethanandani@gmail.com >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > > > _______________________________________________ > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo= /netconf > > > --001a113fb118b3feb60564a00994 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton <rwilton@cisco.com&g= t; wrote:
=20 =20 =20

Hi Andy,


On 07/02/2018 02:33= , Andy Bierman wrote:
=20


On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
For folks tha= t provided comments as part of LC, please verify that your comments have been adequately addressed by -03 version of the draft.



Most comments have been addressed.


    The =
"with-defaults" parameter does not apply when interacting with an=
=C2=A0
=C2= =A0 =C2=A0 =C2=A0 =C2=A0 operational datastore.


There is no explanation of why the with-defaults parameter does not apply to <operational>.
This is confusing. The solution that has been a standard for years still applies to
all datastores, except a completely different mechanism (origin-filter) is used instead
for 1 datastore.

If the server code can identify a default so it can be tagged origin=3Dor:default, then it can
also support with-defaults.

I prefer the sentence above be changed, so that a server MAY implement with-defaults
for <operational>.=C2=A0 If the client sends <with-defaults> it should be OK to honor it instead
of returning an error.
I have two concerns with changing this to a MAY:

(1) The most useful "with-defaults" behavior differs for <operational> vs the configuration datastores, but with-defaults only allows a single standard behavior to be specified.

E.g. for configuration datastores the most appropriate semantics (if the client doesn't explicitly ask for something else) is "expl= icit". i.e. you give back exactly what was put in.

But, for operational, the most appropriate semantics (if the client doesn't explicitly ask for something else) is something like "report-all", i.e. the device reports the precise current sta= te including any defaults.=C2=A0 However, we felt that this would return t= oo much unnecessary data, hence why the datastore architecture defines "in-use" data, allowing the server to prune out any data that= is clearly irrelevant.

(2) <operational> is a new datastore.=C2=A0 I personally don'= t want each server choosing how the data is returned, which requires that clients must handle all variants.=C2=A0 It would be better for the draf= t to specify the standard semantics to use unless a client has explicitly requested something else.

I'm not opposed to a "with-defaults-bis", or a new draft = covering "with-defaults" for <operational>", but I think th= at:
(i) We shouldn't delay the NMDA protocol drafts for this, this can be done as separate draft adding extra optional functionality.
(ii) The semantics for retrieving data from operational (or notifications) should be as defined by "in-use" in the NMDA architecture, unless a client has explicitly specified, or configured, a different behavior.
(iii) Probably the only existing option defined in "with-defaults&= quot; that makes sense for <operational> is a variant of "trim&quo= t; that is specified to return what is defined as returning the "in-use&qu= ot; values, but also excluding any values that match a default value specified in the schema.



I think your = approach violates the Postel Principle.
"Be liberal in what = you accept" is about robustness.
Rejecting parameters for no= good reason is about fragility.

I never said chan= ge the behavior for <operational> if no <with-defaults> is pres= ent.
If the parameter is provided it is trivial for the server to= honor it.
The most useful value (report-all) is the default, not= leave out all defaults, like <get-config>.

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


=C2=A0
Thanks

Mahesh Jethanandani
= mjethanandani@gmail.com

> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Hi,
>
> Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
>> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.
>>
>> As part of the LC, there were a couple of comments/questions
>> raised. In particular
>>
>> - Vladmir reported an error, which Martin said is fixed in his local copy.
>
> Fixed.
>
>> - Robert suggested that =E2=80=9C/yang-library/check= sum=E2=80=9D should be a
>>=C2=A0 reference. Juergen supported that comment, so = I am assuming that
>>=C2=A0 that will be incorporated into the draft.
>
> Yes, fixed.
>
>> - Andy had questions around datastore set to =E2=80=9Cconventional=E2=80=9D
>
> Fixed.
>
>>=C2=A0 , about origin filter limited to 1 source
>
> Fixed.
>
>>=C2=A0 and the behavior of with-defaults.
>
> There were no additional changes to the document from the discussion
> about this.
>
>>=C2=A0 I see some discussion around it with the autho= rs
>>=C2=A0 agreeing that some of them need some text clarifying the
>>=C2=A0 position. Can the authors please post the suggested text/additions
>>=C2=A0 for the WG to review.
>> - Anything else??
>>
>> Once an updated draft has been posted, I will do a writeup on the
>> drafts and send it to IESG.
>
> The issues above are now addressed, in
> draft-ietf-netconf-nmda-netconf-03.
>
> There were no additional comments on
> draft-ietf-netconf-nmda-restconf-02, so I believe this version is
> ready.
>
>
> /martin
>
>
>>
>> Thanks.
>>
>>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>
>>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote:
>>>>
>>>> I do have one additional thought below on draft-ietf-netmod-revised-datastores section 5.3 default handling process.=C2=A0 See in-line...
>>>>
>>>
>>> Well, this document is with the RFC editor now. I do not think it needs
>>> clarification. It already has text in 5.3 such as:
>>>
>>>=C2=A0 Requests to retrieve nodes from <operational> always return the value
>>>=C2=A0 in use if the node exists, regardless of a= ny default value specified
>>>=C2=A0 in the YANG module.=C2=A0 If no value is r= eturned for a given node, then
>>>=C2=A0 this implies that the node is not used by the device.
>>>
>>> /js
>>>
>>>> From: Robert Wilton -X, January 31, 2018 6:31 AM
>>>>
>>>>
>>>> Hi Andy,
>>>>
>>>> On 31/01/2018 09:22, Andy Bierman wrote:
>>>>
>>>>
>>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de>&l= t;mailto:j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de>&g= t;> wrote:
>>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
>>>>> Hi,
>>>>>
>>>>> I have some questions about these drafts.
>>>>>
>>>>> 1) what if datastore set to "conventional"?
>>>>>=C2=A0 =C2=A0There are many places where = a datastore-ref type is used.
>>>>>=C2=A0 =C2=A0However, "conventional&= quot; is valid for base "datastore", even though
>>>>>=C2=A0 =C2=A0it is ambiguous as a datasto= re selector.
>>>>
>>>> We can add explicit text that an identity that does not resolve to a
>>>> datastore implemented by the server results in an invalid value error.
>>>>
>>>>
>>>> OK
>>>>
>>>>
>>>>> 2) origin filter is limited to 1 source
>>>>>=C2=A0 This filtering seems rather limited.=C2=A0 A client must retrieve
>>>>> <with-origin> and check
>>>>>=C2=A0 =C2=A0all the values in use, then = make repeated requests for each source as a
>>>>> different
>>>>>=C2=A0 =C2=A0<origin-filter> leaf >>>>
>>>> If the client does <with-origin>, then it has all origin information
>>>> and it can filter locally. That said, we could make origin-filter a
>>>> leaf-list which is logically ORed so that one can retrieve
>>>> origin-filter=3Dor:system or origin-filter=3Dor:learned in one request.
>>>>
>>>>
>>>> OK
>>>>
>>>>> 3) with-defaults broken
>>>>>=C2=A0 =C2=A0The operational datastore do= es not support with-defaults.
>>>>>=C2=A0 =C2=A0 Instead, the client must us= e origin-filter=3Dor:default or with-origin
>>>>>=C2=A0 =C2=A0 and check all the origin attributes.=C2=A0 Since a client needs to use
>>>>>=C2=A0 =C2=A0 with-defaults for other datastores, this special handling of
>>>>> <operational>
>>>>>=C2=A0 =C2=A0 seems unhelpful.
>>>>
>>>> I think the with-defaults semantics for conventional configuration
>>>> datastores are much more complicated than necessary for the
>>>> operational state datastore. Note that that the operational state
>>>> datastore reports in-use values not really defaults:
>>>>
>>>> <leaf or:origin=3D'default'>foo</leaf>
>>>>
>>>> This reports that the value 'foo' is= in use and that it originates
>>>> from a default value. Note that this could also be
>>>>
>>>> <leaf or:origin=3D'intended'>f= oo</leaf>
>>>>
>>>> in case the intended configuration datastore configured the value
>>>> 'foo' (despite this value matching t= he default). The with-defaults
>>>> solution is pretty complex because it tries to handle how different
>>>> systems deal with configuration defaults. The idea is to not carry
>>>> this complexity over to in-use values in the operational state
>>>> datastore.
>>>>
>>>>
>>>> Before NMDA, the client could decide if it wanted to retrieve default nodes or not.
>>>> This client-choice has been removed from NMDA, which is a problem.
>>>> We tried to reach a sensible compromise on the data returned from operational (defined in section 5.3 of the NMDA architecture):
>>>> - it should return explicit values for everything that is affecting the actual running state of the device (regardless of whether the operational value matches a schema default value).
>>>> - it does not need to, and should not, return operational values for stuff that isn't actually i= n use, i.e. don't return needless and unwanted data.
>>>>
>>>> In particular, if no value is returned from a particular data node in <operational> then, barring mgmt protocol errors, a client can assume that any functionality associated with that data node is off (i.e. not in use).
>>>>
>>>> Some examples to illustrate the behavior: >>>>
>>>> (i) If a protocol, e.g. OSPF,=C2=A0 is not enabled/running then <operational> does not need to return any data for it.=C2=A0 It would be reasonable to retur= n a flag to indicate that OSPF is not enabled/running.
>>>>
>>>> (ii) If you have some funky widget on an interface that defaults to being off and isn't being used then <operational> don't need to return any data fo= r it.
>>>>
>>>> (iii) But, if you have some funky widget on an interface that defaults to being on, then the server should return data for it. If it is actually enabled, then it would indicate that it is on and return any associated values with its operational state, or if it is disabled then it should explicitly report that it is off.
>>>>
>>>> (iv) I would regard that all applied configuration is "in use" by the system, even if it matches the default value, and hence it should be reported.
>>>>
>>>>
>>>> This behavior for <operational> is obviously slightly different from the existing with-default handling that is supported for configuration datastores.=C2=A0 As I recall, there were a couple of reasons that we decided to have a different behavior for <operational>:
>>>> (a) to have consistent semantics for all servers, rather than different servers supporting different with-defaults behaviors (which makes life harder for clients because they must cope with all variants).
>>>> (b) to remove any potential ambiguity if data isn't returned.=C2=A0 I.e. with the existing with-de= faults semantics it is not clear to me that servers will always return an explicit value to indicate that a particular widget is off if the schema defines that the default it that is enabled.=C2=A0 If the server doesn't support a gi= ven widget at all, it is quite plausible that it will just return no data for it.=C2=A0 In theory features/deviations should handle this, but those don't work so well if different linecards have different capabilities.=C2=A0 Hence being explicit about stuff that is in use seems more robust.
>>>>
>>>> <eric> These are good examples.=C2=A0 = It would be great if section 5.3 could be tweaked to make clearer the relationship between running datastore defaults and other operational datastore defaults for the same tree.
>>>>
>>>> For example, let=E2=80=99s say I create a configured subscription, and the default transport protocol is NETCONF.=C2=A0 NETCONF will be used for that subscription even though the node might not be populated.=C2= =A0 In this case, the object would not appear in the running datastore, but MUST* appear in the operational datastore with the default origin (as it is in-use).
>>>>
>>>> This to me is the desired behavior as it doesn=E2=80=99t incorrectly add information to the running datastore, but shows what is in-use within operational.=C2=A0 =C2=A0I suspect other such relationships for other operationa= l tree defaults could be asserted, perhaps based on the origin.
>>>>
>>>> (* Maybe =E2=80=98MUST eventually=E2=80=99, = as obviously there is a temporal relationship between the two datastores.)
>>>>
>>>> Eric
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> /js
>>>>
>>>> Andy
>>>>
>>>> --
>>>> 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<https://www.jacobs-university.de/<= /a>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________= ________
>>>>
>>>> netmod mailing list
>>>>
>>>> netmod@ietf.org <mailto:netmod@ietf.org><mailto:netmod@ietf.org <mailto:netmod@ietf.org>>
>>>>
>>>> https://www.ietf.org/mail= man/listinfo/netmod <https://www.ietf.org/mailman/list= info/netmod>
>>>>
>>>
>>>> _______________________________________= ________
>>>> netmod mailing list
>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>>> https://www.ietf.org/mail= man/listinfo/netmod <https://www.ietf.org/mailman/list= info/netmod>
>>>
>>>
>>> --
>>> 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<https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>= ;
>>>
>>> ___________________________________________= ____
>>> netmod mailing list
>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>> https://www.ietf.org/mailman/= listinfo/netmod <https://www.ietf.org/mailman/list= info/netmod>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>

_______________________________________________
Netconf mailing list
Netconf= @ietf.org
https://www.ietf.org/mailman/listinf= o/netconf



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


--001a113fb118b3feb60564a00994-- From nobody Wed Feb 7 08:11:15 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 916EB12D7F2; Wed, 7 Feb 2018 08:11:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.51 X-Spam-Level: X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8SitHkZqmStY; Wed, 7 Feb 2018 08:11:09 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A42F9126FDC; Wed, 7 Feb 2018 08:11:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=63725; q=dns/txt; s=iport; t=1518019869; x=1519229469; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=rH5l5duM+bO0fwB2Mo0JSwdfs5GPPgHyJhP9L7Le1Lk=; b=UlcpICmEXvlM0355slCCoFRkjXU3xKuZJUkd8I2aYf0Ywg80PJjGjtNw 18lWiEPAWlHMjwfcVzeOo/HVUazIM5CJSblMv5TKOVicx2QE2EvzKcafb YAfWxOPF+SAMTkUs38oHFdu/bxcVeWRLrONX6LfgMnDR+zUvnDCAuWl+6 k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B4AQCoJHta/xbLJq1TAQYDGQEBAQEBA?= =?us-ascii?q?QEBAQEBAQcBAQEBAYJZR4EXcCiDZYsYjzSJFY5SggADChgBCoM6gQ9PAoNAFQE?= =?us-ascii?q?CAQEBAQEBAmsohSMBAQEDAQEBGAEISwQHBQkCCQIQAgMDDQwCBQEGAwICGwYGH?= =?us-ascii?q?wMOBgEMBgIBARUCigIDDQgQk3uddIInJoRagjkNgTGCCgEBAQEBAQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBARgFBYRwg2yBaCmBd4EOgmtEAQECgUQBAw8CNyYPB4I6gmUFmg0Xi?= =?us-ascii?q?VA1CZB0hQeCHoYng3OBZYYhjkKBMYgXgTw1I4FQMxoIGxU9gkaCHDkcggZBN3C?= =?us-ascii?q?KWQIlgiQBAQE?= X-IronPort-AV: E=Sophos;i="5.46,473,1511827200"; d="scan'208,217";a="1869143" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2018 16:11:05 +0000 Received: from [10.61.211.230] ([10.61.211.230]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w17GB3OI013816; Wed, 7 Feb 2018 16:11:04 GMT To: Andy Bierman , Netconf , NetMod WG References: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com> <20180131181619.ziqdv5peqdeeuhl4@elstar.local> <20180205.184312.338993520253253388.mbj@tail-f.com> <39203004-C003-4C07-A376-006B6F7969D6@gmail.com> <8d90fd4c-711a-1b90-529b-778f81e80bf5@cisco.com> From: Robert Wilton Message-ID: Date: Wed, 7 Feb 2018 16:11:03 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------F5F35C40BC2248EBC3AE89B0" Content-Language: en-US Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 16:11:14 -0000 This is a multi-part message in MIME format. --------------F5F35C40BC2248EBC3AE89B0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 07/02/2018 14:23, Andy Bierman wrote: > > > On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton > wrote: > > Hi Andy, > > > On 07/02/2018 02:33, Andy Bierman wrote: >> >> >> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani >> > wrote: >> >> For folks that provided comments as part of LC, please verify >> that your comments have been adequately addressed by -03 >> version of the draft. >> >> >> >> Most comments have been addressed. >> >> >> The "with-defaults" parameter does not apply when interacting with an >>       operational datastore. >> >> >> There is no explanation of why the with-defaults parameter does >> not apply to . >> This is confusing. The solution that has been a standard for >> years still applies to >> all datastores, except a completely different mechanism >> (origin-filter) is used instead >> for 1 datastore. >> >> If the server code can identify a default so it can be tagged >> origin=or:default, then it can >> also support with-defaults. >> >> I prefer the sentence above be changed, so that a server MAY >> implement with-defaults >> for .  If the client sends it should >> be OK to honor it instead >> of returning an error. > I have two concerns with changing this to a MAY: > > (1) The most useful "with-defaults" behavior differs for > vs the configuration datastores, but with-defaults > only allows a single standard behavior to be specified. > > E.g. for configuration datastores the most appropriate semantics > (if the client doesn't explicitly ask for something else) is > "explicit". i.e. you give back exactly what was put in. > > But, for operational, the most appropriate semantics (if the > client doesn't explicitly ask for something else) is something > like "report-all", i.e. the device reports the precise current > state including any defaults.  However, we felt that this would > return too much unnecessary data, hence why the datastore > architecture defines "in-use" data, allowing the server to prune > out any data that is clearly irrelevant. > > (2) is a new datastore.  I personally don't want > each server choosing how the data is returned, which requires that > clients must handle all variants.  It would be better for the > draft to specify the standard semantics to use unless a client has > explicitly requested something else. > > I'm not opposed to a "with-defaults-bis", or a new draft covering > "with-defaults" for ", but I think that: > (i) We shouldn't delay the NMDA protocol drafts for this, this can > be done as separate draft adding extra optional functionality. > (ii) The semantics for retrieving data from operational (or > notifications) should be as defined by "in-use" in the NMDA > architecture, unless a client has explicitly specified, or > configured, a different behavior. > (iii) Probably the only existing option defined in "with-defaults" > that makes sense for is a variant of "trim" that is > specified to return what is defined as returning the "in-use" > values, but also excluding any values that match a default value > specified in the schema. > > > > I think your approach violates the Postel Principle. > "Be liberal in what you accept" is about robustness. > Rejecting parameters for no good reason is about fragility. > > I never said change the behavior for if no > is present. > If the parameter is provided it is trivial for the server to honor it. > The most useful value (report-all) is the default, not leave out all > defaults, like . OK, so one option is to allow the "with-defaults" parameter for the datastore, but specify in both the NETCONF NMDA and RESTCONF NMDA drafts how "with-defaults" semantics apply to any operational datastore: 1) Regardless of what is reported in the "basic-mode" capability parameter, the default behavior for is "report-all", with semantics as described below: 2) "report-all" for operational datastores is defined as returning all "in use" values (i.e. as specified in section 5.3 of the NMDA architecture, so default values that are not "in use" are not returned). 3) "trim" for operational datastores is defined as returning all "in-use" values (... as 5.3) except that values that match the value specified in the schema "default" statement are omitted.  Note, clients cannot distinguish between a value that is omitted because it is not in use, vs a value that is omitted because it matches the schema default. 4) "explicit" for operational datastores is defined as returning the same as "report-all", defined above. 5) "report-all-tagged" for operational datastores is defined as returning the same as "report-all", except that all values that match the values specified in the schema "default" statement are tagged, as described in with-defaults (RFC 5243). Also note - there is no change in semantics or behavior to how "with-defaults" works for conventional datastores. Thoughts? Thanks, Rob > > Thanks, > Rob > > > > Andy > >> >> >> Andy >> >> >> Thanks >> >> Mahesh Jethanandani >> mjethanandani@gmail.com >> >> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund >> > wrote: >> > >> > Hi, >> > >> > Mahesh Jethanandani > > wrote: >> >> This closes the LC for the two NDMA drafts for NETCONF and >> RESTCONF. >> >> >> >> As part of the LC, there were a couple of comments/questions >> >> raised. In particular >> >> >> >> - Vladmir reported an error, which Martin said is fixed in >> his local copy. >> > >> > Fixed. >> > >> >> - Robert suggested that “/yang-library/checksum†should be a >> >>  reference. Juergen supported that comment, so I am >> assuming that >> >>  that will be incorporated into the draft. >> > >> > Yes, fixed. >> > >> >> - Andy had questions around datastore set to “conventional†>> > >> > Fixed. >> > >> >>  , about origin filter limited to 1 source >> > >> > Fixed. >> > >> >>  and the behavior of with-defaults. >> > >> > There were no additional changes to the document from the >> discussion >> > about this. >> > >> >>  I see some discussion around it with the authors >> >>  agreeing that some of them need some text clarifying the >> >>  position. Can the authors please post the suggested >> text/additions >> >>  for the WG to review. >> >> - Anything else?? >> >> >> >> Once an updated draft has been posted, I will do a writeup >> on the >> >> drafts and send it to IESG. >> > >> > The issues above are now addressed, in >> > draft-ietf-netconf-nmda-netconf-03. >> > >> > There were no additional comments on >> > draft-ietf-netconf-nmda-restconf-02, so I believe this >> version is >> > ready. >> > >> > >> > /martin >> > >> > >> >> >> >> Thanks. >> >> >> >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder >> > > wrote: >> >>> >> >>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit >> (evoit) wrote: >> >>>> >> >>>> I do have one additional thought below on >> draft-ietf-netmod-revised-datastores section 5.3 default >> handling process.  See in-line... >> >>>> >> >>> >> >>> Well, this document is with the RFC editor now. I do not >> think it needs >> >>> clarification. It already has text in 5.3 such as: >> >>> >> >>>  Requests to retrieve nodes from always >> return the value >> >>>  in use if the node exists, regardless of any default >> value specified >> >>>  in the YANG module.  If no value is returned for a given >> node, then >> >>>  this implies that the node is not used by the device. >> >>> >> >>> /js >> >>> >> >>>> From: Robert Wilton -X, January 31, 2018 6:31 AM >> >>>> >> >>>> >> >>>> Hi Andy, >> >>>> >> >>>> On 31/01/2018 09:22, Andy Bierman wrote: >> >>>> >> >>>> >> >>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder >> > >> > >> >> > >>> wrote: >> >>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman >> wrote: >> >>>>> Hi, >> >>>>> >> >>>>> I have some questions about these drafts. >> >>>>> >> >>>>> 1) what if datastore set to "conventional"? >> >>>>>   There are many places where a datastore-ref type is used. >> >>>>>   However, "conventional" is valid for base >> "datastore", even though >> >>>>>   it is ambiguous as a datastore selector. >> >>>> >> >>>> We can add explicit text that an identity that does not >> resolve to a >> >>>> datastore implemented by the server results in an >> invalid value error. >> >>>> >> >>>> >> >>>> OK >> >>>> >> >>>> >> >>>>> 2) origin filter is limited to 1 source >> >>>>>  This filtering seems rather limited.  A client must >> retrieve >> >>>>> and check >> >>>>>   all the values in use, then make repeated requests >> for each source as a >> >>>>> different >> >>>>>    leaf >> >>>> >> >>>> If the client does , then it has all origin >> information >> >>>> and it can filter locally. That said, we could make >> origin-filter a >> >>>> leaf-list which is logically ORed so that one can retrieve >> >>>> origin-filter=or:system or origin-filter=or:learned in >> one request. >> >>>> >> >>>> >> >>>> OK >> >>>> >> >>>>> 3) with-defaults broken >> >>>>>   The operational datastore does not support with-defaults. >> >>>>>    Instead, the client must use >> origin-filter=or:default or with-origin >> >>>>>    and check all the origin attributes.  Since a client >> needs to use >> >>>>>    with-defaults for other datastores, this special >> handling of >> >>>>> >> >>>>>    seems unhelpful. >> >>>> >> >>>> I think the with-defaults semantics for conventional >> configuration >> >>>> datastores are much more complicated than necessary for the >> >>>> operational state datastore. Note that that the >> operational state >> >>>> datastore reports in-use values not really defaults: >> >>>> >> >>>> foo >> >>>> >> >>>> This reports that the value 'foo' is in use and that it >> originates >> >>>> from a default value. Note that this could also be >> >>>> >> >>>> foo >> >>>> >> >>>> in case the intended configuration datastore configured >> the value >> >>>> 'foo' (despite this value matching the default). The >> with-defaults >> >>>> solution is pretty complex because it tries to handle >> how different >> >>>> systems deal with configuration defaults. The idea is to >> not carry >> >>>> this complexity over to in-use values in the operational >> state >> >>>> datastore. >> >>>> >> >>>> >> >>>> Before NMDA, the client could decide if it wanted to >> retrieve default nodes or not. >> >>>> This client-choice has been removed from NMDA, which is >> a problem. >> >>>> We tried to reach a sensible compromise on the data >> returned from operational (defined in section 5.3 of the NMDA >> architecture): >> >>>> - it should return explicit values for everything that >> is affecting the actual running state of the device >> (regardless of whether the operational value matches a schema >> default value). >> >>>> - it does not need to, and should not, return >> operational values for stuff that isn't actually in use, i.e. >> don't return needless and unwanted data. >> >>>> >> >>>> In particular, if no value is returned from a particular >> data node in then, barring mgmt protocol >> errors, a client can assume that any functionality associated >> with that data node is off (i.e. not in use). >> >>>> >> >>>> Some examples to illustrate the behavior: >> >>>> >> >>>> (i) If a protocol, e.g. OSPF,  is not enabled/running >> then does not need to return any data for it.  >> It would be reasonable to return a flag to indicate that OSPF >> is not enabled/running. >> >>>> >> >>>> (ii) If you have some funky widget on an interface that >> defaults to being off and isn't being used then >> don't need to return any data for it. >> >>>> >> >>>> (iii) But, if you have some funky widget on an interface >> that defaults to being on, then the server should return data >> for it. If it is actually enabled, then it would indicate >> that it is on and return any associated values with its >> operational state, or if it is disabled then it should >> explicitly report that it is off. >> >>>> >> >>>> (iv) I would regard that all applied configuration is >> "in use" by the system, even if it matches the default value, >> and hence it should be reported. >> >>>> >> >>>> >> >>>> This behavior for is obviously slightly >> different from the existing with-default handling that is >> supported for configuration datastores.  As I recall, there >> were a couple of reasons that we decided to have a different >> behavior for : >> >>>> (a) to have consistent semantics for all servers, rather >> than different servers supporting different with-defaults >> behaviors (which makes life harder for clients because they >> must cope with all variants). >> >>>> (b) to remove any potential ambiguity if data isn't >> returned.  I.e. with the existing with-defaults semantics it >> is not clear to me that servers will always return an >> explicit value to indicate that a particular widget is off if >> the schema defines that the default it that is enabled.  If >> the server doesn't support a given widget at all, it is quite >> plausible that it will just return no data for it.  In theory >> features/deviations should handle this, but those don't work >> so well if different linecards have different capabilities.  >> Hence being explicit about stuff that is in use seems more >> robust. >> >>>> >> >>>> These are good examples.  It would be great if >> section 5.3 could be tweaked to make clearer the relationship >> between running datastore defaults and other operational >> datastore defaults for the same tree. >> >>>> >> >>>> For example, let’s say I create a configured >> subscription, and the default transport protocol is NETCONF. >> NETCONF will be used for that subscription even though the >> node might not be populated. In this case, the object would >> not appear in the running datastore, but MUST* appear in the >> operational datastore with the default origin (as it is in-use). >> >>>> >> >>>> This to me is the desired behavior as it doesn’t >> incorrectly add information to the running datastore, but >> shows what is in-use within operational.   I suspect other >> such relationships for other operational tree defaults could >> be asserted, perhaps based on the origin. >> >>>> >> >>>> (* Maybe ‘MUST eventually’, as obviously there is a >> temporal relationship between the two datastores.) >> >>>> >> >>>> Eric >> >>>> >> >>>> Thanks, >> >>>> Rob >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> /js >> >>>> >> >>>> Andy >> >>>> >> >>>> -- >> >>>> Juergen Schoenwaelder    Jacobs University Bremen gGmbH >> >>>> Phone: +49 421 200 3587    Campus Ring 1 | 28759 Bremen >> | Germany >> >>>> Fax:   +49 421 200 3103   >>  > > >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> >> >>>> netmod mailing list >> >>>> >> >>>> netmod@ietf.org >> > >> > >> >> >>>> >> >>>> https://www.ietf.org/mailman/listinfo/netmod >> >> > > >> >>>> >> >>> >> >>>> _______________________________________________ >> >>>> 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 >> >> > > >> >> Mahesh Jethanandani >> >> mjethanandani@gmail.com >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> >> >> >> >> >> _______________________________________________ >> Netconf mailing list >> Netconf@ietf.org >> https://www.ietf.org/mailman/listinfo/netconf >> > > --------------F5F35C40BC2248EBC3AE89B0 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: 8bit



On 07/02/2018 14:23, Andy Bierman wrote:


On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,


On 07/02/2018 02:33, Andy Bierman wrote:


On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
For folks that provided comments as part of LC, please verify that your comments have been adequately addressed by -03 version of the draft.



Most comments have been addressed.


    The "with-defaults" parameter does not apply when interacting with an 
        operational datastore.


There is no explanation of why the with-defaults parameter does not apply to <operational>.
This is confusing. The solution that has been a standard for years still applies to
all datastores, except a completely different mechanism (origin-filter) is used instead
for 1 datastore.

If the server code can identify a default so it can be tagged origin=or:default, then it can
also support with-defaults.

I prefer the sentence above be changed, so that a server MAY implement with-defaults
for <operational>.  If the client sends <with-defaults> it should be OK to honor it instead
of returning an error.
I have two concerns with changing this to a MAY:

(1) The most useful "with-defaults" behavior differs for <operational> vs the configuration datastores, but with-defaults only allows a single standard behavior to be specified.

E.g. for configuration datastores the most appropriate semantics (if the client doesn't explicitly ask for something else) is "explicit". i.e. you give back exactly what was put in.

But, for operational, the most appropriate semantics (if the client doesn't explicitly ask for something else) is something like "report-all", i.e. the device reports the precise current state including any defaults.  However, we felt that this would return too much unnecessary data, hence why the datastore architecture defines "in-use" data, allowing the server to prune out any data that is clearly irrelevant.

(2) <operational> is a new datastore.  I personally don't want each server choosing how the data is returned, which requires that clients must handle all variants.  It would be better for the draft to specify the standard semantics to use unless a client has explicitly requested something else.

I'm not opposed to a "with-defaults-bis", or a new draft covering "with-defaults" for <operational>", but I think that:
(i) We shouldn't delay the NMDA protocol drafts for this, this can be done as separate draft adding extra optional functionality.
(ii) The semantics for retrieving data from operational (or notifications) should be as defined by "in-use" in the NMDA architecture, unless a client has explicitly specified, or configured, a different behavior.
(iii) Probably the only existing option defined in "with-defaults" that makes sense for <operational> is a variant of "trim" that is specified to return what is defined as returning the "in-use" values, but also excluding any values that match a default value specified in the schema.



I think your approach violates the Postel Principle.
"Be liberal in what you accept" is about robustness.
Rejecting parameters for no good reason is about fragility.

I never said change the behavior for <operational> if no <with-defaults> is present.
If the parameter is provided it is trivial for the server to honor it.
The most useful value (report-all) is the default, not leave out all defaults, like <get-config>.
OK, so one option is to allow the "with-defaults" parameter for the <operational> datastore, but specify in both the NETCONF NMDA and RESTCONF NMDA drafts how "with-defaults" semantics apply to any operational datastore:

1) Regardless of what is reported in the "basic-mode" capability parameter, the default behavior for <operational> is "report-all", with semantics as described below:
2) "report-all" for operational datastores is defined as returning all "in use" values (i.e. as specified in section 5.3 of the NMDA architecture, so default values that are not "in use" are not returned).
3) "trim" for operational datastores is defined as returning all "in-use" values (... as 5.3) except that values that match the value specified in the schema "default" statement are omitted.  Note, clients cannot distinguish between a value that is omitted because it is not in use, vs a value that is omitted because it matches the schema default.
4) "explicit" for operational datastores is defined as returning the same as "report-all", defined above.
5) "report-all-tagged" for operational datastores is defined as returning the same as "report-all", except that all values that match the values specified in the schema "default" statement are tagged, as described in with-defaults (RFC 5243).

Also note - there is no change in semantics or behavior to how "with-defaults" works for conventional datastores.

Thoughts?

Thanks,
Rob



 
Thanks,
Rob



Andy
 


Andy


 
Thanks

Mahesh Jethanandani
mjethanandani@gmail.com

> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Hi,
>
> Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
>> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.
>>
>> As part of the LC, there were a couple of comments/questions
>> raised. In particular
>>
>> - Vladmir reported an error, which Martin said is fixed in his local copy.
>
> Fixed.
>
>> - Robert suggested that “/yang-library/checksum†should be a
>>  reference. Juergen supported that comment, so I am assuming that
>>  that will be incorporated into the draft.
>
> Yes, fixed.
>
>> - Andy had questions around datastore set to “conventionalâ€
>
> Fixed.
>
>>  , about origin filter limited to 1 source
>
> Fixed.
>
>>  and the behavior of with-defaults.
>
> There were no additional changes to the document from the discussion
> about this.
>
>>  I see some discussion around it with the authors
>>  agreeing that some of them need some text clarifying the
>>  position. Can the authors please post the suggested text/additions
>>  for the WG to review.
>> - Anything else??
>>
>> Once an updated draft has been posted, I will do a writeup on the
>> drafts and send it to IESG.
>
> The issues above are now addressed, in
> draft-ietf-netconf-nmda-netconf-03.
>
> There were no additional comments on
> draft-ietf-netconf-nmda-restconf-02, so I believe this version is
> ready.
>
>
> /martin
>
>
>>
>> Thanks.
>>
>>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
>>>
>>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote:
>>>>
>>>> I do have one additional thought below on draft-ietf-netmod-revised-datastores section 5.3 default handling process.  See in-line...
>>>>
>>>
>>> Well, this document is with the RFC editor now. I do not think it needs
>>> clarification. It already has text in 5.3 such as:
>>>
>>>  Requests to retrieve nodes from <operational> always return the value
>>>  in use if the node exists, regardless of any default value specified
>>>  in the YANG module.  If no value is returned for a given node, then
>>>  this implies that the node is not used by the device.
>>>
>>> /js
>>>
>>>> From: Robert Wilton -X, January 31, 2018 6:31 AM
>>>>
>>>>
>>>> Hi Andy,
>>>>
>>>> On 31/01/2018 09:22, Andy Bierman wrote:
>>>>
>>>>
>>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de><mailto:j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.de>>> wrote:
>>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
>>>>> Hi,
>>>>>
>>>>> I have some questions about these drafts.
>>>>>
>>>>> 1) what if datastore set to "conventional"?
>>>>>   There are many places where a datastore-ref type is used.
>>>>>   However, "conventional" is valid for base "datastore", even though
>>>>>   it is ambiguous as a datastore selector.
>>>>
>>>> We can add explicit text that an identity that does not resolve to a
>>>> datastore implemented by the server results in an invalid value error.
>>>>
>>>>
>>>> OK
>>>>
>>>>
>>>>> 2) origin filter is limited to 1 source
>>>>>  This filtering seems rather limited.  A client must retrieve
>>>>> <with-origin> and check
>>>>>   all the values in use, then make repeated requests for each source as a
>>>>> different
>>>>>   <origin-filter> leaf
>>>>
>>>> If the client does <with-origin>, then it has all origin information
>>>> and it can filter locally. That said, we could make origin-filter a
>>>> leaf-list which is logically ORed so that one can retrieve
>>>> origin-filter=or:system or origin-filter=or:learned in one request.
>>>>
>>>>
>>>> OK
>>>>
>>>>> 3) with-defaults broken
>>>>>   The operational datastore does not support with-defaults.
>>>>>    Instead, the client must use origin-filter=or:default or with-origin
>>>>>    and check all the origin attributes.  Since a client needs to use
>>>>>    with-defaults for other datastores, this special handling of
>>>>> <operational>
>>>>>    seems unhelpful.
>>>>
>>>> I think the with-defaults semantics for conventional configuration
>>>> datastores are much more complicated than necessary for the
>>>> operational state datastore. Note that that the operational state
>>>> datastore reports in-use values not really defaults:
>>>>
>>>> <leaf or:origin='default'>foo</leaf>
>>>>
>>>> This reports that the value 'foo' is in use and that it originates
>>>> from a default value. Note that this could also be
>>>>
>>>> <leaf or:origin='intended'>foo</leaf>
>>>>
>>>> in case the intended configuration datastore configured the value
>>>> 'foo' (despite this value matching the default). The with-defaults
>>>> solution is pretty complex because it tries to handle how different
>>>> systems deal with configuration defaults. The idea is to not carry
>>>> this complexity over to in-use values in the operational state
>>>> datastore.
>>>>
>>>>
>>>> Before NMDA, the client could decide if it wanted to retrieve default nodes or not.
>>>> This client-choice has been removed from NMDA, which is a problem.
>>>> We tried to reach a sensible compromise on the data returned from operational (defined in section 5.3 of the NMDA architecture):
>>>> - it should return explicit values for everything that is affecting the actual running state of the device (regardless of whether the operational value matches a schema default value).
>>>> - it does not need to, and should not, return operational values for stuff that isn't actually in use, i.e. don't return needless and unwanted data.
>>>>
>>>> In particular, if no value is returned from a particular data node in <operational> then, barring mgmt protocol errors, a client can assume that any functionality associated with that data node is off (i.e. not in use).
>>>>
>>>> Some examples to illustrate the behavior:
>>>>
>>>> (i) If a protocol, e.g. OSPF,  is not enabled/running then <operational> does not need to return any data for it.  It would be reasonable to return a flag to indicate that OSPF is not enabled/running.
>>>>
>>>> (ii) If you have some funky widget on an interface that defaults to being off and isn't being used then <operational> don't need to return any data for it.
>>>>
>>>> (iii) But, if you have some funky widget on an interface that defaults to being on, then the server should return data for it. If it is actually enabled, then it would indicate that it is on and return any associated values with its operational state, or if it is disabled then it should explicitly report that it is off.
>>>>
>>>> (iv) I would regard that all applied configuration is "in use" by the system, even if it matches the default value, and hence it should be reported.
>>>>
>>>>
>>>> This behavior for <operational> is obviously slightly different from the existing with-default handling that is supported for configuration datastores.  As I recall, there were a couple of reasons that we decided to have a different behavior for <operational>:
>>>> (a) to have consistent semantics for all servers, rather than different servers supporting different with-defaults behaviors (which makes life harder for clients because they must cope with all variants).
>>>> (b) to remove any potential ambiguity if data isn't returned.  I.e. with the existing with-defaults semantics it is not clear to me that servers will always return an explicit value to indicate that a particular widget is off if the schema defines that the default it that is enabled.  If the server doesn't support a given widget at all, it is quite plausible that it will just return no data for it.  In theory features/deviations should handle this, but those don't work so well if different linecards have different capabilities.  Hence being explicit about stuff that is in use seems more robust.
>>>>
>>>> <eric> These are good examples.  It would be great if section 5.3 could be tweaked to make clearer the relationship between running datastore defaults and other operational datastore defaults for the same tree.
>>>>
>>>> For example, let’s say I create a configured subscription, and the default transport protocol is NETCONF.  NETCONF will be used for that subscription even though the node might not be populated.  In this case, the object would not appear in the running datastore, but MUST* appear in the operational datastore with the default origin (as it is in-use).
>>>>
>>>> This to me is the desired behavior as it doesn’t incorrectly add information to the running datastore, but shows what is in-use within operational.   I suspect other such relationships for other operational tree defaults could be asserted, perhaps based on the origin.
>>>>
>>>> (* Maybe ‘MUST eventually’, as obviously there is a temporal relationship between the two datastores.)
>>>>
>>>> Eric
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> /js
>>>>
>>>> Andy
>>>>
>>>> --
>>>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>>>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>>>> Fax:   +49 421 200 3103         <https://www.jacobs-university.de/>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>>
>>>> netmod mailing list
>>>>
>>>> netmod@ietf.org <mailto:netmod@ietf.org><mailto:netmod@ietf.org <mailto:netmod@ietf.org>>
>>>>
>>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>>>>
>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>>> https://www.ietf.org/mailman/listinfo/netmod <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         <https://www.jacobs-university.de/ <https://www.jacobs-university.de/>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>> https://www.ietf.org/mailman/listinfo/netmod <https://www.ietf.org/mailman/listinfo/netmod>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>

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



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



--------------F5F35C40BC2248EBC3AE89B0-- From nobody Wed Feb 7 09:30:36 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 438B91270AC for ; Wed, 7 Feb 2018 09:30:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eDSb9FwqMFF2 for ; Wed, 7 Feb 2018 09:30:33 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on071f.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::71f]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AC2812D831 for ; Wed, 7 Feb 2018 09:30:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=gFl4scpT1ZkCVQUkcJcFOLrfV4Gu/exVrlC68CBN2zI=; b=RrGWOV4TFTqaFJxH+fa+vxBD+pk095KYfKiXrhoCXncGFU25V8oEj3LD9DLOAA+yURA9Inef1LnobxAxHS2FSKiEnZcZbdWIYKygkzkhbh9EdeZisbJuhfxXSW/X7r2EDXt1yRBokZi6RJ3CgdbRhcc3XyY9tnWM0ke5XjSdR5g= Received: from pc6 (86.176.21.219) by VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:87::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Wed, 7 Feb 2018 17:30:30 +0000 Message-ID: <017b01d3a039$1d4c5c40$4001a8c0@gateway.2wire.net> From: "t.petch" To: "t.petch" , "NETMOD Working Group" Cc: "RFC Editor" Date: Wed, 7 Feb 2018 17:28:30 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.176.21.219] X-ClientProxiedBy: DB6PR06CA0004.eurprd06.prod.outlook.com (2603:10a6:6:1::17) To VI1PR0701MB3006.eurprd07.prod.outlook.com (2603:10a6:800:87::20) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: e6af5e6c-f8e1-4995-5611-08d56e507c6b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(2017052603307)(7193020); SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 3:2MNFgiMh7cJAgNZgop+PQdo/5y6N05vI6fKQL76li9bFvqI4zjwKArykScLMUGr6C09zVFB6OzM90+UkZW2JvhAjVNzgsyVW5KjBmcqdPNeP/YlNZevhJGbz7+OnaPU9lS1mMFpmirvC7axITF0ojU0qnOPQ02IrCPsTIomKb4sjb9r3mEUCM/6gVw/LA8X2QGgzb3T88rv1V2v66/ZDz6cBz3Hfqe5l/hQ8BH0SPBv2v9up+VjFlVJPDKBgQ3Ps; 25:8USkEOhv+MoN8+0ExlS1aNX4Ojsv65qu/t2P+t+MPFWeMNb9CCmYwhnou3ZdAPWC0ORCvbktPnrZN9+U7TZJGnCJZsbektmms+v87W0TvxBjztDEekr+mhLUFvLniMGSNtBMVONfPyuHhb77N63Dgdxg1PLVSkzLsG33YJqQJTFeKJpsxW/ab/ymj96Ro5tm9+IjugaqP0fWHZk9puS7vAtBbxiPtWlh6BKgI1ukhbcdM7t8Ynadf00Cj6FbiGhRt9XfB2Xd6Scgw/GS/xIfpq5Hwa8+Dmu5pxNc33zVsovPN22/fVb6UmE/5sAK0v53E0/8NJR5HuioStVlzuvLAQ==; 31:gxq1ko97x0dQfl+z54fBRGCc2OlRg7CCn/kwXgXmFkOpd38xZ8hZ3kR5lQRQbvOW6oo/gxcHSEM3BYbUdZ6fZ7Ararx3Mvw33oI8U08AfMFgF3cvnkbjhD5uVzkUCrDH+i/utimybKjKMEcJ/ee5qxqn7H4KeBjrZACOe10TS7MQEP5AK3sNUepLIzKH89g0rC9G/b95byPbo1+AYCwT2T52qFyjSapvxB1lumONrSg= X-MS-TrafficTypeDiagnostic: VI1PR0701MB3006: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041288)(20161123560045)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0701MB3006; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3006; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 4:LZVo8yEqO2TyIbFlbwiWoTjU0DD8SF1z9rAzrtLvNdUpoZh23g3d0uMwl/C1JeeT9mTxIZzRMPnkjEO+UgK8WaYsT50/MB3wm0ICc4eQ8BCBGGiMnsCh/HsQiZNZ4jams7ca8FsTQosaYEiWx5OQ+9J2dSg7z7/jU7TjzRpXN54J2vhdXi3Xetqnyn4Kl2Ur6Fn1RcM3/4dPyNSzeO/taa6gb0SJS5ou1VurrdZ2HiPXgISZD7//AgkG27Aed5nkPqAMjBi9dcwR4bYykCCFDA== X-Forefront-PRVS: 0576145E86 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(376002)(346002)(366004)(396003)(39380400002)(39860400002)(199004)(189003)(81816011)(81686011)(8936002)(16526019)(33896004)(105586002)(50226002)(84392002)(61296003)(23756003)(81156014)(81166006)(106356001)(8676002)(26005)(6116002)(3846002)(386003)(478600001)(25786009)(2906002)(4326008)(6346003)(9686003)(53936002)(8666007)(50466002)(305945005)(66066001)(52116002)(7736002)(6496006)(97736004)(44736005)(6486002)(5660300001)(110136005)(14496001)(86362001)(316002)(296002)(230700001)(5890100001)(1556002)(62236002)(44716002)(47776003)(4720700003)(68736007)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3006; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3006; 23:iwLchLbwUKIOjIqiV9WtGQhYzXlHTv/JG0QmO?= =?iso-8859-1?Q?C3AWDMKgmE3D5NP1DUGxJD9cT7WUzGsfRiNsXPPvwdEYiXQeYRJYsDuCdj?= =?iso-8859-1?Q?mlAIPxVK8eiOZWvs0Y3ThEKLCqa5+Xr33E0EkHZR+Wq4CWxyeJzXLBMPvi?= =?iso-8859-1?Q?5C9HwARGLq274WtTKeO5TrpuV6B4S2MpCUfGKdXR1QCHUWGrrhTLVEtgMz?= =?iso-8859-1?Q?mKy3dJ7/0wAHiNnHMRPAzZ5Lxf26M9dMX1H829aUQ6F6bhRBpkdCGM4MCL?= =?iso-8859-1?Q?JRrY8WhNwyzb97xeRmCqXRLHKFfInYD72TS7OoNHo9IRdhDaw7wVZMmIzw?= =?iso-8859-1?Q?S0ukjixrPBUjTr76v1P2sDtgSX2Hz46Ch6lczPi5dryjIUaFKobi8EUF8B?= =?iso-8859-1?Q?Sizzmjw0mh9B/Xn99NSK+C9Fal6RvjS0YKJrXP+bxkfxVrHh8eya19sZ9i?= =?iso-8859-1?Q?P2IcTnTRLN9qtAdUQ8bp8mkwZ6VbRhQV4IzGektb6ljulbR5irqSN51Ty6?= =?iso-8859-1?Q?ovwcg+o0+r0XvAi01PBYh5bkEM6QgVPrdNdbUIrT8vtnzvdsA437sXVLQL?= =?iso-8859-1?Q?eifEh6AkVX3amqLll5a3B64yBKkyvhl6dCQanj+jrx0I5MBhhKR2Mgl6Na?= =?iso-8859-1?Q?0Dsc8bvJiYIkKSDDx7DQuOBZwa5DHN8jkyPb/alQNqLwWrFfTctVRJNCTZ?= =?iso-8859-1?Q?sirXB4Q3QVnrBxxW7H8H27G2CoiAQ9/0YrX1QI7HmvJc3Peb3CmQwaCFXJ?= =?iso-8859-1?Q?PqYkTyd8u4KcWi/sG36NMT7zUD16RGXbOElFoT8bNYms4/yVeEqwvb7NUJ?= =?iso-8859-1?Q?s1ix7rubYXKfUYfHAbzDlz6oGDxWytPvrKlQhDQhweUq8pRLWdQmTJyX8R?= =?iso-8859-1?Q?mhcF1ogioc61QABNfEJwLDsFXxpw2QhywjXKkCb6RJN7AKi5mrjyQqI7F2?= =?iso-8859-1?Q?k29qAjsGXY7d0B39h6HrLe+IUFhU5v7/8Q3oQwtIsZ0tePXIi0stADCQQP?= =?iso-8859-1?Q?CoqXYYT3aBcKluWeAwIPmyyrk7gaVQxhgYtBziEmNwG6T7fFh7S2XpU1zF?= =?iso-8859-1?Q?RYhphnpcqD5NJtroltHH6YFZvCuCBdMq9XcoCuTdM2rlim+fUJ7NfIPXP4?= =?iso-8859-1?Q?7BZVBUh5D8Y4wR8lxvNBwz+022X+lylCTg+71xJdf4RnBPjwfAQnPA+Ewg?= =?iso-8859-1?Q?jtYPf1uM2nY/0XCVGGOSlJTLibDG7l5aP/WU1N0agCPaNRbjGJD366K8/8?= =?iso-8859-1?Q?JcxPJvHIDaQgYSMrOU9j0jvpH/ELe0Abd2wqSkeq6DkHQ+qWM1J/o8aB0R?= =?iso-8859-1?Q?t5mZoX4e7TAW+IycTWcqo107P8aKPb0TyiRtPJ9c/1zCxSmUG8HVKWS8TH?= =?iso-8859-1?Q?p5ihPzjGB8WTbQcjsCOeZ8pz6hT6iU5?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3006; 6:wNmt93F7bQfpZeGL0N4VYxoSO9EmRSjTGjgvO5g6f8QwC2ePPWJsXEkuGHWziJXoSOxlqSHU8vEsAa/bRkGkBgowbQhT5MRe+RgfpmZhuagQy+zHpry4bbp5difj42IHSAcTdnbOXvBuxGIOzF6m9Q4TauCuw9xuAbjuDXVZWcCtMZle0Lh4Sx0S8GNdRu7xKn6idXFNaVrX5UXZzLKyD4PBX/r2HBDXCfqKp9d6PYz6D3v7HeZH9y6PSBiy1AZwFSUoq9jgbOk1SaB47gUDnWXZKGPycF5ACeTovL/V3idecjY3otilul8taAotBQkmsHNaCoUUxOzHGBwMDevw8Gv347yYI4dH3QYxseJuXCs=; 5:iuQhmyqtZDJbY2ilKwvsqb6vIeda4BLlPgRL6IiHZuq7pbJ1yCkEh+iBkSI7+Fr9SbgZBdOHZuX+/sfn3D+NdAFb3Dg8V6rIoh+kBeOnHqhxt/FvpzUs2IHUU5pKQze0b9jIGQokXTCv0mvb3A7ywuWjTDxs5Iql6xnOaEPb9MA=; 24:royuraeYu1XUcnzK7jV9THFIYCyDJvNFiupC6KmBQHrq3oFqYCjMbOGM4ZndZB1dOEka2feNik4l/9tCn4cgtqS6FCTOxb5t5NWpqX4+pNg=; 7:87I7x5xEltioDnpURsdXIpFp7h0TRZ9v2qjVhxGH9OgvaX1dpgemb4/z8f+1N1l7N0CApeeJSrj2tLKz6wBDrXgCB/Lpx9fDEVl52EHdN9onFAISYc+vRP7QxJsq1v/OL3bdQYwOPgiC9ZyHssMzcBXk1TgTtFoMnIqd/MMHgSjyypbTIeDnPbV1Yhh3OSYzoIGgzKhwEVx8JeUVSsekT5IGvcPR0N4P80oJdm5V3kW+BjdiRwS1QrkfPyU0bGa/ SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2018 17:30:30.2422 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: e6af5e6c-f8e1-4995-5611-08d56e507c6b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3006 Archived-At: Subject: [netmod] Draft Normative references in a YANG module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 17:30:35 -0000 Will the RFC Editor know that reference "draft-ietf-netmod-rfc7223bis: A YANG Data Model for Interface Management"; in draft-ietf-rtgwg-ni-model-09 needs replacing by RFCxxxx when that I-D becomes an RFC? Normally, such a reference would be [draft-ietf-netmod-rfc7223bis] with the underlying HTML/XML anchor and automated tools can pick this up (I assume that the RFC Editor is well automated:-) But when the Normative Reference is in the text of a YANG module and there is no underlying anchor, will this get noticed and actioned? Or should there be a Note to RFC Editor attached to such references? Tom Petch From nobody Wed Feb 7 09:49:05 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6412F12D86C for ; Wed, 7 Feb 2018 09:49:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UahrMtuR9t7l for ; Wed, 7 Feb 2018 09:49:01 -0800 (PST) Received: from mail-lf0-x232.google.com (mail-lf0-x232.google.com [IPv6:2a00:1450:4010:c07::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C771E12D84D for ; Wed, 7 Feb 2018 09:49:00 -0800 (PST) Received: by mail-lf0-x232.google.com with SMTP id q17so2551232lfa.9 for ; Wed, 07 Feb 2018 09:49:00 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=wii3HEaYpO17+r8yhGaEcGNaPa4ZnuEGA+qgwE9m0DE=; b=FLcOOWDc3jwPdzMEBRTsF6I73N1fhaTpoQuJ7U/97QJXqTgjvbMH4ncw2H81ijqDbn SiqJFBjGT2Qy0XLQLDi4RxYIl30hSFXAYiJbLGNeUx9ceW8k5ODHNrW+MpzglltZ9ZZ0 RsZoDGk3m70yqt//tIwQjog8zfdi/JdlDd0b7lQJuyFJVUd/CNPaPgAezChI6ViYIy2p 0iexmZhNaTwiP1buQSX+O7Bb6mBa3sxLBdhHFUAmmNiOl0LE/tTz7PPB8u/anHopkDiV A+GYRb3tFD+3/b3mIA2326BJUIagQt3j+JluZHhgkVkEPIKGNOo4Cs1UdKxsOJ5rxXFR 3plA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=wii3HEaYpO17+r8yhGaEcGNaPa4ZnuEGA+qgwE9m0DE=; b=TlSLESIoiWp97xpsReAwJj0mcNhK7blSWqTUfY2B2MG++HsRXTzk67Kf5Ws7XDqaXI 2apAj0PJOGt+uz3HoYQFvxtw1T+Q27cMPuxB+E5KwPDtHRWXCdOO+hMMF8bSdtMRfJX+ rgqWM0UxfiYhNP+2mdizGHvFdest9LqVisSXU4y3idWoLC54UTd2rurQiDfWYWi5GpJy dfEmGiRTmAsljW7VlOOfeCsgtfwXgbkogb2BlIaRqQJpEUJkx+0MLwqFz9QoZFQA3fZc eM8fg+xRedUEsV+8MhkQP0Ki/2O6tC9TxTW+dsONUvkgULp7lATgiDBPIqtCIQ0XmtLt zj9g== X-Gm-Message-State: APf1xPB2YjRSypKbIag/Gw3qX4AF3xu3k2gX3i2afyxBaV5/QfwX8gxa ySa8LJ+hgENO2LcfDszZyb50/OnI5crjVo6QfioPOg== X-Google-Smtp-Source: AH8x226DJ4kUed7xVLG55nF7nOlbVtK9lB7V6lZaXoqQmq/F2QKiQ3/WUH1LGaZeqs/tQLI/HQk1h558sCXKadl97Ac= X-Received: by 10.46.22.30 with SMTP id w30mr4502921ljd.91.1518025738933; Wed, 07 Feb 2018 09:48:58 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.143.6 with HTTP; Wed, 7 Feb 2018 09:48:58 -0800 (PST) In-Reply-To: <01f501d3a013$72e66180$4001a8c0@gateway.2wire.net> References: <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com> <6BAC6B11-90A9-4CA1-AE53-FFAC084FB76E@juniper.net> <5c2ae0a9-b4b9-3d13-395e-1c779f99f941@cisco.com> <01f501d3a013$72e66180$4001a8c0@gateway.2wire.net> From: Andy Bierman Date: Wed, 7 Feb 2018 09:48:58 -0800 Message-ID: To: "t.petch" Cc: NETMOD Working Group Content-Type: multipart/alternative; boundary="f403045fb506edec620564a2e8dc" Archived-At: Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-16 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 17:49:03 -0000 --f403045fb506edec620564a2e8dc Content-Type: text/plain; charset="UTF-8" On Wed, Feb 7, 2018 at 4:58 AM, t.petch wrote: > Andy > > If an RFC is mentioned in a Description clause, should it also appear in > the related Reference clause? > yes -- there are many places in 6087bis that mention the reference-stmt e.g.: If the notification semantics are defined in an external document (other than another YANG module indicated by an import statement), then a reference statement MUST be present. I cannot find any text that says it is OK or not OK to also put the reference in the description-stmt. > draft-ietf-dhc-dhcpv6-yang-05 has examples of this not being the case, > as I mention in a recent post. I assumed that they should be but cannot > see any discussion of this in RFC6087bis > > Tom Petch > > Andy --f403045fb506edec620564a2e8dc Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 7, 2018 at 4:58 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
Andy<= br>
If an RFC is mentioned in a Description clause, should it also appear in the related Reference clause?

yes -- th= ere are many places in 6087bis that mention the reference-stmt =C2=A0
= 

e.g.:

   If the notification semantics are defined in an external document
   (other than another YANG module indicated by an import statement),
   then a reference statement MUST be present.

I cannot find any text that says it is OK or not OK to= also put
the reference in the description-stmt.




draft-ietf-dhc-dhcpv6-yang-05 has examples of this not being the case,
as I mention in a recent post.=C2=A0 I assumed that they should be but cann= ot
see any discussion of this in RFC6087bis

Tom Petch


Andy

--f403045fb506edec620564a2e8dc-- From nobody Wed Feb 7 10:14:39 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BEA6312E04D for ; Wed, 7 Feb 2018 10:14:36 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SHzj1lPa13vA for ; Wed, 7 Feb 2018 10:14:33 -0800 (PST) Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 5D44512D865 for ; Wed, 7 Feb 2018 10:14:32 -0800 (PST) Received: by mail-lf0-x22e.google.com with SMTP id x20so712677lff.6 for ; Wed, 07 Feb 2018 10:14:32 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=e6hBSh/VNaaa9vnhKIZGIobVTSHSbk8WM98Ov6k5uqI=; b=V04RW+gchUwzKgwj0+kMH6Zq0Nxl7axBtp07ZsDlcye+RAzm+KVaRA7U9TLG3l4dWD FiSOcY9ReSDJjKdtflLfrGl0tYuyPRoYcF4oqIwvH4QQe6yssQm1mIfE3oRUMhYaGZlI Dw/1Brkn430PCId1HNoyXxG6IVedIzQJJbJIyb2oUfljVcAGpJ/aodYFuif3jdczpvsA SQ42Wuzgvd4qOac4dd1s01nUjQGff/MfNi2EDzE4iGbCXxexVubH1X3fvCE7CI+F8Osj QznpYhfGHDpoN2IWfI1qg27r0hh4jFaPP1vqvvGAHQMbsnvX6ZSfJ2+zZSdffDNKBHHY IA/A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=e6hBSh/VNaaa9vnhKIZGIobVTSHSbk8WM98Ov6k5uqI=; b=lZ/LPeoEgA7vNke7t1ElMYPLubxNSIpQR+oMfw5fh8jAjJivbFknC96mpdDZJjQm5u 05/WcljE9siqiky3f7jOnIbNDBANGLf2n7xcabl5b9J890aspTwkyrdDTGlACPXZueRn TPS0rfQbm8QSWe04ZTcFgL3oXwWh7IjXlgLLDfl7Wpg+4drU3CcZ6AA601YcjWFDljkk pbEOVZtoM5bbIljvT1wE1q377WKnJz38F4fV2T6AYLpea4A1bsxwsqNnkNJdgn6B4C8h bRI4lvDYaBN7q/EcnQMpFZRa8ImOt/p1tBzVFUbdHc6NLhIn/QlVVEselPb2aWDCeWQF AoHg== X-Gm-Message-State: APf1xPDMu0uUGiu+Me0jre//uUwa7P7zBS1OW1VD5ww8kBGKcsOuMSmi 4oDhC653R8nCoubeIqe9UYh1IZLNeiCOs9MRE+hkzA== X-Google-Smtp-Source: AH8x227PGI89WuAx+4Slf0ofMCjk9876XzkDZLbJSlixxlJwUBQTOMgXfQZpIH+Z8uk76y9ybY1jNoJSkDi59E5DVeU= X-Received: by 10.46.22.30 with SMTP id w30mr4548001ljd.91.1518027270478; Wed, 07 Feb 2018 10:14:30 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.143.6 with HTTP; Wed, 7 Feb 2018 10:14:29 -0800 (PST) In-Reply-To: References: <29b8034ef2a94523944d53767e6789be@XCH-RTP-013.cisco.com> <20180131181619.ziqdv5peqdeeuhl4@elstar.local> <20180205.184312.338993520253253388.mbj@tail-f.com> <39203004-C003-4C07-A376-006B6F7969D6@gmail.com> <8d90fd4c-711a-1b90-529b-778f81e80bf5@cisco.com> From: Andy Bierman Date: Wed, 7 Feb 2018 10:14:29 -0800 Message-ID: To: Robert Wilton Cc: Netconf , NetMod WG , Mahesh Jethanandani Content-Type: multipart/alternative; boundary="f403045fb50637fbbf0564a34448" Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 18:14:37 -0000 --f403045fb50637fbbf0564a34448 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton wrote: > > > On 07/02/2018 14:23, Andy Bierman wrote: > > > > On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton wrote: > >> Hi Andy, >> >> On 07/02/2018 02:33, Andy Bierman wrote: >> >> >> >> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani < >> mjethanandani@gmail.com> wrote: >> >>> For folks that provided comments as part of LC, please verify that your >>> comments have been adequately addressed by -03 version of the draft. >>> >>> >> >> Most comments have been addressed. >> >> >> The "with-defaults" parameter does not apply when interacting with a= n >> >> operational datastore. >> >> >> There is no explanation of why the with-defaults parameter does not appl= y >> to . >> This is confusing. The solution that has been a standard for years still >> applies to >> all datastores, except a completely different mechanism (origin-filter) >> is used instead >> for 1 datastore. >> >> If the server code can identify a default so it can be tagged >> origin=3Dor:default, then it can >> also support with-defaults. >> >> I prefer the sentence above be changed, so that a server MAY implement >> with-defaults >> for . If the client sends it should be OK >> to honor it instead >> of returning an error. >> >> I have two concerns with changing this to a MAY: >> >> (1) The most useful "with-defaults" behavior differs for v= s >> the configuration datastores, but with-defaults only allows a single >> standard behavior to be specified. >> >> E.g. for configuration datastores the most appropriate semantics (if the >> client doesn't explicitly ask for something else) is "explicit". i.e. yo= u >> give back exactly what was put in. >> >> But, for operational, the most appropriate semantics (if the client >> doesn't explicitly ask for something else) is something like "report-all= ", >> i.e. the device reports the precise current state including any defaults= . >> However, we felt that this would return too much unnecessary data, hence >> why the datastore architecture defines "in-use" data, allowing the serve= r >> to prune out any data that is clearly irrelevant. >> >> (2) is a new datastore. I personally don't want each >> server choosing how the data is returned, which requires that clients mu= st >> handle all variants. It would be better for the draft to specify the >> standard semantics to use unless a client has explicitly requested >> something else. >> >> I'm not opposed to a "with-defaults-bis", or a new draft covering >> "with-defaults" for ", but I think that: >> (i) We shouldn't delay the NMDA protocol drafts for this, this can be >> done as separate draft adding extra optional functionality. >> (ii) The semantics for retrieving data from operational (or >> notifications) should be as defined by "in-use" in the NMDA architecture= , >> unless a client has explicitly specified, or configured, a different >> behavior. >> (iii) Probably the only existing option defined in "with-defaults" that >> makes sense for is a variant of "trim" that is specified t= o >> return what is defined as returning the "in-use" values, but also exclud= ing >> any values that match a default value specified in the schema. >> >> > > I think your approach violates the Postel Principle. > "Be liberal in what you accept" is about robustness. > Rejecting parameters for no good reason is about fragility. > > I never said change the behavior for if no > is present. > If the parameter is provided it is trivial for the server to honor it. > The most useful value (report-all) is the default, not leave out all > defaults, like . > > OK, so one option is to allow the "with-defaults" parameter for the > datastore, but specify in both the NETCONF NMDA and RESTCON= F > NMDA drafts how "with-defaults" semantics apply to any operational > datastore: > > 1) Regardless of what is reported in the "basic-mode" capability > parameter, the default behavior for is "report-all", with > semantics as described below: > 2) "report-all" for operational datastores is defined as returning all "i= n > use" values (i.e. as specified in section 5.3 of the NMDA architecture, s= o > default values that are not "in use" are not returned). > 3) "trim" for operational datastores is defined as returning all "in-use" > values (... as 5.3) except that values that match the value specified in > the schema "default" statement are omitted. Note, clients cannot > distinguish between a value that is omitted because it is not in use, vs = a > value that is omitted because it matches the schema default. > 4) "explicit" for operational datastores is defined as returning the same > as "report-all", defined above. > 5) "report-all-tagged" for operational datastores is defined as returning > the same as "report-all", except that all values that match the values > specified in the schema "default" statement are tagged, as described in > with-defaults (RFC 5243). > > Also note - there is no change in semantics or behavior to how > "with-defaults" works for conventional datastores. > > Thoughts? > > This looks good. Showing the work... 1) there is no YANG default for parameter. The behavior if this parameter is missing is determined by the operatio= n 2) The operation returns all values in use. The only way to suppress defaults is to use (e.g., request all origins except 'default') 3) The parameter for is mostly a NO-OP. It does not add or remove any nodes that would be returned. The "report-all-tagged" value does add the "default> attribute, which is useful for clients that process these attributes already 4) The values that are tagged default are the same ones that the server tag= s as origin=3Ddefault. 5) It still seems to up to the server "basic-mode" as to what is considered "set by default". This messy aspect of NETCONF is minimized in because the server usually returns all values in use. Thanks, > Rob > > Andy > > > > >> Thanks, >> Rob >> >> >> > Andy > > >> >> >> Andy >> >> >> >> >>> Thanks >>> >>> Mahesh Jethanandani >>> mjethanandani@gmail.com >>> >>> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund wrote: >>> > >>> > Hi, >>> > >>> > Mahesh Jethanandani wrote: >>> >> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF. >>> >> >>> >> As part of the LC, there were a couple of comments/questions >>> >> raised. In particular >>> >> >>> >> - Vladmir reported an error, which Martin said is fixed in his local >>> copy. >>> > >>> > Fixed. >>> > >>> >> - Robert suggested that =E2=80=9C/yang-library/checksum=E2=80=9D sho= uld be a >>> >> reference. Juergen supported that comment, so I am assuming that >>> >> that will be incorporated into the draft. >>> > >>> > Yes, fixed. >>> > >>> >> - Andy had questions around datastore set to =E2=80=9Cconventional= =E2=80=9D >>> > >>> > Fixed. >>> > >>> >> , about origin filter limited to 1 source >>> > >>> > Fixed. >>> > >>> >> and the behavior of with-defaults. >>> > >>> > There were no additional changes to the document from the discussion >>> > about this. >>> > >>> >> I see some discussion around it with the authors >>> >> agreeing that some of them need some text clarifying the >>> >> position. Can the authors please post the suggested text/additions >>> >> for the WG to review. >>> >> - Anything else?? >>> >> >>> >> Once an updated draft has been posted, I will do a writeup on the >>> >> drafts and send it to IESG. >>> > >>> > The issues above are now addressed, in >>> > draft-ietf-netconf-nmda-netconf-03. >>> > >>> > There were no additional comments on >>> > draft-ietf-netconf-nmda-restconf-02, so I believe this version is >>> > ready. >>> > >>> > >>> > /martin >>> > >>> > >>> >> >>> >> Thanks. >>> >> >>> >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de> wrote: >>> >>> >>> >>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote: >>> >>>> >>> >>>> I do have one additional thought below on >>> draft-ietf-netmod-revised-datastores section 5.3 default handling >>> process. See in-line... >>> >>>> >>> >>> >>> >>> Well, this document is with the RFC editor now. I do not think it >>> needs >>> >>> clarification. It already has text in 5.3 such as: >>> >>> >>> >>> Requests to retrieve nodes from always return the >>> value >>> >>> in use if the node exists, regardless of any default value specifi= ed >>> >>> in the YANG module. If no value is returned for a given node, the= n >>> >>> this implies that the node is not used by the device. >>> >>> >>> >>> /js >>> >>> >>> >>>> From: Robert Wilton -X, January 31, 2018 6:31 AM >>> >>>> >>> >>>> >>> >>>> Hi Andy, >>> >>>> >>> >>>> On 31/01/2018 09:22, Andy Bierman wrote: >>> >>>> >>> >>>> >>> >>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder < >>> j.schoenwaelder@jacobs-university.de >> -university.de>>> j.schoenwaelder@jacobs-university.de>>> wrote: >>> >>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: >>> >>>>> Hi, >>> >>>>> >>> >>>>> I have some questions about these drafts. >>> >>>>> >>> >>>>> 1) what if datastore set to "conventional"? >>> >>>>> There are many places where a datastore-ref type is used. >>> >>>>> However, "conventional" is valid for base "datastore", even >>> though >>> >>>>> it is ambiguous as a datastore selector. >>> >>>> >>> >>>> We can add explicit text that an identity that does not resolve to= a >>> >>>> datastore implemented by the server results in an invalid value >>> error. >>> >>>> >>> >>>> >>> >>>> OK >>> >>>> >>> >>>> >>> >>>>> 2) origin filter is limited to 1 source >>> >>>>> This filtering seems rather limited. A client must retrieve >>> >>>>> and check >>> >>>>> all the values in use, then make repeated requests for each >>> source as a >>> >>>>> different >>> >>>>> leaf >>> >>>> >>> >>>> If the client does , then it has all origin informati= on >>> >>>> and it can filter locally. That said, we could make origin-filter = a >>> >>>> leaf-list which is logically ORed so that one can retrieve >>> >>>> origin-filter=3Dor:system or origin-filter=3Dor:learned in one req= uest. >>> >>>> >>> >>>> >>> >>>> OK >>> >>>> >>> >>>>> 3) with-defaults broken >>> >>>>> The operational datastore does not support with-defaults. >>> >>>>> Instead, the client must use origin-filter=3Dor:default or >>> with-origin >>> >>>>> and check all the origin attributes. Since a client needs to >>> use >>> >>>>> with-defaults for other datastores, this special handling of >>> >>>>> >>> >>>>> seems unhelpful. >>> >>>> >>> >>>> I think the with-defaults semantics for conventional configuration >>> >>>> datastores are much more complicated than necessary for the >>> >>>> operational state datastore. Note that that the operational state >>> >>>> datastore reports in-use values not really defaults: >>> >>>> >>> >>>> foo >>> >>>> >>> >>>> This reports that the value 'foo' is in use and that it originates >>> >>>> from a default value. Note that this could also be >>> >>>> >>> >>>> foo >>> >>>> >>> >>>> in case the intended configuration datastore configured the value >>> >>>> 'foo' (despite this value matching the default). The with-defaults >>> >>>> solution is pretty complex because it tries to handle how differen= t >>> >>>> systems deal with configuration defaults. The idea is to not carry >>> >>>> this complexity over to in-use values in the operational state >>> >>>> datastore. >>> >>>> >>> >>>> >>> >>>> Before NMDA, the client could decide if it wanted to retrieve >>> default nodes or not. >>> >>>> This client-choice has been removed from NMDA, which is a problem. >>> >>>> We tried to reach a sensible compromise on the data returned from >>> operational (defined in section 5.3 of the NMDA architecture): >>> >>>> - it should return explicit values for everything that is affectin= g >>> the actual running state of the device (regardless of whether the >>> operational value matches a schema default value). >>> >>>> - it does not need to, and should not, return operational values >>> for stuff that isn't actually in use, i.e. don't return needless and >>> unwanted data. >>> >>>> >>> >>>> In particular, if no value is returned from a particular data node >>> in then, barring mgmt protocol errors, a client can assum= e >>> that any functionality associated with that data node is off (i.e. not = in >>> use). >>> >>>> >>> >>>> Some examples to illustrate the behavior: >>> >>>> >>> >>>> (i) If a protocol, e.g. OSPF, is not enabled/running then >>> does not need to return any data for it. It would be >>> reasonable to return a flag to indicate that OSPF is not enabled/runnin= g. >>> >>>> >>> >>>> (ii) If you have some funky widget on an interface that defaults t= o >>> being off and isn't being used then don't need to return = any >>> data for it. >>> >>>> >>> >>>> (iii) But, if you have some funky widget on an interface that >>> defaults to being on, then the server should return data for it. If it = is >>> actually enabled, then it would indicate that it is on and return any >>> associated values with its operational state, or if it is disabled then= it >>> should explicitly report that it is off. >>> >>>> >>> >>>> (iv) I would regard that all applied configuration is "in use" by >>> the system, even if it matches the default value, and hence it should b= e >>> reported. >>> >>>> >>> >>>> >>> >>>> This behavior for is obviously slightly different >>> from the existing with-default handling that is supported for configura= tion >>> datastores. As I recall, there were a couple of reasons that we decide= d to >>> have a different behavior for : >>> >>>> (a) to have consistent semantics for all servers, rather than >>> different servers supporting different with-defaults behaviors (which m= akes >>> life harder for clients because they must cope with all variants). >>> >>>> (b) to remove any potential ambiguity if data isn't returned. I.e= . >>> with the existing with-defaults semantics it is not clear to me that >>> servers will always return an explicit value to indicate that a particu= lar >>> widget is off if the schema defines that the default it that is enabled= . >>> If the server doesn't support a given widget at all, it is quite plausi= ble >>> that it will just return no data for it. In theory features/deviations >>> should handle this, but those don't work so well if different linecards >>> have different capabilities. Hence being explicit about stuff that is = in >>> use seems more robust. >>> >>>> >>> >>>> These are good examples. It would be great if section 5.3 >>> could be tweaked to make clearer the relationship between running datas= tore >>> defaults and other operational datastore defaults for the same tree. >>> >>>> >>> >>>> For example, let=E2=80=99s say I create a configured subscription,= and the >>> default transport protocol is NETCONF. NETCONF will be used for that >>> subscription even though the node might not be populated. In this case= , >>> the object would not appear in the running datastore, but MUST* appear = in >>> the operational datastore with the default origin (as it is in-use). >>> >>>> >>> >>>> This to me is the desired behavior as it doesn=E2=80=99t incorrect= ly add >>> information to the running datastore, but shows what is in-use within >>> operational. I suspect other such relationships for other operational >>> tree defaults could be asserted, perhaps based on the origin. >>> >>>> >>> >>>> (* Maybe =E2=80=98MUST eventually=E2=80=99, as obviously there is = a temporal >>> relationship between the two datastores.) >>> >>>> >>> >>>> Eric >>> >>>> >>> >>>> Thanks, >>> >>>> Rob >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> /js >>> >>>> >>> >>>> Andy >>> >>>> >>> >>>> -- >>> >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>> >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >>> Germany >>> >>> >>>> Fax: +49 421 200 3103 >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> _______________________________________________ >>> >>>> >>> >>>> netmod mailing list >>> >>>> >>> >>>> netmod@ietf.org >> > >>> >>>> >>> >>>> https://www.ietf.org/mailman/listinfo/netmod < >>> https://www.ietf.org/mailman/listinfo/netmod> >>> >>>> >>> >>> >>> >>>> _______________________________________________ >>> >>>> netmod mailing list >>> >>>> netmod@ietf.org >>> >>>> https://www.ietf.org/mailman/listinfo/netmod < >>> 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 >> https://www.jacobs-university.de/>> >>> >>> >>> >>> _______________________________________________ >>> >>> netmod mailing list >>> >>> netmod@ietf.org >>> >>> https://www.ietf.org/mailman/listinfo/netmod < >>> https://www.ietf.org/mailman/listinfo/netmod> >>> >> Mahesh Jethanandani >>> >> mjethanandani@gmail.com >>> >> >>> >>> _______________________________________________ >>> Netconf mailing list >>> Netconf@ietf.org >>> https://www.ietf.org/mailman/listinfo/netconf >>> >> >> >> >> _______________________________________________ >> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinf= o/netconf >> >> >> > > --f403045fb50637fbbf0564a34448 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton <rwilton@cisco.com&g= t; wrote:
=20 =20 =20



On 07/02/2018 14:2= 3, Andy Bierman wrote:
=20


On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,


On 07/02/2018 02:33, Andy Bierman wrote:


On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <= mjethanandani@= gmail.com> wrote:
F= or folks that provided comments as part of LC, please verify that your comments have been adequately addressed by -03 version of the draft.



Most comments have been addressed.


    The "with-defaults" parameter does =
not apply when interacting with an=C2=A0
=C2=A0 =C2=A0 =C2=A0 =C2=A0 operational datastore.


There is no explanation of why the with-defaults parameter does not apply to <operational>.
This is confusing. The solution that has been a standard for years still applies to
all datastores, except a completely different mechanism (origin-filter) is used instead
for 1 datastore.

If the server code can identify a default so it can be tagged origin=3Dor:default, then it can
also support with-defaults.

I prefer the sentence above be changed, so that a server MAY implement with-defaults
for <operational>.=C2=A0 If the client sends <with-defaults> it should be OK to honor it instead
of returning an error.
I have two concerns with changing this to a MAY:

(1) The most useful "with-defaults" behavior diff= ers for <operational> vs the configuration datastores, but with-defaults only allows a single standard behavior to be specified.

E.g. for configuration datastores the most appropriate semantics (if the client doesn't explicitly ask for something else) is "explicit". i.e. you give back exactly what was put in.

But, for operational, the most appropriate semantics (if the client doesn't explicitly ask for something else) i= s something like "report-all", i.e. the device repo= rts the precise current state including any defaults.=C2=A0 However= , we felt that this would return too much unnecessary data, hence why the datastore architecture defines "in-use" data, allowing the server to prune out a= ny data that is clearly irrelevant.

(2) <operational> is a new datastore.=C2=A0 I personally don't want each server choosing how the data is returned, which requires that clients must handle all variants.=C2=A0 It would be better for the draft to specify the standard semantics to use unless a client has explicitly requested something else.

I'm not opposed to a "with-defaults-bis", or = a new draft covering "with-defaults" for <operational>&= quot;, but I think that:
(i) We shouldn't delay the NMDA protocol drafts for this, this can be done as separate draft adding extra optional functionality.
(ii) The semantics for retrieving data from operational (or notifications) should be as defined by "in-use&quo= t; in the NMDA architecture, unless a client has explicitly specified, or configured, a different behavior.
(iii) Probably the only existing option defined in "with-defaults" that makes sense for <operatio= nal> is a variant of "trim" that is specified to retur= n what is defined as returning the "in-use" values, but = also excluding any values that match a default value specified in the schema.



I think your approach violates the Postel Principle.
"Be liberal in what you accept" is about robustn= ess.
Rejecting parameters for no good reason is about fragility.

I never said change the behavior for <operational> if no <with-defaults> is present.
If the parameter is provided it is trivial for the server to honor it.
The most useful value (report-all) is the default, not leave out all defaults, like <get-config>.
OK, so one option is to allow the "with-defaults" parameter f= or the <operational> datastore, but specify in both the NETCONF NMDA and RESTCONF NMDA drafts how "with-defaults" semantics apply = to any operational datastore:

1) Regardless of what is reported in the "basic-mode" capabil= ity parameter, the default behavior for <operational> is "report-all", with semantics as described below:
2) "report-all" for operational datastores is defined as retu= rning all "in use" values (i.e. as specified in section 5.3 of the = NMDA architecture, so default values that are not "in use" are not returned).
3) "trim" for operational datastores is defined as returning = all "in-use" values (... as 5.3) except that values that match th= e value specified in the schema "default" statement are omitted.=C2= =A0 Note, clients cannot distinguish between a value that is omitted because it is not in use, vs a value that is omitted because it matches the schema default.
4) "explicit" for operational datastores is defined as return= ing the same as "report-all", defined above.
5) "report-all-tagged" for operational datastores is defined = as returning the same as "report-all", except that all values th= at match the values specified in the schema "default" statement = are tagged, as described in with-defaults (RFC 5243).

Also note - there is no change in semantics or behavior to how "with-defaults" works for conventional datastores.

Thoughts?


This looks good.
<= br>
Showing the work...

1) there is no Y= ANG default for <with-defaults> parameter.
=C2=A0 =C2=A0 Th= e behavior if this parameter is missing is determined by the operation

2) The <get-data> operation returns all values i= n use.
=C2=A0 =C2=A0 The only way to suppress defaults is to use = <origin-filter>
=C2=A0 =C2=A0 (e.g., request all origins ex= cept 'default')

3) The <with-defaults&g= t; parameter for <operational> is mostly a NO-OP.
=C2=A0 = =C2=A0 It does not add or remove any nodes that would be returned.
=C2=A0 =C2=A0 The "report-all-tagged" value does add the "= default> attribute, which is useful
=C2=A0 =C2=A0 for clients = that process these attributes already

4) The value= s that are tagged default are the same ones that the server tags
= =C2=A0 =C2=A0 =C2=A0as origin=3Ddefault.

5) It sti= ll seems to up to the server "basic-mode" as to what is considere= d
=C2=A0 =C2=A0 =C2=A0"set by default". This messy aspe= ct of NETCONF is minimized in <get-data> because
=C2=A0 =C2= =A0 =C2=A0the server usually returns all values in use.


Thanks,
Rob



Andy
=C2=A0


=C2=A0
Thanks,
Rob



Andy
=C2=A0


Andy


=C2=A0
= Thanks

Mahesh Jethanandani
mjethanandani@gmail.com

> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
>
> Hi,
>
> Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
>> This closes the LC for the two NDMA drafts for NETCONF and RESTCONF.
>>
>> As part of the LC, there were a couple of comments/questions
>> raised. In particular
>>
>> - Vladmir reported an error, which Martin said is fixed in his local copy.
>
> Fixed.
>
>> - Robert suggested that =E2=80=9C/yang-library/checksum=E2=80=9D should b= e a
>>=C2=A0 reference. Juergen supported that comment, so I am assuming that
>>=C2=A0 that will be incorporated into the draft.
>
> Yes, fixed.
>
>> - Andy had questions around datastore set to =E2=80=9Cconventional=E2=80=9D
>
> Fixed.
>
>>=C2=A0 , about origin filter limited to 1 source
>
> Fixed.
>
>>=C2=A0 and the behavior of with-defaults.=
>
> There were no additional changes to the document from the discussion
> about this.
>
>>=C2=A0 I see some discussion around it wi= th the authors
>>=C2=A0 agreeing that some of them need so= me text clarifying the
>>=C2=A0 position. Can the authors please post the suggested text/additions
>>=C2=A0 for the WG to review.
>> - Anything else??
>>
>> Once an updated draft has been posted, I will do a writeup on the
>> drafts and send it to IESG.
>
> The issues above are now addressed, in
> draft-ietf-netconf-nmda-netconf-03.
>
> There were no additional comments on
> draft-ietf-netconf-nmda-restconf-02, so I believe this version is
> ready.
>
>
> /martin
>
>
>>
>> Thanks.
>>
>>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-u= niversity.de> wrote:
>>>
>>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote:
>>>>
>>>> I do have one additional thought below on draft-ietf-netmod-revised-datastores section 5.3 default handling process.=C2=A0 See in-line...
>>>>
>>>
>>> Well, this document is with the RFC editor now. I do not think it needs
>>> clarification. It already has text in 5.3 such as:
>>>
>>>=C2=A0 Requests to retrieve nodes fro= m <operational> always return the value
>>>=C2=A0 in use if the node exists, regardless of any default value specified
>>>=C2=A0 in the YANG module.=C2=A0 If n= o value is returned for a given node, then
>>>=C2=A0 this implies that the node is not used by the device.
>>>
>>> /js
>>>
>>>> From: Robert Wilton -X, January 31, 2018 6:31 AM
>>>>
>>>>
>>>> Hi Andy,
>>>>
>>>> On 31/01/2018 09:22, Andy Bierman wrote:
>>>>
>>>>
>>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder <j.schoenwaelder@jaco= bs-university.de <mailto:j.schoenwaelder@jacobs-university.= de><mailto:j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs-university.= de>>> wrote:
>>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote:
>>>>> Hi,
>>>>>
>>>>> I have some questions about these drafts.
>>>>>
>>>>> 1) what if datastore set to "conventional"?
>>>>>=C2=A0 =C2=A0There are many p= laces where a datastore-ref type is used.
>>>>>=C2=A0 =C2=A0However, "c= onventional" is valid for base "datastore", even tho= ugh
>>>>>=C2=A0 =C2=A0it is ambiguous = as a datastore selector.
>>>>
>>>> We can add explicit text that an identity that does not resolve to a
>>>> datastore implemented by the server results in an invalid value error.
>>>>
>>>>
>>>> OK
>>>>
>>>>
>>>>> 2) origin filter is limited to 1 source
>>>>>=C2=A0 This filtering seems rather limited.=C2=A0 A client must retrieve
>>>>> <with-origin> and check
>>>>>=C2=A0 =C2=A0all the values i= n use, then make repeated requests for each source as a
>>>>> different
>>>>>=C2=A0 =C2=A0<origin-filte= r> leaf
>>>>
>>>> If the client does <with-origin>, then it has all origin information
>>>> and it can filter locally. That said, we could make origin-filter a
>>>> leaf-list which is logically ORed so that one can retrieve
>>>> origin-filter=3Dor:system or origin-filter=3Dor:learned in one request.
>>>>
>>>>
>>>> OK
>>>>
>>>>> 3) with-defaults broken
>>>>>=C2=A0 =C2=A0The operational datastore does not support with-defaults.
>>>>>=C2=A0 =C2=A0 Instead, the cl= ient must use origin-filter=3Dor:default or with-origin
>>>>>=C2=A0 =C2=A0 and check all t= he origin attributes.=C2=A0 Since a client needs to use
>>>>>=C2=A0 =C2=A0 with-defaults f= or other datastores, this special handling of
>>>>> <operational>
>>>>>=C2=A0 =C2=A0 seems unhelpful= .
>>>>
>>>> I think the with-defaults semantics for conventional configuration
>>>> datastores are much more complicated than necessary for the
>>>> operational state datastore. Note that that the operational state
>>>> datastore reports in-use values not really defaults:
>>>>
>>>> <leaf or:origin=3D'default'>foo</leaf>=
>>>>
>>>> This reports that the value 'foo' is in use and that it originates >>>> from a default value. Note that this could also be
>>>>
>>>> <leaf or:origin=3D'intended'>foo</leaf>
>>>>
>>>> in case the intended configuration datastore configured the value
>>>> 'foo' (despite this valu= e matching the default). The with-defaults
>>>> solution is pretty complex because it tries to handle how different
>>>> systems deal with configuration defaults. The idea is to not carry
>>>> this complexity over to in-use values in the operational state
>>>> datastore.
>>>>
>>>>
>>>> Before NMDA, the client could decide if it wanted to retrieve default nodes or not.
>>>> This client-choice has been removed from NMDA, which is a problem.
>>>> We tried to reach a sensible compromise on the data returned from operational (defined in section 5.3 of the NMDA architecture):
>>>> - it should return explicit values for everything that is affecting the actual running state of the device (regardless of whether the operational value matches a schema default value).
>>>> - it does not need to, and should not, return operational values for stuff that isn't actually in use, i.e. don= 9;t return needless and unwanted data.
>>>>
>>>> In particular, if no value is returned from a particular data node in <operational> then, barring mgmt protocol errors, a client can assume that any functionality associated with that data node is off (i.e. not in use).
>>>>
>>>> Some examples to illustrate the behavior:
>>>>
>>>> (i) If a protocol, e.g. OSPF,=C2=A0 is not enabled/running then <operational> does not need to return any data for it.=C2=A0 It would be reasonable to return a flag to indicate that OSPF is not enabled/running.
>>>>
>>>> (ii) If you have some funky widget on an interface that defaults to being off and isn't being used then <operational> don't need to return any data for it.
>>>>
>>>> (iii) But, if you have some funky widget on an interface that defaults to being on, then the server should return data for it. If it is actually enabled, then it would indicate that it is on and return any associated values with its operational state, or if it is disabled then it should explicitly report that it is off.
>>>>
>>>> (iv) I would regard that all applied configuration is "in use" by th= e system, even if it matches the default value, and hence it should be reported.
>>>>
>>>>
>>>> This behavior for <operational> is obviously slightly different from the existing with-default handling that is supported for configuration datastores.=C2=A0 As I recall, there were a coupl= e of reasons that we decided to have a different behavior for <operational>:
>>>> (a) to have consistent semantics for all servers, rather than different servers supporting different with-defaults behaviors (which makes life harder for clients because they must cope with all variants).
>>>> (b) to remove any potential ambiguity if data isn't returned.=C2=A0 I.e. = with the existing with-defaults semantics it is not clear to me that servers will always return an explicit value to indicate that a particular widget is off if the schema defines that the default it that is enabled.=C2=A0 If the server doesn't support a given widget at all, it is quite plausible that it will just return no data for it.=C2=A0 In theory features/deviations should handle this, but those don't work so well if different linecards have different capabilities.=C2=A0 Hence being explicit about stuff that is in use seems more robust.
>>>>
>>>> <eric> These are good examples.=C2=A0 It would be great if section 5.3 could be tweaked to make clearer the relationship between running datastore defaults and other operational datastore defaults for the same tree.
>>>>
>>>> For example, let=E2=80=99s say I create a configured subscription, and the default transport protocol is NETCONF.=C2=A0 NETCONF will be used for that subscription even though the node might not be populated.=C2= =A0 In this case, the object would not appear in the running datastore, but MUST* appear in the operational datastore with the default origin (as it is in-use).
>>>>
>>>> This to me is the desired behavior as it doesn=E2=80=99t incorrectly add information to the running datastore, but shows what is in-use within operational.=C2=A0 = =C2=A0I suspect other such relationships for other operational tree defaults could be asserted, perhaps based on the origin.
>>>>
>>>> (* Maybe =E2=80=98MUST eventuall= y=E2=80=99, as obviously there is a temporal relationship between the two datastores.)
>>>>
>>>> Eric
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> /js
>>>>
>>>> Andy
>>>>
>>>> --
>>>> 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 310= 3=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-unive= rsity.de/>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> ____________________________________________= ___
>>>>
>>>> netmod mailing list
>>>>
>>>> netmod@ietf.org <mailto:netmod@ietf.org><mailto:netmod@ietf.org <mailto:netmod@ietf.org>>
>>>>
>>>> https://www.i= etf.org/mailman/listinfo/netmod <https://www.ietf.org/mailm= an/listinfo/netmod>
>>>>
>>>
>>>> ____________________________________________= ___
>>>> netmod mailing list
>>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>>> https://www.i= etf.org/mailman/listinfo/netmod <https://www.ietf.org/mailm= an/listinfo/netmod>
>>>
>>>
>>> --
>>> 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=A0C= ampus Ring 1 | 28759 Bremen | Germany
>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/ <https://www.jacobs-university.de= />>
>>>
>>> _______________________________= ________________
>>> netmod mailing list
>>> netmod@ietf.org <mailto:netmod@ietf.org>
>>> https://www.ietf.= org/mailman/listinfo/netmod <https://www.ietf.org/mailm= an/listinfo/netmod>
>> Mahesh Jethanandani
>> mjethanandani@gmail.com
>>

____________________________________________= ___
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/= listinfo/netconf



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




--f403045fb50637fbbf0564a34448-- From nobody Wed Feb 7 10:28:14 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 82AD41275FD; Wed, 7 Feb 2018 10:28:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v0DNyWd8ID8w; Wed, 7 Feb 2018 10:28:04 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 472A9126DED; Wed, 7 Feb 2018 10:28:04 -0800 (PST) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 32C731AE0118; Wed, 7 Feb 2018 19:28:03 +0100 (CET) Date: Wed, 07 Feb 2018 19:28:03 +0100 (CET) Message-Id: <20180207.192803.834988416883038576.mbj@tail-f.com> To: andy@yumaworks.com Cc: rwilton@cisco.com, netconf@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=utf-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 18:28:08 -0000 QW5keSBCaWVybWFuIDxhbmR5QHl1bWF3b3Jrcy5jb20+IHdyb3RlOg0KPiBPbiBXZWQsIEZlYiA3 LCAyMDE4IGF0IDg6MTEgQU0sIFJvYmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPiB3cm90 ZToNCj4gDQo+ID4NCj4gPg0KPiA+IE9uIDA3LzAyLzIwMTggMTQ6MjMsIEFuZHkgQmllcm1hbiB3 cm90ZToNCj4gPg0KPiA+DQo+ID4NCj4gPiBPbiBXZWQsIEZlYiA3LCAyMDE4IGF0IDM6MTQgQU0s IFJvYmVydCBXaWx0b24gPHJ3aWx0b25AY2lzY28uY29tPiB3cm90ZToNCj4gPg0KPiA+PiBIaSBB bmR5LA0KPiA+Pg0KPiA+PiBPbiAwNy8wMi8yMDE4IDAyOjMzLCBBbmR5IEJpZXJtYW4gd3JvdGU6 DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+IE9uIE1vbiwgRmViIDUsIDIwMTggYXQgMTozMyBQTSwg TWFoZXNoIEpldGhhbmFuZGFuaSA8DQo+ID4+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPiB3cm90 ZToNCj4gPj4NCj4gPj4+IEZvciBmb2xrcyB0aGF0IHByb3ZpZGVkIGNvbW1lbnRzIGFzIHBhcnQg b2YgTEMsIHBsZWFzZSB2ZXJpZnkgdGhhdCB5b3VyDQo+ID4+PiBjb21tZW50cyBoYXZlIGJlZW4g YWRlcXVhdGVseSBhZGRyZXNzZWQgYnkgLTAzIHZlcnNpb24gb2YgdGhlIGRyYWZ0Lg0KPiA+Pj4N Cj4gPj4+DQo+ID4+DQo+ID4+IE1vc3QgY29tbWVudHMgaGF2ZSBiZWVuIGFkZHJlc3NlZC4NCj4g Pj4NCj4gPj4NCj4gPj4gICAgIFRoZSAid2l0aC1kZWZhdWx0cyIgcGFyYW1ldGVyIGRvZXMgbm90 IGFwcGx5IHdoZW4gaW50ZXJhY3Rpbmcgd2l0aCBhbg0KPiA+Pg0KPiA+PiAgICAgICAgIG9wZXJh dGlvbmFsIGRhdGFzdG9yZS4NCj4gPj4NCj4gPj4NCj4gPj4gVGhlcmUgaXMgbm8gZXhwbGFuYXRp b24gb2Ygd2h5IHRoZSB3aXRoLWRlZmF1bHRzIHBhcmFtZXRlciBkb2VzIG5vdCBhcHBseQ0KPiA+ PiB0byA8b3BlcmF0aW9uYWw+Lg0KPiA+PiBUaGlzIGlzIGNvbmZ1c2luZy4gVGhlIHNvbHV0aW9u IHRoYXQgaGFzIGJlZW4gYSBzdGFuZGFyZCBmb3IgeWVhcnMgc3RpbGwNCj4gPj4gYXBwbGllcyB0 bw0KPiA+PiBhbGwgZGF0YXN0b3JlcywgZXhjZXB0IGEgY29tcGxldGVseSBkaWZmZXJlbnQgbWVj aGFuaXNtIChvcmlnaW4tZmlsdGVyKQ0KPiA+PiBpcyB1c2VkIGluc3RlYWQNCj4gPj4gZm9yIDEg ZGF0YXN0b3JlLg0KPiA+Pg0KPiA+PiBJZiB0aGUgc2VydmVyIGNvZGUgY2FuIGlkZW50aWZ5IGEg ZGVmYXVsdCBzbyBpdCBjYW4gYmUgdGFnZ2VkDQo+ID4+IG9yaWdpbj1vcjpkZWZhdWx0LCB0aGVu IGl0IGNhbg0KPiA+PiBhbHNvIHN1cHBvcnQgd2l0aC1kZWZhdWx0cy4NCj4gPj4NCj4gPj4gSSBw cmVmZXIgdGhlIHNlbnRlbmNlIGFib3ZlIGJlIGNoYW5nZWQsIHNvIHRoYXQgYSBzZXJ2ZXIgTUFZ IGltcGxlbWVudA0KPiA+PiB3aXRoLWRlZmF1bHRzDQo+ID4+IGZvciA8b3BlcmF0aW9uYWw+LiAg SWYgdGhlIGNsaWVudCBzZW5kcyA8d2l0aC1kZWZhdWx0cz4gaXQgc2hvdWxkIGJlIE9LDQo+ID4+ IHRvIGhvbm9yIGl0IGluc3RlYWQNCj4gPj4gb2YgcmV0dXJuaW5nIGFuIGVycm9yLg0KPiA+Pg0K PiA+PiBJIGhhdmUgdHdvIGNvbmNlcm5zIHdpdGggY2hhbmdpbmcgdGhpcyB0byBhIE1BWToNCj4g Pj4NCj4gPj4gKDEpIFRoZSBtb3N0IHVzZWZ1bCAid2l0aC1kZWZhdWx0cyIgYmVoYXZpb3IgZGlm ZmVycyBmb3IgPG9wZXJhdGlvbmFsPiB2cw0KPiA+PiB0aGUgY29uZmlndXJhdGlvbiBkYXRhc3Rv cmVzLCBidXQgd2l0aC1kZWZhdWx0cyBvbmx5IGFsbG93cyBhIHNpbmdsZQ0KPiA+PiBzdGFuZGFy ZCBiZWhhdmlvciB0byBiZSBzcGVjaWZpZWQuDQo+ID4+DQo+ID4+IEUuZy4gZm9yIGNvbmZpZ3Vy YXRpb24gZGF0YXN0b3JlcyB0aGUgbW9zdCBhcHByb3ByaWF0ZSBzZW1hbnRpY3MgKGlmIHRoZQ0K PiA+PiBjbGllbnQgZG9lc24ndCBleHBsaWNpdGx5IGFzayBmb3Igc29tZXRoaW5nIGVsc2UpIGlz ICJleHBsaWNpdCIuIGkuZS4geW91DQo+ID4+IGdpdmUgYmFjayBleGFjdGx5IHdoYXQgd2FzIHB1 dCBpbi4NCj4gPj4NCj4gPj4gQnV0LCBmb3Igb3BlcmF0aW9uYWwsIHRoZSBtb3N0IGFwcHJvcHJp YXRlIHNlbWFudGljcyAoaWYgdGhlIGNsaWVudA0KPiA+PiBkb2Vzbid0IGV4cGxpY2l0bHkgYXNr IGZvciBzb21ldGhpbmcgZWxzZSkgaXMgc29tZXRoaW5nIGxpa2UgInJlcG9ydC1hbGwiLA0KPiA+ PiBpLmUuIHRoZSBkZXZpY2UgcmVwb3J0cyB0aGUgcHJlY2lzZSBjdXJyZW50IHN0YXRlIGluY2x1 ZGluZyBhbnkgZGVmYXVsdHMuDQo+ID4+IEhvd2V2ZXIsIHdlIGZlbHQgdGhhdCB0aGlzIHdvdWxk IHJldHVybiB0b28gbXVjaCB1bm5lY2Vzc2FyeSBkYXRhLCBoZW5jZQ0KPiA+PiB3aHkgdGhlIGRh dGFzdG9yZSBhcmNoaXRlY3R1cmUgZGVmaW5lcyAiaW4tdXNlIiBkYXRhLCBhbGxvd2luZyB0aGUg c2VydmVyDQo+ID4+IHRvIHBydW5lIG91dCBhbnkgZGF0YSB0aGF0IGlzIGNsZWFybHkgaXJyZWxl dmFudC4NCj4gPj4NCj4gPj4gKDIpIDxvcGVyYXRpb25hbD4gaXMgYSBuZXcgZGF0YXN0b3JlLiAg SSBwZXJzb25hbGx5IGRvbid0IHdhbnQgZWFjaA0KPiA+PiBzZXJ2ZXIgY2hvb3NpbmcgaG93IHRo ZSBkYXRhIGlzIHJldHVybmVkLCB3aGljaCByZXF1aXJlcyB0aGF0IGNsaWVudHMgbXVzdA0KPiA+ PiBoYW5kbGUgYWxsIHZhcmlhbnRzLiAgSXQgd291bGQgYmUgYmV0dGVyIGZvciB0aGUgZHJhZnQg dG8gc3BlY2lmeSB0aGUNCj4gPj4gc3RhbmRhcmQgc2VtYW50aWNzIHRvIHVzZSB1bmxlc3MgYSBj bGllbnQgaGFzIGV4cGxpY2l0bHkgcmVxdWVzdGVkDQo+ID4+IHNvbWV0aGluZyBlbHNlLg0KPiA+ Pg0KPiA+PiBJJ20gbm90IG9wcG9zZWQgdG8gYSAid2l0aC1kZWZhdWx0cy1iaXMiLCBvciBhIG5l dyBkcmFmdCBjb3ZlcmluZw0KPiA+PiAid2l0aC1kZWZhdWx0cyIgZm9yIDxvcGVyYXRpb25hbD4i LCBidXQgSSB0aGluayB0aGF0Og0KPiA+PiAoaSkgV2Ugc2hvdWxkbid0IGRlbGF5IHRoZSBOTURB IHByb3RvY29sIGRyYWZ0cyBmb3IgdGhpcywgdGhpcyBjYW4gYmUNCj4gPj4gZG9uZSBhcyBzZXBh cmF0ZSBkcmFmdCBhZGRpbmcgZXh0cmEgb3B0aW9uYWwgZnVuY3Rpb25hbGl0eS4NCj4gPj4gKGlp KSBUaGUgc2VtYW50aWNzIGZvciByZXRyaWV2aW5nIGRhdGEgZnJvbSBvcGVyYXRpb25hbCAob3IN Cj4gPj4gbm90aWZpY2F0aW9ucykgc2hvdWxkIGJlIGFzIGRlZmluZWQgYnkgImluLXVzZSIgaW4g dGhlIE5NREEgYXJjaGl0ZWN0dXJlLA0KPiA+PiB1bmxlc3MgYSBjbGllbnQgaGFzIGV4cGxpY2l0 bHkgc3BlY2lmaWVkLCBvciBjb25maWd1cmVkLCBhIGRpZmZlcmVudA0KPiA+PiBiZWhhdmlvci4N Cj4gPj4gKGlpaSkgUHJvYmFibHkgdGhlIG9ubHkgZXhpc3Rpbmcgb3B0aW9uIGRlZmluZWQgaW4g IndpdGgtZGVmYXVsdHMiIHRoYXQNCj4gPj4gbWFrZXMgc2Vuc2UgZm9yIDxvcGVyYXRpb25hbD4g aXMgYSB2YXJpYW50IG9mICJ0cmltIiB0aGF0IGlzIHNwZWNpZmllZCB0bw0KPiA+PiByZXR1cm4g d2hhdCBpcyBkZWZpbmVkIGFzIHJldHVybmluZyB0aGUgImluLXVzZSIgdmFsdWVzLCBidXQgYWxz byBleGNsdWRpbmcNCj4gPj4gYW55IHZhbHVlcyB0aGF0IG1hdGNoIGEgZGVmYXVsdCB2YWx1ZSBz cGVjaWZpZWQgaW4gdGhlIHNjaGVtYS4NCj4gPj4NCj4gPj4NCj4gPg0KPiA+IEkgdGhpbmsgeW91 ciBhcHByb2FjaCB2aW9sYXRlcyB0aGUgUG9zdGVsIFByaW5jaXBsZS4NCj4gPiAiQmUgbGliZXJh bCBpbiB3aGF0IHlvdSBhY2NlcHQiIGlzIGFib3V0IHJvYnVzdG5lc3MuDQo+ID4gUmVqZWN0aW5n IHBhcmFtZXRlcnMgZm9yIG5vIGdvb2QgcmVhc29uIGlzIGFib3V0IGZyYWdpbGl0eS4NCj4gPg0K PiA+IEkgbmV2ZXIgc2FpZCBjaGFuZ2UgdGhlIGJlaGF2aW9yIGZvciA8b3BlcmF0aW9uYWw+IGlm IG5vIDx3aXRoLWRlZmF1bHRzPg0KPiA+IGlzIHByZXNlbnQuDQo+ID4gSWYgdGhlIHBhcmFtZXRl ciBpcyBwcm92aWRlZCBpdCBpcyB0cml2aWFsIGZvciB0aGUgc2VydmVyIHRvIGhvbm9yIGl0Lg0K PiA+IFRoZSBtb3N0IHVzZWZ1bCB2YWx1ZSAocmVwb3J0LWFsbCkgaXMgdGhlIGRlZmF1bHQsIG5v dCBsZWF2ZSBvdXQgYWxsDQo+ID4gZGVmYXVsdHMsIGxpa2UgPGdldC1jb25maWc+Lg0KPiA+DQo+ ID4gT0ssIHNvIG9uZSBvcHRpb24gaXMgdG8gYWxsb3cgdGhlICJ3aXRoLWRlZmF1bHRzIiBwYXJh bWV0ZXIgZm9yIHRoZQ0KPiA+IDxvcGVyYXRpb25hbD4gZGF0YXN0b3JlLCBidXQgc3BlY2lmeSBp biBib3RoIHRoZSBORVRDT05GIE5NREEgYW5kIFJFU1RDT05GDQo+ID4gTk1EQSBkcmFmdHMgaG93 ICJ3aXRoLWRlZmF1bHRzIiBzZW1hbnRpY3MgYXBwbHkgdG8gYW55IG9wZXJhdGlvbmFsDQo+ID4g ZGF0YXN0b3JlOg0KPiA+DQo+ID4gMSkgUmVnYXJkbGVzcyBvZiB3aGF0IGlzIHJlcG9ydGVkIGlu IHRoZSAiYmFzaWMtbW9kZSIgY2FwYWJpbGl0eQ0KPiA+IHBhcmFtZXRlciwgdGhlIGRlZmF1bHQg YmVoYXZpb3IgZm9yIDxvcGVyYXRpb25hbD4gaXMgInJlcG9ydC1hbGwiLCB3aXRoDQo+ID4gc2Vt YW50aWNzIGFzIGRlc2NyaWJlZCBiZWxvdzoNCj4gPiAyKSAicmVwb3J0LWFsbCIgZm9yIG9wZXJh dGlvbmFsIGRhdGFzdG9yZXMgaXMgZGVmaW5lZCBhcyByZXR1cm5pbmcgYWxsICJpbg0KPiA+IHVz ZSIgdmFsdWVzIChpLmUuIGFzIHNwZWNpZmllZCBpbiBzZWN0aW9uIDUuMyBvZiB0aGUgTk1EQSBh cmNoaXRlY3R1cmUsIHNvDQo+ID4gZGVmYXVsdCB2YWx1ZXMgdGhhdCBhcmUgbm90ICJpbiB1c2Ui IGFyZSBub3QgcmV0dXJuZWQpLg0KPiA+IDMpICJ0cmltIiBmb3Igb3BlcmF0aW9uYWwgZGF0YXN0 b3JlcyBpcyBkZWZpbmVkIGFzIHJldHVybmluZyBhbGwgImluLXVzZSINCj4gPiB2YWx1ZXMgKC4u LiBhcyA1LjMpIGV4Y2VwdCB0aGF0IHZhbHVlcyB0aGF0IG1hdGNoIHRoZSB2YWx1ZSBzcGVjaWZp ZWQgaW4NCj4gPiB0aGUgc2NoZW1hICJkZWZhdWx0IiBzdGF0ZW1lbnQgYXJlIG9taXR0ZWQuICBO b3RlLCBjbGllbnRzIGNhbm5vdA0KPiA+IGRpc3Rpbmd1aXNoIGJldHdlZW4gYSB2YWx1ZSB0aGF0 IGlzIG9taXR0ZWQgYmVjYXVzZSBpdCBpcyBub3QgaW4gdXNlLCB2cyBhDQo+ID4gdmFsdWUgdGhh dCBpcyBvbWl0dGVkIGJlY2F1c2UgaXQgbWF0Y2hlcyB0aGUgc2NoZW1hIGRlZmF1bHQuDQo+ID4g NCkgImV4cGxpY2l0IiBmb3Igb3BlcmF0aW9uYWwgZGF0YXN0b3JlcyBpcyBkZWZpbmVkIGFzIHJl dHVybmluZyB0aGUgc2FtZQ0KPiA+IGFzICJyZXBvcnQtYWxsIiwgZGVmaW5lZCBhYm92ZS4NCj4g PiA1KSAicmVwb3J0LWFsbC10YWdnZWQiIGZvciBvcGVyYXRpb25hbCBkYXRhc3RvcmVzIGlzIGRl ZmluZWQgYXMgcmV0dXJuaW5nDQo+ID4gdGhlIHNhbWUgYXMgInJlcG9ydC1hbGwiLCBleGNlcHQg dGhhdCBhbGwgdmFsdWVzIHRoYXQgbWF0Y2ggdGhlIHZhbHVlcw0KPiA+IHNwZWNpZmllZCBpbiB0 aGUgc2NoZW1hICJkZWZhdWx0IiBzdGF0ZW1lbnQgYXJlIHRhZ2dlZCwgYXMgZGVzY3JpYmVkIGlu DQo+ID4gd2l0aC1kZWZhdWx0cyAoUkZDIDUyNDMpLg0KPiA+DQo+ID4gQWxzbyBub3RlIC0gdGhl cmUgaXMgbm8gY2hhbmdlIGluIHNlbWFudGljcyBvciBiZWhhdmlvciB0byBob3cNCj4gPiAid2l0 aC1kZWZhdWx0cyIgd29ya3MgZm9yIGNvbnZlbnRpb25hbCBkYXRhc3RvcmVzLg0KPiA+DQo+ID4g VGhvdWdodHM/DQo+ID4NCj4gPg0KPiBUaGlzIGxvb2tzIGdvb2QuDQo+IA0KPiBTaG93aW5nIHRo ZSB3b3JrLi4uDQo+IA0KPiAxKSB0aGVyZSBpcyBubyBZQU5HIGRlZmF1bHQgZm9yIDx3aXRoLWRl ZmF1bHRzPiBwYXJhbWV0ZXIuDQo+ICAgICBUaGUgYmVoYXZpb3IgaWYgdGhpcyBwYXJhbWV0ZXIg aXMgbWlzc2luZyBpcyBkZXRlcm1pbmVkIGJ5IHRoZSBvcGVyYXRpb24NCg0KUmlnaHQuICBTbyBp biB0aGlzIGNhc2UgKGdldC1kYXRhIG9mIG9wZXJhdGlvbmFsKSwgaXQgd291bGQgcmV0dXJuIGFs bA0KZGVmYXVsdCB2YWx1ZXMgaW4gdXNlLg0KDQo+IDIpIFRoZSA8Z2V0LWRhdGE+IG9wZXJhdGlv biByZXR1cm5zIGFsbCB2YWx1ZXMgaW4gdXNlLg0KPiAgICAgVGhlIG9ubHkgd2F5IHRvIHN1cHBy ZXNzIGRlZmF1bHRzIGlzIHRvIHVzZSA8b3JpZ2luLWZpbHRlcj4NCj4gICAgIChlLmcuLCByZXF1 ZXN0IGFsbCBvcmlnaW5zIGV4Y2VwdCAnZGVmYXVsdCcpDQoNCk9yIHVzZSB3aXRoLWRlZmF1bHRz ID0gdHJpbS4NCg0KPiAzKSBUaGUgPHdpdGgtZGVmYXVsdHM+IHBhcmFtZXRlciBmb3IgPG9wZXJh dGlvbmFsPiBpcyBtb3N0bHkgYSBOTy1PUC4NCj4gICAgIEl0IGRvZXMgbm90IGFkZCBvciByZW1v dmUgYW55IG5vZGVzIHRoYXQgd291bGQgYmUgcmV0dXJuZWQuDQo+ICAgICBUaGUgInJlcG9ydC1h bGwtdGFnZ2VkIiB2YWx1ZSBkb2VzIGFkZCB0aGUgImRlZmF1bHQ+IGF0dHJpYnV0ZSwgd2hpY2gN Cj4gaXMgdXNlZnVsDQo+ICAgICBmb3IgY2xpZW50cyB0aGF0IHByb2Nlc3MgdGhlc2UgYXR0cmli dXRlcyBhbHJlYWR5DQo+IA0KPiA0KSBUaGUgdmFsdWVzIHRoYXQgYXJlIHRhZ2dlZCBkZWZhdWx0 IGFyZSB0aGUgc2FtZSBvbmVzIHRoYXQgdGhlIHNlcnZlciB0YWdzDQo+ICAgICAgYXMgb3JpZ2lu PWRlZmF1bHQuDQo+IA0KPiA1KSBJdCBzdGlsbCBzZWVtcyB0byB1cCB0byB0aGUgc2VydmVyICJi YXNpYy1tb2RlIiBhcyB0byB3aGF0IGlzIGNvbnNpZGVyZWQNCj4gICAgICAic2V0IGJ5IGRlZmF1 bHQiLiBUaGlzIG1lc3N5IGFzcGVjdCBvZiBORVRDT05GIGlzIG1pbmltaXplZCBpbg0KPiA8Z2V0 LWRhdGE+IGJlY2F1c2UNCj4gICAgICB0aGUgc2VydmVyIHVzdWFsbHkgcmV0dXJucyBhbGwgdmFs dWVzIGluIHVzZS4NCg0KDQoNCi9tYXJ0aW4NCg0KDQoNCj4gDQo+IA0KPiBUaGFua3MsDQo+ID4g Um9iDQo+ID4NCj4gPg0KPiANCj4gQW5keQ0KPiANCj4gDQo+ID4NCj4gPg0KPiA+DQo+ID4NCj4g Pj4gVGhhbmtzLA0KPiA+PiBSb2INCj4gPj4NCj4gPj4NCj4gPj4NCj4gPiBBbmR5DQo+ID4NCj4g Pg0KPiA+Pg0KPiA+Pg0KPiA+PiBBbmR5DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+DQo+ID4+PiBU aGFua3MNCj4gPj4+DQo+ID4+PiBNYWhlc2ggSmV0aGFuYW5kYW5pDQo+ID4+PiBtamV0aGFuYW5k YW5pQGdtYWlsLmNvbQ0KPiA+Pj4NCj4gPj4+ID4gT24gRmViIDUsIDIwMTgsIGF0IDk6NDMgQU0s IE1hcnRpbiBCam9ya2x1bmQgPG1iakB0YWlsLWYuY29tPiB3cm90ZToNCj4gPj4+ID4NCj4gPj4+ ID4gSGksDQo+ID4+PiA+DQo+ID4+PiA+IE1haGVzaCBKZXRoYW5hbmRhbmkgPG1qZXRoYW5hbmRh bmlAZ21haWwuY29tPiB3cm90ZToNCj4gPj4+ID4+IFRoaXMgY2xvc2VzIHRoZSBMQyBmb3IgdGhl IHR3byBORE1BIGRyYWZ0cyBmb3IgTkVUQ09ORiBhbmQgUkVTVENPTkYuDQo+ID4+PiA+Pg0KPiA+ Pj4gPj4gQXMgcGFydCBvZiB0aGUgTEMsIHRoZXJlIHdlcmUgYSBjb3VwbGUgb2YgY29tbWVudHMv cXVlc3Rpb25zDQo+ID4+PiA+PiByYWlzZWQuIEluIHBhcnRpY3VsYXINCj4gPj4+ID4+DQo+ID4+ PiA+PiAtIFZsYWRtaXIgcmVwb3J0ZWQgYW4gZXJyb3IsIHdoaWNoIE1hcnRpbiBzYWlkIGlzIGZp eGVkIGluIGhpcyBsb2NhbA0KPiA+Pj4gY29weS4NCj4gPj4+ID4NCj4gPj4+ID4gRml4ZWQuDQo+ ID4+PiA+DQo+ID4+PiA+PiAtIFJvYmVydCBzdWdnZXN0ZWQgdGhhdCDigJwveWFuZy1saWJyYXJ5 L2NoZWNrc3Vt4oCdIHNob3VsZCBiZSBhDQo+ID4+PiA+PiAgcmVmZXJlbmNlLiBKdWVyZ2VuIHN1 cHBvcnRlZCB0aGF0IGNvbW1lbnQsIHNvIEkgYW0gYXNzdW1pbmcgdGhhdA0KPiA+Pj4gPj4gIHRo YXQgd2lsbCBiZSBpbmNvcnBvcmF0ZWQgaW50byB0aGUgZHJhZnQuDQo+ID4+PiA+DQo+ID4+PiA+ IFllcywgZml4ZWQuDQo+ID4+PiA+DQo+ID4+PiA+PiAtIEFuZHkgaGFkIHF1ZXN0aW9ucyBhcm91 bmQgZGF0YXN0b3JlIHNldCB0byDigJxjb252ZW50aW9uYWzigJ0NCj4gPj4+ID4NCj4gPj4+ID4g Rml4ZWQuDQo+ID4+PiA+DQo+ID4+PiA+PiAgLCBhYm91dCBvcmlnaW4gZmlsdGVyIGxpbWl0ZWQg dG8gMSBzb3VyY2UNCj4gPj4+ID4NCj4gPj4+ID4gRml4ZWQuDQo+ID4+PiA+DQo+ID4+PiA+PiAg YW5kIHRoZSBiZWhhdmlvciBvZiB3aXRoLWRlZmF1bHRzLg0KPiA+Pj4gPg0KPiA+Pj4gPiBUaGVy ZSB3ZXJlIG5vIGFkZGl0aW9uYWwgY2hhbmdlcyB0byB0aGUgZG9jdW1lbnQgZnJvbSB0aGUgZGlz Y3Vzc2lvbg0KPiA+Pj4gPiBhYm91dCB0aGlzLg0KPiA+Pj4gPg0KPiA+Pj4gPj4gIEkgc2VlIHNv bWUgZGlzY3Vzc2lvbiBhcm91bmQgaXQgd2l0aCB0aGUgYXV0aG9ycw0KPiA+Pj4gPj4gIGFncmVl aW5nIHRoYXQgc29tZSBvZiB0aGVtIG5lZWQgc29tZSB0ZXh0IGNsYXJpZnlpbmcgdGhlDQo+ID4+ PiA+PiAgcG9zaXRpb24uIENhbiB0aGUgYXV0aG9ycyBwbGVhc2UgcG9zdCB0aGUgc3VnZ2VzdGVk IHRleHQvYWRkaXRpb25zDQo+ID4+PiA+PiAgZm9yIHRoZSBXRyB0byByZXZpZXcuDQo+ID4+PiA+ PiAtIEFueXRoaW5nIGVsc2U/Pw0KPiA+Pj4gPj4NCj4gPj4+ID4+IE9uY2UgYW4gdXBkYXRlZCBk cmFmdCBoYXMgYmVlbiBwb3N0ZWQsIEkgd2lsbCBkbyBhIHdyaXRldXAgb24gdGhlDQo+ID4+PiA+ PiBkcmFmdHMgYW5kIHNlbmQgaXQgdG8gSUVTRy4NCj4gPj4+ID4NCj4gPj4+ID4gVGhlIGlzc3Vl cyBhYm92ZSBhcmUgbm93IGFkZHJlc3NlZCwgaW4NCj4gPj4+ID4gZHJhZnQtaWV0Zi1uZXRjb25m LW5tZGEtbmV0Y29uZi0wMy4NCj4gPj4+ID4NCj4gPj4+ID4gVGhlcmUgd2VyZSBubyBhZGRpdGlv bmFsIGNvbW1lbnRzIG9uDQo+ID4+PiA+IGRyYWZ0LWlldGYtbmV0Y29uZi1ubWRhLXJlc3Rjb25m LTAyLCBzbyBJIGJlbGlldmUgdGhpcyB2ZXJzaW9uIGlzDQo+ID4+PiA+IHJlYWR5Lg0KPiA+Pj4g Pg0KPiA+Pj4gPg0KPiA+Pj4gPiAvbWFydGluDQo+ID4+PiA+DQo+ID4+PiA+DQo+ID4+PiA+Pg0K PiA+Pj4gPj4gVGhhbmtzLg0KPiA+Pj4gPj4NCj4gPj4+ID4+PiBPbiBKYW4gMzEsIDIwMTgsIGF0 IDEwOjE2IEFNLCBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgPA0KPiA+Pj4gai5zY2hvZW53YWVsZGVy QGphY29icy11bml2ZXJzaXR5LmRlPiB3cm90ZToNCj4gPj4+ID4+Pg0KPiA+Pj4gPj4+IE9uIFdl ZCwgSmFuIDMxLCAyMDE4IGF0IDA0OjUzOjQ4UE0gKzAwMDAsIEVyaWMgVm9pdCAoZXZvaXQpIHdy b3RlOg0KPiA+Pj4gPj4+Pg0KPiA+Pj4gPj4+PiBJIGRvIGhhdmUgb25lIGFkZGl0aW9uYWwgdGhv dWdodCBiZWxvdyBvbg0KPiA+Pj4gZHJhZnQtaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVz IHNlY3Rpb24gNS4zIGRlZmF1bHQgaGFuZGxpbmcNCj4gPj4+IHByb2Nlc3MuICBTZWUgaW4tbGlu ZS4uLg0KPiA+Pj4gPj4+Pg0KPiA+Pj4gPj4+DQo+ID4+PiA+Pj4gV2VsbCwgdGhpcyBkb2N1bWVu dCBpcyB3aXRoIHRoZSBSRkMgZWRpdG9yIG5vdy4gSSBkbyBub3QgdGhpbmsgaXQNCj4gPj4+IG5l ZWRzDQo+ID4+PiA+Pj4gY2xhcmlmaWNhdGlvbi4gSXQgYWxyZWFkeSBoYXMgdGV4dCBpbiA1LjMg c3VjaCBhczoNCj4gPj4+ID4+Pg0KPiA+Pj4gPj4+ICBSZXF1ZXN0cyB0byByZXRyaWV2ZSBub2Rl cyBmcm9tIDxvcGVyYXRpb25hbD4gYWx3YXlzIHJldHVybiB0aGUNCj4gPj4+IHZhbHVlDQo+ID4+ PiA+Pj4gIGluIHVzZSBpZiB0aGUgbm9kZSBleGlzdHMsIHJlZ2FyZGxlc3Mgb2YgYW55IGRlZmF1 bHQgdmFsdWUgc3BlY2lmaWVkDQo+ID4+PiA+Pj4gIGluIHRoZSBZQU5HIG1vZHVsZS4gIElmIG5v IHZhbHVlIGlzIHJldHVybmVkIGZvciBhIGdpdmVuIG5vZGUsIHRoZW4NCj4gPj4+ID4+PiAgdGhp cyBpbXBsaWVzIHRoYXQgdGhlIG5vZGUgaXMgbm90IHVzZWQgYnkgdGhlIGRldmljZS4NCj4gPj4+ ID4+Pg0KPiA+Pj4gPj4+IC9qcw0KPiA+Pj4gPj4+DQo+ID4+PiA+Pj4+IEZyb206IFJvYmVydCBX aWx0b24gLVgsIEphbnVhcnkgMzEsIDIwMTggNjozMSBBTQ0KPiA+Pj4gPj4+Pg0KPiA+Pj4gPj4+ Pg0KPiA+Pj4gPj4+PiBIaSBBbmR5LA0KPiA+Pj4gPj4+Pg0KPiA+Pj4gPj4+PiBPbiAzMS8wMS8y MDE4IDA5OjIyLCBBbmR5IEJpZXJtYW4gd3JvdGU6DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+DQo+ ID4+PiA+Pj4+IE9uIFdlZCwgSmFuIDMxLCAyMDE4IGF0IDEyOjExIEFNLCBKdWVyZ2VuIFNjaG9l bndhZWxkZXIgPA0KPiA+Pj4gai5zY2hvZW53YWVsZGVyQGphY29icy11bml2ZXJzaXR5LmRlIDxt YWlsdG86ai5zY2hvZW53YWVsZGVyQGphY29icw0KPiA+Pj4gLXVuaXZlcnNpdHkuZGU+PG1haWx0 bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZlcnNpdHkuZGUgPG1haWx0bzoNCj4gPj4+IGou c2Nob2Vud2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4+PiB3cm90ZToNCj4gPj4+ID4+Pj4+ IE9uIFR1ZSwgSmFuIDMwLCAyMDE4IGF0IDEyOjM1OjMzUE0gLTA4MDAsIEFuZHkgQmllcm1hbiB3 cm90ZToNCj4gPj4+ID4+Pj4+IEhpLA0KPiA+Pj4gPj4+Pj4NCj4gPj4+ID4+Pj4+IEkgaGF2ZSBz b21lIHF1ZXN0aW9ucyBhYm91dCB0aGVzZSBkcmFmdHMuDQo+ID4+PiA+Pj4+Pg0KPiA+Pj4gPj4+ Pj4gMSkgd2hhdCBpZiBkYXRhc3RvcmUgc2V0IHRvICJjb252ZW50aW9uYWwiPw0KPiA+Pj4gPj4+ Pj4gICBUaGVyZSBhcmUgbWFueSBwbGFjZXMgd2hlcmUgYSBkYXRhc3RvcmUtcmVmIHR5cGUgaXMg dXNlZC4NCj4gPj4+ID4+Pj4+ICAgSG93ZXZlciwgImNvbnZlbnRpb25hbCIgaXMgdmFsaWQgZm9y IGJhc2UgImRhdGFzdG9yZSIsIGV2ZW4NCj4gPj4+IHRob3VnaA0KPiA+Pj4gPj4+Pj4gICBpdCBp cyBhbWJpZ3VvdXMgYXMgYSBkYXRhc3RvcmUgc2VsZWN0b3IuDQo+ID4+PiA+Pj4+DQo+ID4+PiA+ Pj4+IFdlIGNhbiBhZGQgZXhwbGljaXQgdGV4dCB0aGF0IGFuIGlkZW50aXR5IHRoYXQgZG9lcyBu b3QgcmVzb2x2ZSB0byBhDQo+ID4+PiA+Pj4+IGRhdGFzdG9yZSBpbXBsZW1lbnRlZCBieSB0aGUg c2VydmVyIHJlc3VsdHMgaW4gYW4gaW52YWxpZCB2YWx1ZQ0KPiA+Pj4gZXJyb3IuDQo+ID4+PiA+ Pj4+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IE9LDQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+DQo+ ID4+PiA+Pj4+PiAyKSBvcmlnaW4gZmlsdGVyIGlzIGxpbWl0ZWQgdG8gMSBzb3VyY2UNCj4gPj4+ ID4+Pj4+ICBUaGlzIGZpbHRlcmluZyBzZWVtcyByYXRoZXIgbGltaXRlZC4gIEEgY2xpZW50IG11 c3QgcmV0cmlldmUNCj4gPj4+ID4+Pj4+IDx3aXRoLW9yaWdpbj4gYW5kIGNoZWNrDQo+ID4+PiA+ Pj4+PiAgIGFsbCB0aGUgdmFsdWVzIGluIHVzZSwgdGhlbiBtYWtlIHJlcGVhdGVkIHJlcXVlc3Rz IGZvciBlYWNoDQo+ID4+PiBzb3VyY2UgYXMgYQ0KPiA+Pj4gPj4+Pj4gZGlmZmVyZW50DQo+ID4+ PiA+Pj4+PiAgIDxvcmlnaW4tZmlsdGVyPiBsZWFmDQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IElm IHRoZSBjbGllbnQgZG9lcyA8d2l0aC1vcmlnaW4+LCB0aGVuIGl0IGhhcyBhbGwgb3JpZ2luIGlu Zm9ybWF0aW9uDQo+ID4+PiA+Pj4+IGFuZCBpdCBjYW4gZmlsdGVyIGxvY2FsbHkuIFRoYXQgc2Fp ZCwgd2UgY291bGQgbWFrZSBvcmlnaW4tZmlsdGVyIGENCj4gPj4+ID4+Pj4gbGVhZi1saXN0IHdo aWNoIGlzIGxvZ2ljYWxseSBPUmVkIHNvIHRoYXQgb25lIGNhbiByZXRyaWV2ZQ0KPiA+Pj4gPj4+ PiBvcmlnaW4tZmlsdGVyPW9yOnN5c3RlbSBvciBvcmlnaW4tZmlsdGVyPW9yOmxlYXJuZWQgaW4g b25lIHJlcXVlc3QuDQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IE9LDQo+ID4+ PiA+Pj4+DQo+ID4+PiA+Pj4+PiAzKSB3aXRoLWRlZmF1bHRzIGJyb2tlbg0KPiA+Pj4gPj4+Pj4g ICBUaGUgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIGRvZXMgbm90IHN1cHBvcnQgd2l0aC1kZWZhdWx0 cy4NCj4gPj4+ID4+Pj4+ICAgIEluc3RlYWQsIHRoZSBjbGllbnQgbXVzdCB1c2Ugb3JpZ2luLWZp bHRlcj1vcjpkZWZhdWx0IG9yDQo+ID4+PiB3aXRoLW9yaWdpbg0KPiA+Pj4gPj4+Pj4gICAgYW5k IGNoZWNrIGFsbCB0aGUgb3JpZ2luIGF0dHJpYnV0ZXMuICBTaW5jZSBhIGNsaWVudCBuZWVkcyB0 bw0KPiA+Pj4gdXNlDQo+ID4+PiA+Pj4+PiAgICB3aXRoLWRlZmF1bHRzIGZvciBvdGhlciBkYXRh c3RvcmVzLCB0aGlzIHNwZWNpYWwgaGFuZGxpbmcgb2YNCj4gPj4+ID4+Pj4+IDxvcGVyYXRpb25h bD4NCj4gPj4+ID4+Pj4+ICAgIHNlZW1zIHVuaGVscGZ1bC4NCj4gPj4+ID4+Pj4NCj4gPj4+ID4+ Pj4gSSB0aGluayB0aGUgd2l0aC1kZWZhdWx0cyBzZW1hbnRpY3MgZm9yIGNvbnZlbnRpb25hbCBj b25maWd1cmF0aW9uDQo+ID4+PiA+Pj4+IGRhdGFzdG9yZXMgYXJlIG11Y2ggbW9yZSBjb21wbGlj YXRlZCB0aGFuIG5lY2Vzc2FyeSBmb3IgdGhlDQo+ID4+PiA+Pj4+IG9wZXJhdGlvbmFsIHN0YXRl IGRhdGFzdG9yZS4gTm90ZSB0aGF0IHRoYXQgdGhlIG9wZXJhdGlvbmFsIHN0YXRlDQo+ID4+PiA+ Pj4+IGRhdGFzdG9yZSByZXBvcnRzIGluLXVzZSB2YWx1ZXMgbm90IHJlYWxseSBkZWZhdWx0czoN Cj4gPj4+ID4+Pj4NCj4gPj4+ID4+Pj4gPGxlYWYgb3I6b3JpZ2luPSdkZWZhdWx0Jz5mb288L2xl YWY+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IFRoaXMgcmVwb3J0cyB0aGF0IHRoZSB2YWx1ZSAn Zm9vJyBpcyBpbiB1c2UgYW5kIHRoYXQgaXQgb3JpZ2luYXRlcw0KPiA+Pj4gPj4+PiBmcm9tIGEg ZGVmYXVsdCB2YWx1ZS4gTm90ZSB0aGF0IHRoaXMgY291bGQgYWxzbyBiZQ0KPiA+Pj4gPj4+Pg0K PiA+Pj4gPj4+PiA8bGVhZiBvcjpvcmlnaW49J2ludGVuZGVkJz5mb288L2xlYWY+DQo+ID4+PiA+ Pj4+DQo+ID4+PiA+Pj4+IGluIGNhc2UgdGhlIGludGVuZGVkIGNvbmZpZ3VyYXRpb24gZGF0YXN0 b3JlIGNvbmZpZ3VyZWQgdGhlIHZhbHVlDQo+ID4+PiA+Pj4+ICdmb28nIChkZXNwaXRlIHRoaXMg dmFsdWUgbWF0Y2hpbmcgdGhlIGRlZmF1bHQpLiBUaGUgd2l0aC1kZWZhdWx0cw0KPiA+Pj4gPj4+ PiBzb2x1dGlvbiBpcyBwcmV0dHkgY29tcGxleCBiZWNhdXNlIGl0IHRyaWVzIHRvIGhhbmRsZSBo b3cgZGlmZmVyZW50DQo+ID4+PiA+Pj4+IHN5c3RlbXMgZGVhbCB3aXRoIGNvbmZpZ3VyYXRpb24g ZGVmYXVsdHMuIFRoZSBpZGVhIGlzIHRvIG5vdCBjYXJyeQ0KPiA+Pj4gPj4+PiB0aGlzIGNvbXBs ZXhpdHkgb3ZlciB0byBpbi11c2UgdmFsdWVzIGluIHRoZSBvcGVyYXRpb25hbCBzdGF0ZQ0KPiA+ Pj4gPj4+PiBkYXRhc3RvcmUuDQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IEJl Zm9yZSBOTURBLCB0aGUgY2xpZW50IGNvdWxkIGRlY2lkZSBpZiBpdCB3YW50ZWQgdG8gcmV0cmll dmUNCj4gPj4+IGRlZmF1bHQgbm9kZXMgb3Igbm90Lg0KPiA+Pj4gPj4+PiBUaGlzIGNsaWVudC1j aG9pY2UgaGFzIGJlZW4gcmVtb3ZlZCBmcm9tIE5NREEsIHdoaWNoIGlzIGEgcHJvYmxlbS4NCj4g Pj4+ID4+Pj4gV2UgdHJpZWQgdG8gcmVhY2ggYSBzZW5zaWJsZSBjb21wcm9taXNlIG9uIHRoZSBk YXRhIHJldHVybmVkIGZyb20NCj4gPj4+IG9wZXJhdGlvbmFsIChkZWZpbmVkIGluIHNlY3Rpb24g NS4zIG9mIHRoZSBOTURBIGFyY2hpdGVjdHVyZSk6DQo+ID4+PiA+Pj4+IC0gaXQgc2hvdWxkIHJl dHVybiBleHBsaWNpdCB2YWx1ZXMgZm9yIGV2ZXJ5dGhpbmcgdGhhdCBpcyBhZmZlY3RpbmcNCj4g Pj4+IHRoZSBhY3R1YWwgcnVubmluZyBzdGF0ZSBvZiB0aGUgZGV2aWNlIChyZWdhcmRsZXNzIG9m IHdoZXRoZXIgdGhlDQo+ID4+PiBvcGVyYXRpb25hbCB2YWx1ZSBtYXRjaGVzIGEgc2NoZW1hIGRl ZmF1bHQgdmFsdWUpLg0KPiA+Pj4gPj4+PiAtIGl0IGRvZXMgbm90IG5lZWQgdG8sIGFuZCBzaG91 bGQgbm90LCByZXR1cm4gb3BlcmF0aW9uYWwgdmFsdWVzDQo+ID4+PiBmb3Igc3R1ZmYgdGhhdCBp c24ndCBhY3R1YWxseSBpbiB1c2UsIGkuZS4gZG9uJ3QgcmV0dXJuIG5lZWRsZXNzIGFuZA0KPiA+ Pj4gdW53YW50ZWQgZGF0YS4NCj4gPj4+ID4+Pj4NCj4gPj4+ID4+Pj4gSW4gcGFydGljdWxhciwg aWYgbm8gdmFsdWUgaXMgcmV0dXJuZWQgZnJvbSBhIHBhcnRpY3VsYXIgZGF0YSBub2RlDQo+ID4+ PiBpbiA8b3BlcmF0aW9uYWw+IHRoZW4sIGJhcnJpbmcgbWdtdCBwcm90b2NvbCBlcnJvcnMsIGEg Y2xpZW50IGNhbiBhc3N1bWUNCj4gPj4+IHRoYXQgYW55IGZ1bmN0aW9uYWxpdHkgYXNzb2NpYXRl ZCB3aXRoIHRoYXQgZGF0YSBub2RlIGlzIG9mZiAoaS5lLiBub3QgaW4NCj4gPj4+IHVzZSkuDQo+ ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IFNvbWUgZXhhbXBsZXMgdG8gaWxsdXN0cmF0ZSB0aGUgYmVo YXZpb3I6DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IChpKSBJZiBhIHByb3RvY29sLCBlLmcuIE9T UEYsICBpcyBub3QgZW5hYmxlZC9ydW5uaW5nIHRoZW4NCj4gPj4+IDxvcGVyYXRpb25hbD4gZG9l cyBub3QgbmVlZCB0byByZXR1cm4gYW55IGRhdGEgZm9yIGl0LiAgSXQgd291bGQgYmUNCj4gPj4+ IHJlYXNvbmFibGUgdG8gcmV0dXJuIGEgZmxhZyB0byBpbmRpY2F0ZSB0aGF0IE9TUEYgaXMgbm90 IGVuYWJsZWQvcnVubmluZy4NCj4gPj4+ID4+Pj4NCj4gPj4+ID4+Pj4gKGlpKSBJZiB5b3UgaGF2 ZSBzb21lIGZ1bmt5IHdpZGdldCBvbiBhbiBpbnRlcmZhY2UgdGhhdCBkZWZhdWx0cyB0bw0KPiA+ Pj4gYmVpbmcgb2ZmIGFuZCBpc24ndCBiZWluZyB1c2VkIHRoZW4gPG9wZXJhdGlvbmFsPiBkb24n dCBuZWVkIHRvIHJldHVybiBhbnkNCj4gPj4+IGRhdGEgZm9yIGl0Lg0KPiA+Pj4gPj4+Pg0KPiA+ Pj4gPj4+PiAoaWlpKSBCdXQsIGlmIHlvdSBoYXZlIHNvbWUgZnVua3kgd2lkZ2V0IG9uIGFuIGlu dGVyZmFjZSB0aGF0DQo+ID4+PiBkZWZhdWx0cyB0byBiZWluZyBvbiwgdGhlbiB0aGUgc2VydmVy IHNob3VsZCByZXR1cm4gZGF0YSBmb3IgaXQuIElmIGl0IGlzDQo+ID4+PiBhY3R1YWxseSBlbmFi bGVkLCB0aGVuIGl0IHdvdWxkIGluZGljYXRlIHRoYXQgaXQgaXMgb24gYW5kIHJldHVybiBhbnkN Cj4gPj4+IGFzc29jaWF0ZWQgdmFsdWVzIHdpdGggaXRzIG9wZXJhdGlvbmFsIHN0YXRlLCBvciBp ZiBpdCBpcyBkaXNhYmxlZCB0aGVuIGl0DQo+ID4+PiBzaG91bGQgZXhwbGljaXRseSByZXBvcnQg dGhhdCBpdCBpcyBvZmYuDQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IChpdikgSSB3b3VsZCByZWdh cmQgdGhhdCBhbGwgYXBwbGllZCBjb25maWd1cmF0aW9uIGlzICJpbiB1c2UiIGJ5DQo+ID4+PiB0 aGUgc3lzdGVtLCBldmVuIGlmIGl0IG1hdGNoZXMgdGhlIGRlZmF1bHQgdmFsdWUsIGFuZCBoZW5j ZSBpdCBzaG91bGQgYmUNCj4gPj4+IHJlcG9ydGVkLg0KPiA+Pj4gPj4+Pg0KPiA+Pj4gPj4+Pg0K PiA+Pj4gPj4+PiBUaGlzIGJlaGF2aW9yIGZvciA8b3BlcmF0aW9uYWw+IGlzIG9idmlvdXNseSBz bGlnaHRseSBkaWZmZXJlbnQNCj4gPj4+IGZyb20gdGhlIGV4aXN0aW5nIHdpdGgtZGVmYXVsdCBo YW5kbGluZyB0aGF0IGlzIHN1cHBvcnRlZCBmb3IgY29uZmlndXJhdGlvbg0KPiA+Pj4gZGF0YXN0 b3Jlcy4gIEFzIEkgcmVjYWxsLCB0aGVyZSB3ZXJlIGEgY291cGxlIG9mIHJlYXNvbnMgdGhhdCB3 ZSBkZWNpZGVkIHRvDQo+ID4+PiBoYXZlIGEgZGlmZmVyZW50IGJlaGF2aW9yIGZvciA8b3BlcmF0 aW9uYWw+Og0KPiA+Pj4gPj4+PiAoYSkgdG8gaGF2ZSBjb25zaXN0ZW50IHNlbWFudGljcyBmb3Ig YWxsIHNlcnZlcnMsIHJhdGhlciB0aGFuDQo+ID4+PiBkaWZmZXJlbnQgc2VydmVycyBzdXBwb3J0 aW5nIGRpZmZlcmVudCB3aXRoLWRlZmF1bHRzIGJlaGF2aW9ycyAod2hpY2ggbWFrZXMNCj4gPj4+ IGxpZmUgaGFyZGVyIGZvciBjbGllbnRzIGJlY2F1c2UgdGhleSBtdXN0IGNvcGUgd2l0aCBhbGwg dmFyaWFudHMpLg0KPiA+Pj4gPj4+PiAoYikgdG8gcmVtb3ZlIGFueSBwb3RlbnRpYWwgYW1iaWd1 aXR5IGlmIGRhdGEgaXNuJ3QgcmV0dXJuZWQuICBJLmUuDQo+ID4+PiB3aXRoIHRoZSBleGlzdGlu ZyB3aXRoLWRlZmF1bHRzIHNlbWFudGljcyBpdCBpcyBub3QgY2xlYXIgdG8gbWUgdGhhdA0KPiA+ Pj4gc2VydmVycyB3aWxsIGFsd2F5cyByZXR1cm4gYW4gZXhwbGljaXQgdmFsdWUgdG8gaW5kaWNh dGUgdGhhdCBhIHBhcnRpY3VsYXINCj4gPj4+IHdpZGdldCBpcyBvZmYgaWYgdGhlIHNjaGVtYSBk ZWZpbmVzIHRoYXQgdGhlIGRlZmF1bHQgaXQgdGhhdCBpcyBlbmFibGVkLg0KPiA+Pj4gSWYgdGhl IHNlcnZlciBkb2Vzbid0IHN1cHBvcnQgYSBnaXZlbiB3aWRnZXQgYXQgYWxsLCBpdCBpcyBxdWl0 ZSBwbGF1c2libGUNCj4gPj4+IHRoYXQgaXQgd2lsbCBqdXN0IHJldHVybiBubyBkYXRhIGZvciBp dC4gIEluIHRoZW9yeSBmZWF0dXJlcy9kZXZpYXRpb25zDQo+ID4+PiBzaG91bGQgaGFuZGxlIHRo aXMsIGJ1dCB0aG9zZSBkb24ndCB3b3JrIHNvIHdlbGwgaWYgZGlmZmVyZW50IGxpbmVjYXJkcw0K PiA+Pj4gaGF2ZSBkaWZmZXJlbnQgY2FwYWJpbGl0aWVzLiAgSGVuY2UgYmVpbmcgZXhwbGljaXQg YWJvdXQgc3R1ZmYgdGhhdCBpcyBpbg0KPiA+Pj4gdXNlIHNlZW1zIG1vcmUgcm9idXN0Lg0KPiA+ Pj4gPj4+Pg0KPiA+Pj4gPj4+PiA8ZXJpYz4gVGhlc2UgYXJlIGdvb2QgZXhhbXBsZXMuICBJdCB3 b3VsZCBiZSBncmVhdCBpZiBzZWN0aW9uIDUuMw0KPiA+Pj4gY291bGQgYmUgdHdlYWtlZCB0byBt YWtlIGNsZWFyZXIgdGhlIHJlbGF0aW9uc2hpcCBiZXR3ZWVuIHJ1bm5pbmcgZGF0YXN0b3JlDQo+ ID4+PiBkZWZhdWx0cyBhbmQgb3RoZXIgb3BlcmF0aW9uYWwgZGF0YXN0b3JlIGRlZmF1bHRzIGZv ciB0aGUgc2FtZSB0cmVlLg0KPiA+Pj4gPj4+Pg0KPiA+Pj4gPj4+PiBGb3IgZXhhbXBsZSwgbGV0 4oCZcyBzYXkgSSBjcmVhdGUgYSBjb25maWd1cmVkIHN1YnNjcmlwdGlvbiwgYW5kIHRoZQ0KPiA+ Pj4gZGVmYXVsdCB0cmFuc3BvcnQgcHJvdG9jb2wgaXMgTkVUQ09ORi4gIE5FVENPTkYgd2lsbCBi ZSB1c2VkIGZvciB0aGF0DQo+ID4+PiBzdWJzY3JpcHRpb24gZXZlbiB0aG91Z2ggdGhlIG5vZGUg bWlnaHQgbm90IGJlIHBvcHVsYXRlZC4gIEluIHRoaXMgY2FzZSwNCj4gPj4+IHRoZSBvYmplY3Qg d291bGQgbm90IGFwcGVhciBpbiB0aGUgcnVubmluZyBkYXRhc3RvcmUsIGJ1dCBNVVNUKiBhcHBl YXIgaW4NCj4gPj4+IHRoZSBvcGVyYXRpb25hbCBkYXRhc3RvcmUgd2l0aCB0aGUgZGVmYXVsdCBv cmlnaW4gKGFzIGl0IGlzIGluLXVzZSkuDQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IFRoaXMgdG8g bWUgaXMgdGhlIGRlc2lyZWQgYmVoYXZpb3IgYXMgaXQgZG9lc27igJl0IGluY29ycmVjdGx5IGFk ZA0KPiA+Pj4gaW5mb3JtYXRpb24gdG8gdGhlIHJ1bm5pbmcgZGF0YXN0b3JlLCBidXQgc2hvd3Mg d2hhdCBpcyBpbi11c2Ugd2l0aGluDQo+ID4+PiBvcGVyYXRpb25hbC4gICBJIHN1c3BlY3Qgb3Ro ZXIgc3VjaCByZWxhdGlvbnNoaXBzIGZvciBvdGhlciBvcGVyYXRpb25hbA0KPiA+Pj4gdHJlZSBk ZWZhdWx0cyBjb3VsZCBiZSBhc3NlcnRlZCwgcGVyaGFwcyBiYXNlZCBvbiB0aGUgb3JpZ2luLg0K PiA+Pj4gPj4+Pg0KPiA+Pj4gPj4+PiAoKiBNYXliZSDigJhNVVNUIGV2ZW50dWFsbHnigJksIGFz IG9idmlvdXNseSB0aGVyZSBpcyBhIHRlbXBvcmFsDQo+ID4+PiByZWxhdGlvbnNoaXAgYmV0d2Vl biB0aGUgdHdvIGRhdGFzdG9yZXMuKQ0KPiA+Pj4gPj4+Pg0KPiA+Pj4gPj4+PiBFcmljDQo+ID4+ PiA+Pj4+DQo+ID4+PiA+Pj4+IFRoYW5rcywNCj4gPj4+ID4+Pj4gUm9iDQo+ID4+PiA+Pj4+DQo+ ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+ DQo+ID4+PiA+Pj4+IC9qcw0KPiA+Pj4gPj4+Pg0KPiA+Pj4gPj4+PiBBbmR5DQo+ID4+PiA+Pj4+ DQo+ID4+PiA+Pj4+IC0tDQo+ID4+PiA+Pj4+IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciAgICAgICAg ICAgSmFjb2JzIFVuaXZlcnNpdHkgQnJlbWVuIGdHbWJIDQo+ID4+PiA+Pj4+IFBob25lOiArNDkg NDIxIDIwMCAzNTg3ICAgICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8DQo+ID4+ PiBHZXJtYW55DQo+ID4+PiA8aHR0cHM6Ly9tYXBzLmdvb2dsZS5jb20vP3E9Q2FtcHVzK1Jpbmcr MSslN0MrMjg3NTkrQnJlbWVuKyU3QytHZXJtYW55JmVudHJ5PWdtYWlsJnNvdXJjZT1nPg0KPiA+ Pj4gPj4+PiBGYXg6ICAgKzQ5IDQyMSAyMDAgMzEwMyAgICAgICAgIDxodHRwczovL3d3dy5qYWNv YnMtdW5pdmVyc2l0eS5kZS8+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+DQo+ ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fDQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IG5ldG1vZCBt YWlsaW5nIGxpc3QNCj4gPj4+ID4+Pj4NCj4gPj4+ID4+Pj4gbmV0bW9kQGlldGYub3JnIDxtYWls dG86bmV0bW9kQGlldGYub3JnPjxtYWlsdG86bmV0bW9kQGlldGYub3JnDQo+ID4+PiA8bWFpbHRv Om5ldG1vZEBpZXRmLm9yZz4+DQo+ID4+PiA+Pj4+DQo+ID4+PiA+Pj4+IGh0dHBzOi8vd3d3Lmll dGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIDwNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPg0KPiA+Pj4gPj4+Pg0KPiA+Pj4gPj4+DQo+ID4+ PiA+Pj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ ID4+PiA+Pj4+IG5ldG1vZCBtYWlsaW5nIGxpc3QNCj4gPj4+ID4+Pj4gbmV0bW9kQGlldGYub3Jn IDxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPiA+Pj4gPj4+PiBodHRwczovL3d3dy5pZXRmLm9y Zy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZCA8DQo+ID4+PiBodHRwczovL3d3dy5pZXRmLm9yZy9t YWlsbWFuL2xpc3RpbmZvL25ldG1vZD4NCj4gPj4+ID4+Pg0KPiA+Pj4gPj4+DQo+ID4+PiA+Pj4g LS0NCj4gPj4+ID4+PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2 ZXJzaXR5IEJyZW1lbiBnR21iSA0KPiA+Pj4gPj4+IFBob25lOiArNDkgNDIxIDIwMCAzNTg3ICAg ICAgICAgQ2FtcHVzIFJpbmcgMSB8IDI4NzU5IEJyZW1lbiB8DQo+ID4+PiBHZXJtYW55DQo+ID4+ PiA8aHR0cHM6Ly9tYXBzLmdvb2dsZS5jb20vP3E9Q2FtcHVzK1JpbmcrMSslN0MrMjg3NTkrQnJl bWVuKyU3QytHZXJtYW55JmVudHJ5PWdtYWlsJnNvdXJjZT1nPg0KPiA+Pj4gPj4+IEZheDogICAr NDkgNDIxIDIwMCAzMTAzICAgICAgICAgPGh0dHBzOi8vd3d3LmphY29icy11bml2ZXJzaXR5LmRl LyA8DQo+ID4+PiBodHRwczovL3d3dy5qYWNvYnMtdW5pdmVyc2l0eS5kZS8+Pg0KPiA+Pj4gPj4+ DQo+ID4+PiA+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X18NCj4gPj4+ID4+PiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4+PiA+Pj4gbmV0bW9kQGlldGYu b3JnIDxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0KPiA+Pj4gPj4+IGh0dHBzOi8vd3d3LmlldGYu b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kIDwNCj4gPj4+IGh0dHBzOi8vd3d3LmlldGYub3Jn L21haWxtYW4vbGlzdGluZm8vbmV0bW9kPg0KPiA+Pj4gPj4gTWFoZXNoIEpldGhhbmFuZGFuaQ0K PiA+Pj4gPj4gbWpldGhhbmFuZGFuaUBnbWFpbC5jb20NCj4gPj4+ID4+DQo+ID4+Pg0KPiA+Pj4g X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4gPj4+IE5l dGNvbmYgbWFpbGluZyBsaXN0DQo+ID4+PiBOZXRjb25mQGlldGYub3JnDQo+ID4+PiBodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldGNvbmYNCj4gPj4+DQo+ID4+DQo+ID4+ DQo+ID4+DQo+ID4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fDQo+ID4+IE5ldGNvbmYgbWFpbGluZyBsaXN0TmV0Y29uZkBpZXRmLm9yZ2h0dHBzOi8vd3d3 LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0Y29uZg0KPiA+Pg0KPiA+Pg0KPiA+Pg0KPiA+ DQo+ID4NCg== From nobody Wed Feb 7 11:01:18 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC1791270B4 for ; Wed, 7 Feb 2018 11:01:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zrrePrPOQ01M for ; Wed, 7 Feb 2018 11:01:15 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 7F2C81270AB for ; Wed, 7 Feb 2018 11:01:15 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w17IxhQX005214; Wed, 7 Feb 2018 11:00:51 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=message-id : from : to : cc : subject : in-reply-to : mime-version : content-type : content-id : date; s=PPS1017; bh=PIodeuFwG5jvwL5YO9R8aN23BOFPnUF7WVFSOcA85BY=; b=TJpxR3lhjF8Bi6lusSrJ91lu1K+ekTdsnq5O7tbnDK0tjep57GL115GUWuLLytoPsKP5 Ort5FsgCA5eS8TkMbZy0HsBDi1f6zcTDfFeFec+2+NuHB4yjn8lAR86VJHEDlGM0ziKM lAIvj/Dwp2o96UBjZsoedm/UYtbhY1fjy436st0z69EeB/pXDexNN+BAJf5q9VqGsZGB CIgZt8kt71wTREHRJscpYuV0bfJcQ1zAzq7nmkDgCPQFniV/2xdMDFvl8xMI8+rtFaSc 4BFqmfymQw7dhi8RQME3VFQCHdLce5qWp/moT7c5iZAKNVs8QWucMpiOsly9yJbYIQs3 qw== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0052.outbound.protection.outlook.com [216.32.180.52]) by mx0a-00273201.pphosted.com with ESMTP id 2g06a203wb-3 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2018 11:00:51 -0800 Received: from SN4PR0501CA0059.namprd05.prod.outlook.com (2603:10b6:803:41::36) by BLUPR0501MB2067.namprd05.prod.outlook.com (2a01:111:e400:c475::25) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.7; Wed, 7 Feb 2018 19:00:42 +0000 Received: from DM3NAM05FT009.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::202) by SN4PR0501CA0059.outlook.office365.com (2603:10b6:803:41::36) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.485.3 via Frontend Transport; Wed, 7 Feb 2018 19:00:41 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by DM3NAM05FT009.mail.protection.outlook.com (10.152.98.115) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.485.5 via Frontend Transport; Wed, 7 Feb 2018 19:00:41 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 7 Feb 2018 10:59:43 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w17IxfU8003512; Wed, 7 Feb 2018 10:59:42 -0800 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.15.2/8.15.2) with ESMTP id w17IxjwU073675; Wed, 7 Feb 2018 13:59:46 -0500 (EST) (envelope-from phil@juniper.net) Message-ID: <201802071859.w17IxjwU073675@idle.juniper.net> From: Phil Shafer To: Andy Bierman CC: joel jaeggli , NETMOD Working Group In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <73673.1518029985.1@idle.juniper.net> Date: Wed, 7 Feb 2018 13:59:45 -0500 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39860400002)(39380400002)(2980300002)(189003)(199004)(7696005)(50466002)(6246003)(186003)(8276002)(53936002)(8676002)(81156014)(81166006)(106466001)(69596002)(8936002)(68736007)(54906003)(47776003)(26005)(77096007)(97736004)(336011)(316002)(105596002)(6916009)(16586007)(86362001)(53416004)(2950100002)(229853002)(76506005)(23726003)(97756001)(1076002)(46406003)(4326008)(478600001)(305945005)(356003)(7126002)(2810700001)(2906002)(5660300001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR0501MB2067; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT009; 1:JEghQaTIaEJKsI0xknksKrHMHjDy6I8X832eu6Ph+z77zT42tRxwMPvnV4QKmbkwK5e2sdm54aQf0G81TYVv39u7IGHgonkum2GbFDJqvljr9SMV40v+VAAJ0air4Qwb X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 974e1b2e-676c-498f-70c4-08d56e5d15a8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:BLUPR0501MB2067; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2067; 3:RoY4bMgW7FylUedzqXuf4wNeZgjEQLBb8A8cz59NuvjPa/If/UFFr6GXfeWNtcB5rAnIdOnXCSDTNiSDXa6uU6qHyZss4S0AZoomszzcHKJbNuIv6VzCMSgYAJuUohD5dCcrwVR8ElOx/grjxkTXKrpM28Mb7Mw/7JSGC5epe4/kRXmpBx4tbGThEUVITd+fDvhT4Is+nJcRFFJcJibVJ++GYeoOosTUj0vK/ucx3FF6XFv7pdf7Cv3Mux4x4F8kGbv793HnWEP0uBLw798rviwoPlajccUBOqWeyvhvlbF0jPddj8JTTPEV8PvFIKM82TOuFBijBymZhDk7d2cYB+hW5Zp7F50icHbIEOO8u54=; 25:eAH/QJxufvv71ZioZEx1yo9+BnW9OVy9WgLVWj47NiL5sB4mEEkODuwbMzE0YMXAZ4nNewrMtg0rNuUTqJONPwZWPIw3pCB3noXIfMz1ErAWwi4ESUmxBV3fPwhGbkZmBqYh2QJrhO7XfcR/SyZYA1Px6fbuweTpeluANUqkHw0Ko5a0ssPuezUNjPd62jDHL3+CcF2z9mDNyq6LFXG5qQhari7A0IhPV3dinyg3PkWeywvXke12QDpOBBYSWp3W3bjYsjg1pWK4sH0A5m8DHqD1KHJj8vGN3Cid3XAxSLp8EM428Pp3uNHrKyDDJQ0vE8uBPrADFfUCUmR9MLhusw== X-MS-TrafficTypeDiagnostic: BLUPR0501MB2067: X-LD-Processed: bea78b3c-4cdb-4130-854a-1d193232e5f4,ExtAddr X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2067; 31:T3zUVmPRHNI/rk4q49j3m5WdUFkL2pk6VaC8nHSjyY6NBJR9WIJgMtkliMgJLOmfBFSJrM3RP43fQ3zOYGLO/P8Ho7vSoZ/maggjwwdlNfvWsBTruEgNq4QGhTUVI4OQxYNPBZK60HDyjBPzhebZYkKiPxaYbR5pfkYDyrDi40L1uSwsyGvM8Pj1QNoX3t9yPH7z8eOrIiVKPFYM0C1qxOsIIpIB7sXv5/Jq4CmKuqg=; 20:0HOth/2NwadWX8Uj9FhRKbiy3VcApKUraNroIv1nxubOMlPq90jGEnDP0qTsyKMTV8aZ2qgKChPpY7/6laLzNOgGW8UdNBZIKzL23WPNA9WDzwMBUMUm1nep1NaJncHdX4oJJg6Hul4UxDyCxkrGtXSazcX+HVpM+8/yHp4yYG+/03Lm2EIRFcpkclwYX6QQpct20QNKfWci3itaNKXeAaJJijeQJVMp6Wvxto+0+ziJRikLM+NC5o3fB05aCIbUrduC0QMrLVlOwRWZp/wv1g3q03te4OXiue5034PE/ukG/AkmgcQcqv89kIVc4HGxvHIOEp+QTmOoKxT3aVDHNhd5lMN0YlF88YIXRqRh4n9DAiI/MwTGdo5KXjTYE9rEkjH+uXB9M4lS5qXOyIb0sqcborVcXyN9NM4Dc1w+wn4vgbqLFyMb3soFkykf1Tvh8Nt5zpDRSnqIxAb7riguY49JKeoNhEsvp17PDASo/qzUiTpmhBQFag0diW1YAquS X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231101)(2400082)(944501161)(3002001)(93006095)(93001095)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:BLUPR0501MB2067; BCL:0; PCL:0; RULEID:; SRVR:BLUPR0501MB2067; X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2067; 4:/HCgPWG0dLi+aHury2NZhXb5qrOhiurSDromZfi6CPAb6c17iNvKvKx9kw/1hAs7yKaQRWfuYNpnRYUUS/0mfBSXgrBTIvOpg1Ho8PeP/UdJoLSKFvvkQQmWyaAqo4SLLy4dT+mbPmOEXU2xg4N8sGF0FVJ8T+MT4LIBzzz3EPyMWfipcD5GX1mCnAApCJUVWvb55mJ0/TxsB7k15PRwy22s975Zd1bTtVYwJZ9dmNaUqId2WjYw4FQ+OEnKdmqr/uS2gGKfC2/YdCQgPbB5xe4LJfF3NNx306u3GrmRfZMe2UJgTYCHwxcWYHFmB2B3 X-Forefront-PRVS: 0576145E86 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; BLUPR0501MB2067; 23:Gu55AVjBQjvebZIvu+WzwGWm5gNq8fiWIuIxnOQ?= =?us-ascii?Q?1EAG14PmEfPBhZuCSNInb+idD2P86I93NXlgbvak5VKK/3+JMHbr3cQ3FE9a?= =?us-ascii?Q?zntJwNKZ4ecIZfa1U9Obm8jwVbVOv2muOuXuQWxJoDmHX6vP6Vf5+xhmrAFS?= =?us-ascii?Q?F85nn2UfgbryHIbl+GNGjdig3BBG58jFxtmEePCbyznXW0zRPdHRB8ZRXmx/?= =?us-ascii?Q?3kqkrPa3+RwGG6KAR8UP+16fn73Tkn/SvmzJDZcry5PoINdphH+xMSVSwQSl?= =?us-ascii?Q?bFhv/cEcaO8oJzSCICJ0HkM50od5sP2Fs0dhHKCsNFJoAIwo2hx0ldrxbPmj?= =?us-ascii?Q?vTcVk8e+c6QIHA1z0aQkG8gFMkPKq6TH92MxMZP7EXiWpC/iF8nlDlDA2a6O?= =?us-ascii?Q?Q82wnSFZZig0GunBMJPvKh6YICTA61Xylw4DC4mKESYWUO4DWxhGJ3mbW/Ly?= =?us-ascii?Q?cldqMmP85ChnT1RiSOnaN3Mo+hbo0IvWH2iz5p/e6B6/8qWjNx2QMaa/wHxR?= =?us-ascii?Q?SgBoDx5iRM0YYZszdjAxXnIvw6J+7WHN58r3t3kk+pKIS6zJYnnCkEWPRKhN?= =?us-ascii?Q?tdouwgdoP5sGJMZHl+ybc4plgLoB1LvmLKrYb3Y8k3GT4HZ7krj5WuD51E+0?= =?us-ascii?Q?w0s7VNIa9Nvrqs9+zIlRZhf46nHflM3BYO6k1SeD9c6l0sxJVNfqLTR2o/dq?= =?us-ascii?Q?J5ByJ9Ov/7rrJtqLdLkt2W3DPFlMurPwmaSC/PvypFLEf2lPkMlSNGZEt3gs?= =?us-ascii?Q?8TJ48oxHMWWjqp2+gi5bAV1Q2A79t9hOMoMwJzoIWUYYj9+8UnPF7wb8IcfW?= =?us-ascii?Q?g4ntRzxatbBoRS/zRqJg+7YIEJ4yV1l6dIGdH72J6ipabUjFU7gHJgSsRP3/?= =?us-ascii?Q?IwutCnlJ3R3yK4f8VRRajEO59jIXpG093Jtxt+/UwQlpqneNbvZKJgILv8iS?= =?us-ascii?Q?Bz10EfTaSDdB7arXtBZy+OPuLiwUQAsoATYftpvn2FRAp/aosHKA8tEv+D9f?= =?us-ascii?Q?ts0Xw92Lmp7e73lYZXniD365N4SX1CgpJXM50TmRB0Pt5wCTTTr1kX8jqGnK?= =?us-ascii?Q?GW8PqTS6Pd8h7X1fdlrPB530IXAbG4Rk/2I/qJIQ40f+MvYF3wYqpy18sYdH?= =?us-ascii?Q?flmvaaV9OcOs=3D?= X-Microsoft-Exchange-Diagnostics: 1; BLUPR0501MB2067; 6:/3Q+JaV0zmvFuenzZpMWHS7Eudcl1Kdfe+hK+AtL2nxYFRiPOKaT4H79BEYeY1CA46ZxWqJfz3MODj5eoAr4Bo5LHzd1noc7GHJ+y/3/C4wsb80fRo/l4ksCsa+3Q7aTvx+Ih54ZXsfR7oGzwoV+pO4crIj2/AHY0gt3grQNh6F2fMO3NVAHZ20VEe0u90JP82ekKbvEp1NtUW82W48UaqRsM3Z3iu9EZWG9mo0fkQNWYEVxg17pOsaQ+3d6guJZtgbtQE7C0uAnVL+9TVAbqIreafmZRuKf8VOkOqeKiS3XkMh0XYeIlIGHr3FGfubqm6JfnT4Vfd9vFXlniShxBlF5//7ZdkJYgqmYo+uVIL4=; 5:YbhYaY52G1ALyVo0R5zkHvKZjqUs2PlF/qObf9GDSb0qZKhDwHdVgHIG2XO8JAuyqZ1I1T0hv1+lIzyVCROQM+2Am7HRcAVpaMsgKUhn5wxPdbyjW2mvpiJ2GgcAdLumScn94aJneHGrTBros+bEfb+HJnFrOvkgpOEvVckuIhE=; 24:2dQMhunZR8utvPixJvf0thE2CPG99MC8g+GYsc7g35hTtmM3BPaIKrTfHRyapk/WR/C68Lz0Bk0710tpLuPSLDEAeNrWpNHJA228qjpVKqc=; 7:NH3DktMOXwD1RRYJ6C2B1+xjDKHoyVHbbIe0GJfd2iavzk8MzIHke/L+9UY9W7noRpunOtwT8iYa8eum57f/LrfDHm7gYphPF/x25eCeHYiui6EDNFYutMGpC7amNB2fuY/fvXwOpmDzIhrmbIp22uekLS4dUG/vK+WERX6qgS0dt3zhDRE804wW9y3WX8x6loiX4DJwLPc00e/gqdGCzxyU6L7duXrfaG/H/UMT4v7ob0MbizRY0u8Ug+euBRiK SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 07 Feb 2018 19:00:41.4042 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 974e1b2e-676c-498f-70c4-08d56e5d15a8 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.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR0501MB2067 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_06:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=2 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070241 Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 19:01:18 -0000 Andy Bierman writes: >The draft avoids discussion of any useful operations based on tags. Nor does it really clearly say "what" is being tagged. The absract talks about "used to help classify and organize modules", but the Introduction lacks any expansion on this. There's really no clear problem statement or a clear definition of why we need tags or what one would use them for. It would also be helpful to understand why "#hashtag" and the string format ("ietf:routing", "vendor:super-duper:...") are chosen over YANG identities. It seems like identity naming standards and inheritance would be good features. Also it's not clear why these would be configurable rather that controlled by the module author. I'd rather have the OAM standard YANG module say something like: module ietf-oam { import "ietf-category" { prefix ietf-category; } identify ietf-oam { base ietf-category:ietf-standard; description "This module category represents something OAM related."; } ietf-category:module-category ietf-oam; ... } The draft says: Implementations that do not support the reset rpc statement (whether at all, or just for a particular rpc or module) MUST respond with an YANG transport protocol-appropriate rpc layer error when such a statement is received. The entire idea of NETCONF/YANG is that the client _knows_ what it can safely send instead of tossing spaghetti at the wall until something sticks. Avoid programming-by-error-detection, which creates fragile infrastructure. Use "feature" to control optional portions of a YANG module. I'd suggest one feature for "reset" support and another for "read-only", since IMHO the idea of someone munging the categories of standard modules is, well, disconcerting. "Local" tags are not well explained. The idea of a user/admin tagging modules means that something is broken. Users shouldn't understand YANG modules. Users use applications, some of which are home-grown. Is "local" appropriate for my "audit interfaces" script? 6.1 is missing the list "module-tags". 9.1 advocates putting vital information in the description string, which is IMHO not a good idea. We want to put as much information in machine-readable format as possible, so I can ask ietf.org questions like "give me a list of ietf-oam-related yang modules" and get a nice list. It also talks about "SHOULD" and "MAY" tags without giving any clue as to why or when this would be appropriate or useful. So my vote would be that this document needs some significant work and expansion before it's a supportable draft. I think the authors have more in their heads than they've put into the draft and I'd like to see the rest of their thoughts. Thanks, Phil From nobody Wed Feb 7 12:28:06 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB153126D05 for ; Wed, 7 Feb 2018 12:28:05 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.531 X-Spam-Level: X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rBiv7wIuj_OR for ; Wed, 7 Feb 2018 12:28:03 -0800 (PST) Received: from rcdn-iport-6.cisco.com (rcdn-iport-6.cisco.com [173.37.86.77]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0EBF512751F for ; Wed, 7 Feb 2018 12:28:03 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11442; q=dns/txt; s=iport; t=1518035282; x=1519244882; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=inYwQZBMF6X/za5qsof+p9tWkBfg7Nt2EQk1FwWHolk=; b=Ij/LP/OYDy5vlubqtZubRbUiynwzxxLAwJQXH0XthfUmkNzD7PGOstCw RTB+eI8Qm9RPc0ILq6SeQU3K/FOm47JlhlEIfmECf+XW2RxWyzMccJD/l UiU1MkHgfkpviVVr7/LGr0qbWmCxaA70Wds/Vbo674jDd2nkRG8H4LoyU c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DLAAD7YHta/5FdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNRZnAoCoNbiiSOJoFbJ3yWVhWCAwofhRwCGoJPVBgBAgEBAQE?= =?us-ascii?q?BAQJrKIUjAQEBAwEjEToXBAIBCA4HAQQCJgICAjAVEAIEARKKLQixYIInhQCDe?= =?us-ascii?q?IIKAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPg2aCFYFXgWgpDIJDNoMvBIEoJQq?= =?us-ascii?q?DLzGCNAEEimqZPwkCiByNXYIeZ4VAi3mLEolBgwoCERkBgTsBHzmBUHAVPSoBg?= =?us-ascii?q?hsJhG54i1CBJYEXAQEB?= X-IronPort-AV: E=Sophos;i="5.46,473,1511827200"; d="scan'208";a="353255923" Received: from rcdn-core-9.cisco.com ([173.37.93.145]) by rcdn-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 07 Feb 2018 20:27:54 +0000 Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by rcdn-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id w17KRs47031581 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 7 Feb 2018 20:27:54 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 7 Feb 2018 14:27:53 -0600 Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1320.000; Wed, 7 Feb 2018 14:27:53 -0600 From: "Clyde Wildes (cwildes)" To: Kent Watsen , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt Thread-Index: AQHTi/jjJvmTWqOlt0ibymRgFNi7TqN3I0QAgAwuwXGAFVW8AIABSSEA Date: Wed, 7 Feb 2018 20:27:53 +0000 Message-ID: <5C6AA747-4459-408C-B5CA-12E2210D36EA@cisco.com> References: <151579789446.21777.985631371557420470@ietfa.amsl.com> <045f01d39534$c02ba480$4001a8c0@gateway.2wire.net> 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.154.131.46] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 20:28:06 -0000 S2VudCwNCg0KSSB3aWxsIHJlbW92ZSBUTFMgaWYgdGhhdCBpcyB0aGUgcHJlZmVyZW5jZSBvZiB0 aGUgY2hhaXIgYW5kIHRoZSB3b3JraW5nIGdyb3VwLg0KDQpSRkMgNjU4NyBjYW4gYmUgbWFkZSBJ bmZvcm1hdGlvbmFsLg0KDQpXb3JraW5nIHdpdGggYW4gZWRpdG9yIG1pZ2h0IGhlbHAgdG8gYXZv aWQgYWRkaXRpb25hbCByZXZpc2lvbnMuDQoNClVubGVzcyBJIGhlYXIgb3RoZXJ3aXNlIEkgd2ls bCBwb3N0IGFub3RoZXIgdXBkYXRlIG9uIEZyaWRheSB3aXRoIFRMUywgYW5kIGl0cyByZWZlcmVu Y2VzLCByZW1vdmVkIGFzIHdlbGwgYXMgdGhlIGNoYW5nZSB0byBtYWtlIFJGQyA2NTg3IGluZm9y bWF0aW9uYWwuDQoNClRoYW5rcywNCg0KQ2x5ZGUNCg0KDQpPbiAyLzYvMTgsIDQ6NDkgUE0sICJL ZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KDQogICAgSGkgQ2x5ZGUs DQogICAgDQogICAgVGhlIGNoYWlycyB3ZXJlIGRpc2N1c3NpbmcgdGhlIEhJU1RPUklDIHJlZmVy ZW5jZSB0byBSRkMgNjU4Ny4gICBBcyB3ZSB1bmRlcnN0YW5kIGl0LCBSRkMgNjU4NyB3YXMgYWN0 dWFsbHkgb3JpZ2luYWxseSBwdWJsaXNoZWQgYXMgYSBISVNUT1JJQyBkb2N1bWVudCB0byBhY2Nv bW1vZGF0ZSBTZWN1cml0eSBhcmVhIGNvbmNlcm5zLiAgQXBwYXJlbnRseSwgQmVub2l0IHdhcyBB RCBhdCB0aGUgdGltZSwgc28gaGUgbWF5IHJlY2FsbC4gIFRoZSBJRVRGIHRvb2sgc3BlY2lhbCBl ZmZvcnQgdG8gcHVibGlzaCBSRkMgNjU4NyBhbnl3YXksIGxpa2VseSBkdWUgdG8gVENQIGJlaW5n IGluIGNvbW1vbiB1c2UuICBBbnl3YXksIHdlJ3JlIHdvbmRlcmluZywgbXVzdCB0aGlzIGRvY3Vt ZW50IGhhdmUgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJGQyA2NTg3PyAgLSBjb3VsZCBpdCBi ZSBtYWRlIEluZm9ybWF0aW9uYWwgaW5zdGVhZD8gIElzIHVuZGVyc3RhbmRpbmcgUkZDIDY1ODcg bmVjZXNzYXJ5IHRvIGltcGxlbWVudCB0aGUgc3lzbG9nIGRyYWZ0Pw0KICAgIA0KICAgIFdlIGFs c28gZGlzY3Vzc2VkIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlcyB0byB0aGUga2V5c3RvcmUtYW5k LWZyaWVuZHMgZHJhZnRzLiAgIEFzIGl0IHN0YW5kcywgbXkgc2hlcGhlcmQgd3JpdGUtdXAgaXMg Z29pbmcgdG8gaGF2ZSB0byBjYWxsIHRoZXNlIG91dCBhcyB1bnN0YWJsZSBkZXBlbmRlbmNpZXMu ICAgSSBrbm93IHRoYXQgaXQgd2FzIGRpc2N1c3NlZCBiZWZvcmUsIGJ1dCB3b3VsZCB5b3UgaGF2 ZSBhbnkgYXBwZXRpdGUgdG8gcmV2aXNpdCBoYXZpbmcgVExTIGluIHRoZSBmaXJzdCB2ZXJzaW9u IG9mIHRoaXMgbW9kdWxlPyAgUGVyaGFwcyBpdCBjb3VsZCBiZSBwaWNrZWQgaXQgdXAgaW4gYSBi aXM/DQogICAgDQogICAgV2hlbiBjYW4geW91IHBvc3QgYW4gdXBkYXRlPyAgV291bGQgeW91IHJh dGhlciB1cyBhcHBvaW50IGFuIEVkaXRvciB0byBoZWxwIGdldCBpdCBkb25lIHNvb25lcj8gIEkg dGhpbmsgdGhhdCB3ZSd2ZSBiZWVuIGluIHRoaXMgcG9zdC1MQyBwaGFzZSBmb3IgbmVhcmx5IGZv dXIgbW9udGhzIG5vdy4uLg0KICAgIA0KICAgIEtlbnQgLy8gc2hlcGhlcmQNCiAgICANCiAgICAN CiAgICA9PT09PSBvcmlnaW5hbCBtZXNzYWdlID09PT09DQogICAgDQogICAgS2VudA0KICAgIA0K ICAgIE15IHJlcXVlc3QgZm9yIGEgcmVmZXJlbmNlIGZvciBQb3NpeCBocyBiZWVuIGZpeGVkIGlu IC0xOS4NCiAgICANCiAgICBUb20gUGV0Y2gNCiAgICANCiAgICAtLS0tLSBPcmlnaW5hbCBNZXNz YWdlIC0tLS0tDQogICAgRnJvbTogIktlbnQgV2F0c2VuIiA8a3dhdHNlbkBqdW5pcGVyLm5ldD4N CiAgICBUbzogPG5ldG1vZEBpZXRmLm9yZz4NCiAgICBTZW50OiBUdWVzZGF5LCBKYW51YXJ5IDE2 LCAyMDE4IDQ6NTkgUE0NCiAgICANCiAgICA+IENseWRlLA0KICAgID4NCiAgICA+IFRoaXMgZHJh ZnQgc3RpbGwgaXNuJ3QgcGFzc2luZyBpZG5pdHMuICBJIHByb3ZpZGVkIHRoZSBsaW5rIHRvIGlk bml0cw0KICAgIHByZXZpb3VzbHksIGJ1dCBoZXJlIGl0IGlzIGFnYWluOiBodHRwczovL3VybGRl ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ190b29s c19pZG5pdHMmZD1Ed0lDQXcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRY Y1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPXZC OEdlbnU0STduT3U5QjdsS3o1bVdXWUNCdXVId21nbjBISXplUEFrNlEmcz1ISGE0S2c3Wm9YT3o2 dUM5VmtpVF8tak1lR2RXOUtiZm8xQ3lkaVQ0Yk04JmU9Lg0KICAgIEJlbG93IGlzIHRoZSBpZG5p dHMgb3V0cHV0IGZvciAtMTkgd2l0aCBpbmxpbmVkIGNvbW1lbnRzLg0KICAgID4NCiAgICA+IFBT OiBJIGRpZG4ndCBhbHNvIGNoZWNrZWQgdGhlIG90aGVyIGlzc3VlcyB3ZSdyZSB0cmFja2luZywg YnV0IHdpbGwNCiAgICB3aGVuIHdlIGdldCBwYXN0IHRoZXNlIGlkbml0cyBpc3N1ZXMuDQogICAg Pg0KICAgID4gS2VudA0KICAgID4NCiAgICA+DQogICAgPiA9PT09PSBTVEFSVCA9PT09PQ0KICAg ID4gaWRuaXRzIDIuMTUuMDANCiAgICA+DQogICAgPiAvdG1wL2RyYWZ0LWlldGYtbmV0bW9kLXN5 c2xvZy1tb2RlbC0xOS50eHQ6DQogICAgPg0KICAgID4gICBDaGVja2luZyBib2lsZXJwbGF0ZSBy ZXF1aXJlZCBieSBSRkMgNTM3OCBhbmQgdGhlIElFVEYgVHJ1c3QgKHNlZQ0KICAgID4gICBodHRw czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3RydXN0ZWUu aWV0Zi5vcmdfbGljZW5zZS0yRGluZm8mZD1Ed0lDQXcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVq QlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2 aklTbGFKZGNabyZtPXZCOEdlbnU0STduT3U5QjdsS3o1bVdXWUNCdXVId21nbjBISXplUEFrNlEm cz1MOTVrOHJEZU5LYVNaWGtDcHF4Mmh3em1HRHc4dHJtem1ZT1QwU0xVLWZRJmU9KToNCiAgICA+ ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0NCiAgICAtLS0tLS0tLQ0KICAgID4NCiAgICA+ICAgICAgTm8gaXNzdWVz IGZvdW5kIGhlcmUuDQogICAgPg0KICAgID4gICBDaGVja2luZyBuaXRzIGFjY29yZGluZyB0bw0K ICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f d3d3LmlldGYub3JnX2lkLTJEaW5mb18xaWQtMkRndWlkZWxpbmVzLnR4dCZkPUR3SUNBdyZjPUhB a1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdK OUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09dkI4R2VudTRJN25PdTlCN2xLejVtV1dZ Q0J1dUh3bWduMEhJemVQQWs2USZzPXdybW80alZjQmI3LV9MRkg3dHktVE9wRzgwdGZlM3BXYmZD U0ZaYVQ2ZVkmZT06DQogICAgPiAgIC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAgLS0tLS0tLS0NCiAgICA+DQog ICAgPiAgICAgIE5vIGlzc3VlcyBmb3VuZCBoZXJlLg0KICAgID4NCiAgICA+ICAgQ2hlY2tpbmcg bml0cyBhY2NvcmRpbmcgdG8gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3Vy bD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaWQtMkRpbmZvX2NoZWNrbGlzdCZkPUR3SUNBdyZj PUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2 WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09dkI4R2VudTRJN25PdTlCN2xLejVt V1dZQ0J1dUh3bWduMEhJemVQQWs2USZzPV9zZVNhQ0tmenhZZWIzYjF0ZlgyUnFVazdDS2JPc1Jy M3BSVkpyUThsRWMmZT0gOg0KICAgID4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIC0tLS0tLS0tDQogICAg Pg0KICAgID4gICAqKiBUaGVyZSBpcyAxIGluc3RhbmNlIG9mIHRvbyBsb25nIGxpbmVzIGluIHRo ZSBkb2N1bWVudCwgdGhlDQogICAgbG9uZ2VzdCBvbmUNCiAgICA+ICAgICAgYmVpbmcgMSBjaGFy YWN0ZXIgaW4gZXhjZXNzIG9mIDcyLg0KICAgID4NCiAgICA+IEtlbnQ6IHRoaXMgaXNuJ3QgYSBi aWcgZGVhbCBJTU8sIGJ1dCBpZiBpdCdzIGVhc3kgdG8gZml4LCBpdCBzYXZlcyB0aGUNCiAgICBS RkMgZWRpdG9yIGEgc3RlcCBsYXRlciBvbi4NCiAgICA+DQogICAgPg0KICAgID4gICBNaXNjZWxs YW5lb3VzIHdhcm5pbmdzOg0KICAgID4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIC0tLS0tLS0tDQogICAg Pg0KICAgID4gICA9PSBMaW5lIDM1MiBoYXMgd2VpcmQgc3BhY2luZzogJy4uLmdvcml0aG0gICAg aWRlLi4uJw0KICAgID4NCiAgICA+IEtlbnQ6IHRoaXMgaXMgZmluZS4gIGl0IGlzIGluIGEgdHJl ZSBkaWFncmFtLg0KICAgID4NCiAgICA+DQogICAgPiAgID09IFRoZSBkb2N1bWVudCBzZWVtcyB0 byBsYWNrIHRoZSByZWNvbW1lbmRlZCBSRkMgMjExOSBib2lsZXJwbGF0ZSwNCiAgICBldmVuIGlm DQogICAgPiAgICAgIGl0IGFwcGVhcnMgdG8gdXNlIFJGQyAyMTE5IGtleXdvcmRzIC0tIGhvd2V2 ZXIsIHRoZXJlJ3MgYQ0KICAgIHBhcmFncmFwaCB3aXRoDQogICAgPiAgICAgIGEgbWF0Y2hpbmcg YmVnaW5uaW5nLiBCb2lsZXJwbGF0ZSBlcnJvcj8NCiAgICA+DQogICAgPiAgICAgIChUaGUgZG9j dW1lbnQgZG9lcyBzZWVtIHRvIGhhdmUgdGhlIHJlZmVyZW5jZSB0byBSRkMgMjExOSB3aGljaA0K ICAgIHRoZQ0KICAgID4gICAgICBJRC1DaGVja2xpc3QgcmVxdWlyZXMpLg0KICAgID4NCiAgICA+ IEtlbnQ6IEkgY2FuJ3QgZmluZCB0aGUgZXJyb3IuICBMb29raW5nIGF0IHRoZSB4bWwsIGl0IGlz IHZlcmJhdGltIHdoYXQNCiAgICBJIGhhdmUgaW4gdGhlIHplcm90b3VjaCBkcmFmdC4gIG15IGd1 ZXNzIGlzIHRoYXQgdGhpcyBpcyBhIHRvb2xpbmcgZXJyb3INCiAgICBhbmQgd2Ugc2hvdWxkIGln bm9yZSBpdC4NCiAgICA+DQogICAgPg0KICAgID4gICAtLSBUaGUgZG9jdW1lbnQgZGF0ZSAoSmFu dWFyeSAxMiwgMjAxOCkgaXMgNCBkYXlzIGluIHRoZSBwYXN0LiAgSXMNCiAgICB0aGlzDQogICAg PiAgICAgIGludGVudGlvbmFsPw0KICAgID4NCiAgICA+IEtlbnQ6IHRoaXMgaXMgZmluZSwgaXQg aXMgaW50ZW50aW9uYWwuDQogICAgPg0KICAgID4NCiAgICA+ICAgQ2hlY2tpbmcgcmVmZXJlbmNl cyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFyZA0KICAgID4gICAtLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KICAgIC0tLS0tLS0tDQogICAgPg0KICAgID4gICAgICAoU2VlIFJGQ3MgMzk2NyBhbmQg NDg5NyBmb3IgaW5mb3JtYXRpb24gYWJvdXQgdXNpbmcgbm9ybWF0aXZlDQogICAgcmVmZXJlbmNl cw0KICAgID4gICAgICB0byBsb3dlci1tYXR1cml0eSBkb2N1bWVudHMgaW4gUkZDcykNCiAgICA+ DQogICAgPiAgID09IFVudXNlZCBSZWZlcmVuY2U6ICdJLUQuaWV0Zi1uZXRjb25mLWtleXN0b3Jl JyBpcyBkZWZpbmVkIG9uIGxpbmUNCiAgICAxMzg2LA0KICAgID4gICAgICBidXQgbm8gZXhwbGlj aXQgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0KICAgID4NCiAgICA+IEtlbnQ6IGxv b2tpbmcgYXQgdGhlIFhNTCwgSSBzZWUgdGhhdCB0aGUgZW50aXJlIHBhcmFncmFwaCB1c2VzICdb JyBhbmQNCiAgICAnXScgYXMgb3Bwb3NlZCB0byA8eHJlZiAuLi4vPi4gIFBsZWFzZSBmaXggdGhp cy4NCiAgICA+DQogICAgPg0KICAgID4gICA9PSBVbnVzZWQgUmVmZXJlbmNlOiAnUkZDNzg5NScg aXMgZGVmaW5lZCBvbiBsaW5lIDE0NTYsIGJ1dCBubw0KICAgIGV4cGxpY2l0DQogICAgPiAgICAg IHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQNCiAgICA+DQogICAgPiBLZW50OiBsb29r aW5nIGF0IHRoZSBYTUwsIEkgc2VlIHR3byBpbnN0YW5jZXMgb2YgYW4gdW53YW50ZWQgIi8mZ3Q7 Ig0KICAgIHN0cmluZy4gIEZvciBpbnN0YW5jZTogPHhyZWYgdGFyZ2V0PSJSRkM3ODk1Ii8+LyZn dDsgIFBsZWFzZSBmaXggdGhpcy4NCiAgICA+DQogICAgPg0KICAgID4gICAqKiBEb3ducmVmOiBO b3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIEhpc3RvcmljIFJGQzogUkZDIDY1ODcNCiAgICA+DQog ICAgPiBLZW50OiBobW1tLCB3aGF0J3MgZ29pbmcgb24gaGVyZT8gIFRoaXMgWUFORyBtb2R1bGUg aXMgcHJvdmlkaW5nIGFuDQogICAgYWJpbGl0eSB0byBjb25maWd1cmUgdGhlICJ0Y3AiIHRyYW5z cG9ydCwgZXZlbiB0aG91Z2ggdGhlIElFU0cgbWFkZSB0aGF0DQogICAgYWJpbGl0eSBoaXN0b3Jp YyBpbiAyMDEyIChzZWUgSUVTRyBOb3RlIGJlbG93KS4gIFNlYXJjaGluZyBvbmxpbmUsIGl0DQog ICAgbG9va3MgbGlrZSBDaXNjbyBzdXBwb3J0cyB0aGlzLCBidXQgSnVuaXBlciBkb2VzIG5vdC4g IFdoYXQgYWJvdXQgb3RoZXINCiAgICB2ZW5kb3JzLCBpcyBpdCB3aWRlbHkgc3VwcG9ydGVkPyAg V2FzIHRoaXMgZGlzY3Vzc2VkIGluIHRoZSBXRz8NCiAgICBBbnN3ZXJpbmcgbXkgb3duIHF1ZXN0 aW9uLCBzZWFyY2hpbmcgbXkgbG9jYWwgbWFpbGJveCwgSSBkb24ndCBzZWUgdGhpcw0KICAgIGV2 ZXIgYmVpbmcgZGlzY3Vzc2VkIGJlZm9yZSwgb3RoZXIgdGhhbiBNYXJ0aW4gcXVlc3Rpb25pbmcg aWYgaXQgd2FzIGENCiAgICBnb29kIGlkZWEgaW4gTWFyIDIwMTYgKG5vIHJlc3BvbnNlKS4gIFBs ZWFzZSBzdGFydCBhIHRocmVhZCBvbiB0aGUgbGlzdA0KICAgIHRvIGdldCBXRyBvcGluaW9uIGlm IGl0J3Mgb2theSBmb3IgdGhlIGRyYWZ0IHRvIHByb2NlZWQgYXMgaXMgb3Igbm90Lg0KICAgIEhl cmUncyB0aGUgSUVTRyBOb3RlIGZyb20gUkZDIDY1ODc6DQogICAgPg0KICAgID4gICAgSUVTRyBO b3RlDQogICAgPg0KICAgID4gICAgVGhlIElFU0cgZG9lcyBub3QgcmVjb21tZW5kIGltcGxlbWVu dGluZyBvciBkZXBsb3lpbmcgc3lzbG9nIG92ZXINCiAgICA+ICAgIHBsYWluIHRjcCwgd2hpY2gg aXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQsIGJlY2F1c2UgaXQgbGFja3MNCiAgICB0aGUN CiAgICA+ICAgIGFiaWxpdHkgdG8gZW5hYmxlIHN0cm9uZyBzZWN1cml0eSBbUkZDMzM2NV0uDQog ICAgPg0KICAgID4gICAgSW1wbGVtZW50YXRpb24gb2YgdGhlIFRMUyB0cmFuc3BvcnQgW1JGQzU0 MjVdIGlzIHJlY29tbWVuZGVkIHNvDQogICAgdGhhdA0KICAgID4gICAgYXBwcm9wcmlhdGUgc2Vj dXJpdHkgZmVhdHVyZXMgYXJlIGF2YWlsYWJsZSB0byBvcGVyYXRvcnMgd2hvIHdhbnQNCiAgICB0 bw0KICAgID4gICAgZGVwbG95IHNlY3VyZSBzeXNsb2cuICBTaW1pbGFybHksIHRob3NlIHNlY3Vy aXR5IGZlYXR1cmVzIGNhbiBiZQ0KICAgID4gICAgdHVybmVkIG9mZiBmb3IgdGhvc2Ugd2hvIGRv IG5vdCB3YW50IHRoZW0uDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPg0KICAgID4NCiAgICA+ ICAgICAgU3VtbWFyeTogMiBlcnJvcnMgKCoqKSwgMCBmbGF3cyAofn4pLCA0IHdhcm5pbmdzICg9 PSksIDEgY29tbWVudA0KICAgICgtLSkuDQogICAgPg0KICAgID4gICAgICBSdW4gaWRuaXRzIHdp dGggdGhlIC0tdmVyYm9zZSBvcHRpb24gZm9yIG1vcmUgZGV0YWlsZWQNCiAgICBpbmZvcm1hdGlv biBhYm91dA0KICAgID4gICAgICB0aGUgaXRlbXMgYWJvdmUuDQogICAgPiA9PT09PSBFTkQgPT09 PT0NCiAgICA+DQogICAgPiBUaGFua3MsDQogICAgPiBLZW50IC8vIHNoZXBoZXJkDQogICAgPg0K ICAgID4NCiAgICA+DQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fXw0KICAgID4gbmV0bW9kIG1haWxpbmcgbGlzdA0KICAgID4gbmV0bW9kQGlldGYu b3JnDQogICAgPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0 cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBdyZjPUhB a1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdK OUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09dkI4R2VudTRJN25PdTlCN2xLejVtV1dZ Q0J1dUh3bWduMEhJemVQQWs2USZzPUNvSURjTnlMWWg2LU42Sm1MMnVTUjJNbTJVaDFrQU9PcFlQ OFlEYjBtbWMmZT0NCiAgICANCiAgICANCiAgICANCiAgICANCg0K From nobody Wed Feb 7 13:46:50 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5F54126DC2 for ; Wed, 7 Feb 2018 13:46:48 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.689 X-Spam-Level: X-Spam-Status: No, score=-2.689 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01] 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 lD--6aiKDGti for ; Wed, 7 Feb 2018 13:46:45 -0800 (PST) Received: from mail-io0-x236.google.com (mail-io0-x236.google.com [IPv6:2607:f8b0:4001:c06::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 86EB3126D46 for ; Wed, 7 Feb 2018 13:46:45 -0800 (PST) Received: by mail-io0-x236.google.com with SMTP id l17so3626269ioc.3 for ; Wed, 07 Feb 2018 13:46:45 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:references:in-reply-to:subject:date:message-id:mime-version :content-language:thread-index; bh=iJcI8xB0tf/tmkg9bMQrR345SXYJX+SITWMVOMwblHA=; b=L1hZtT9FLtQdTIWipclUGUm4ilhpmTqqgkwZmErDZWCBy5cqcI1bqKk0D1HynN+B23 mrpgVDHqAok9fbYkbCTOP6A5Rw9GIydnn1n518XAEugfJ36sB8/aYjFQFGPgSYF75tbG UzYos7LBfsFBnewdR5NJ+X5nYm3qQTSd9fytnty3szqH9tu76bubEjg7DwZ4DPc1qyAU pPuwGEhGY54AA2qUIJ+182v0C1nesP5hFJqiXnDhetILxJ1LB+t/AgDUWb0L1+U1XLCv 7GGf/ohmR4MgSGrwOMwBzLGdVKXMhPls6zVP5b/CK/YzjmXOclAZLcown3gcXWoqWgyF /Ung== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:references:in-reply-to:subject:date :message-id:mime-version:content-language:thread-index; bh=iJcI8xB0tf/tmkg9bMQrR345SXYJX+SITWMVOMwblHA=; b=RPTOd7epCLENCTAU+qSYu/e+/wjIDTp9pp49Ddi/Zmp3LI3KV5osiJEWQrVWJbKJZ0 e2ENOXJU+h/rONOkDJMtJJJbzKpNF4s0fZ2FhRdzbBZMT+p86w2rPRxiRqzysTja7r5x rYTVSach4OUNUI38D1WeqW74ZeweLQlhL17/56E8ALO4H8Iifb+ImiGow8X2kUfGgxUw 0EPC6GvZuO57XsugNjU7OTk+AUEFw3ZdzWzVfC8DMnMfutqinj5vHlSruv6Xj7ZZwinQ WQzLo2vhwpU7hyzhj8ACsUJve6fBYzwAtUK0+bcj1vuSzuz614JCSgdLj59E0b1C6B5W a4xw== X-Gm-Message-State: APf1xPDVQ3sN/ZX2JL63GAZgYkjOgg9IVUbYniZiFxgiKr/AMc/7LKlC frBCCOeVCKXyWSrjGLnFX/A= X-Google-Smtp-Source: AH8x226sdn8CIh/U6pIFlxqfokVoN2/U/wYg91F2jrI+eVf+MfJeGFEGIvqzfD7nwhb6rzq2QTiRIA== X-Received: by 10.107.33.65 with SMTP id h62mr9257740ioh.104.1518040004910; Wed, 07 Feb 2018 13:46:44 -0800 (PST) Received: from xliuus (ip72-196-214-116.dc.dc.cox.net. [72.196.214.116]) by smtp.gmail.com with ESMTPSA id m145sm2697537itg.22.2018.02.07.13.46.44 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 13:46:44 -0800 (PST) From: "Xufeng Liu" To: "'joel jaeggli'" , "'NETMOD Working Group'" References: In-Reply-To: Date: Wed, 7 Feb 2018 16:46:45 -0500 Message-ID: <018101d3a05d$2698b0e0$73ca12a0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0182_01D3A033.3DC4F2D0" X-Mailer: Microsoft Outlook 16.0 Content-Language: en-us Thread-Index: AQIX1B7goXi+5ADmA39FllDn0ciLi6MREf8w x-dg-ref: PG1ldGE+PGF0IG5tPSJib2R5Lmh0bWwiIHA9ImM6XHVzZXJzXHhsaXVcYXBwZGF0YVxyb2FtaW5nXDA5ZDg0OWI2LTMyZDMtNGE0MC04NWVlLTZiODRiYTI5ZTM1Ylxtc2dzXG1zZy02MzljNDA0MC0wYzUwLTExZTgtOWM0NC0xODVlMGZlM2M0NWNcYW1lLXRlc3RcNjM5YzQwNDItMGM1MC0xMWU4LTljNDQtMTg1ZTBmZTNjNDVjYm9keS5odG1sIiBzej0iNDA5NyIgdD0iMTMxNjI1MTM2MDUzMjE0MDcwIiBoPSJNRWRaVzdkUkJFaGNTdlBVelNFcloxT3ZUSG89IiBpZD0iIiBibD0iMCIgYm89IjEiLz48L21ldGE+ Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 21:46:49 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0182_01D3A033.3DC4F2D0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable yes/support. =20 Thanks, - Xufeng =20 From: netmod [mailto:netmod-bounces@ietf.org] On Behalf Of joel jaeggli Sent: Tuesday, February 6, 2018 6:47 PM To: NETMOD Working Group Subject: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 =20 Hi,=20 This is the start of a *two* week poll on making = draft-rtgyangdt-netmod-module-tags-02 a working group document. =20 https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02 This document was most recently discussed at IETF 100. Please send email to the list indicating "yes/support" or "no/do not = support". If indicating no, please state your reservations with the = document. If yes, please also feel free to provide comments you'd like = to see addressed once the document is a WG document.=20 This poll ends on February 8.=20 Thank you!=20 Joel Jaeggli and IETF NETMOD Co-Chairs ------=_NextPart_000_0182_01D3A033.3DC4F2D0 Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: quoted-printable

yes/support.

 

Thanks,

- = Xufeng

 

From: netmod [mailto:netmod-bounces@ietf.org] = On Behalf Of joel jaeggli
Sent: Tuesday, February 6, = 2018 6:47 PM
To: NETMOD Working Group = <netmod@ietf.org>
Subject: [netmod] Adoption Poll: = draft-rtgyangdt-netmod-module-tags-02

 

Hi,

This is the start = of a *two* week poll on making = draft-rtgyangdt-netmod-module-tags-02 a working group = document.  

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF = 100.

Please send email to the list indicating = "yes/support" or "no/do not support".  If = indicating no, please state your reservations with the document.  = If yes, please also feel free to provide comments you'd like to see = addressed once the document is a WG document.

This poll ends on = February 8.

Thank you!

Joel Jaeggli and IETF = NETMOD Co-Chairs

------=_NextPart_000_0182_01D3A033.3DC4F2D0-- From nobody Wed Feb 7 13:56:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8BDF51270AB for ; Wed, 7 Feb 2018 13:56:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O8uaXw327DiZ for ; Wed, 7 Feb 2018 13:56:55 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 221CB127873 for ; Wed, 7 Feb 2018 13:56:55 -0800 (PST) Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w17LnOMp007625; Wed, 7 Feb 2018 13:56:51 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=uerr1PmRPpCVE2f09BnFKNaASL2BspO8GpfB7nasZxY=; b=1oWbh9Lg8tyi/RfU101yZXW2jGLlDSwZGwbclRpnUEZuk1BAzT3k2IHOg3PhU30WioKD /f2Lo7/FzUodyq2XyOSX1OyOaAG8xsCe90WDEA59SeL51AwpMyKXt7PUQqFeuWUv2+Fg qhFTYH2wB+5yvKCpmJRWc8lQ7YQfLSLB14Uzb+e+q5kDSc1ZOc7ZV5HPkZjh725pq+WW qq5WxhmSl4DzljHdSk8sTm6Be+92wTTpinJRGnsnIf4BxxmaBQwR9RGEDrYEZ3FncVju onBv3wcyNEI1juY16MARKdvq1/HjDotiRHmqDz7HqmLYlFjj+fI/9NRcu6HaZbYLdVNM nw== Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0052.outbound.protection.outlook.com [216.32.180.52]) by mx0a-00273201.pphosted.com with ESMTP id 2g09kkr0vg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 07 Feb 2018 13:56:50 -0800 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3642.namprd05.prod.outlook.com (10.174.243.17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Wed, 7 Feb 2018 21:56:49 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) by DM5PR05MB3484.namprd05.prod.outlook.com ([10.174.240.147]) with mapi id 15.20.0485.009; Wed, 7 Feb 2018 21:56:49 +0000 From: Kent Watsen To: "t.petch" , NETMOD Working Group CC: RFC Editor Thread-Topic: [netmod] Draft Normative references in a YANG module Thread-Index: AQHToDlhpKliwBaKp0GYEyk8iin3O6OZKNeA Date: Wed, 7 Feb 2018 21:56:49 +0000 Message-ID: References: <017b01d3a039$1d4c5c40$4001a8c0@gateway.2wire.net> In-Reply-To: <017b01d3a039$1d4c5c40$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.11] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3642; 7:SfhaXFBWYuyQm9SXhvZX9E3Snt/yiRzPIOLfbexQvc/aNSbHNqzfJe2msyIyIrftoaByAMhK3lqtQlhUPiXrWez9tkbDOuZFKgMbegvw90bvzxLhtbFx3fbLV/yMrGH7SMmYXf95R7fQiF7K8Z9dD4+Pxgl7C0vlOFFvcbaY8dRn8lCl9t67UyAcKO8OrIWAcHnYx0xJjZ/wglS0Hv3kpDa0RYQlVUl/VJFpDkiSMWyZw+3VajIKGyflzgrwYITJ x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 05f82e2f-50e1-40f1-ca86-08d56e75b08f x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3642; x-ms-traffictypediagnostic: DM5PR05MB3642: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(17755550239193); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(3002001)(6055026)(6041288)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR05MB3642; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3642; x-forefront-prvs: 0576145E86 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(346002)(376002)(396003)(39860400002)(39380400002)(51444003)(189003)(199004)(6306002)(82746002)(6512007)(305945005)(106356001)(6506007)(8936002)(5890100001)(36756003)(2950100002)(102836004)(76176011)(966005)(97736004)(81166006)(6436002)(83506002)(6486002)(6246003)(105586002)(7736002)(81156014)(26005)(4326008)(5660300001)(83716003)(77096007)(2906002)(8666007)(186003)(3660700001)(99286004)(575784001)(86362001)(66066001)(110136005)(478600001)(8676002)(6116002)(14454004)(58126008)(3280700002)(2900100001)(68736007)(53936002)(33656002)(296002)(316002)(3846002)(25786009)(229853002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3642; H:DM5PR05MB3484.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) x-microsoft-antispam-message-info: AK0i/dosaMmokiqzeyDuMILSs9y0udugZq1X8Jw7lDIItgR/9+pNoy9BkvBktPbdFSKv/KAjIxnvahEohepMLA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: 05f82e2f-50e1-40f1-ca86-08d56e75b08f X-MS-Exchange-CrossTenant-originalarrivaltime: 07 Feb 2018 21:56:49.4610 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3642 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-07_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802070276 Archived-At: Subject: Re: [netmod] Draft Normative references in a YANG module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 21:56:57 -0000 SSB0aGluayB0aGF0IHRoZXJlIHNob3VsZCBiZSBhIG5vdGUgYXR0YWNoZWQgdG8gc3VjaCByZWZl cmVuY2VzIA0Kb2NjdXJyaW5nIGluc2lkZSBvZiBhIFlBTkcgbW9kdWxlLiAgIEkgdGhpbmsgdGhh dCBhbGwgb2YgbXkgZHJhZnRzDQpkbyB0aGlzLCB0aG91Z2ggSSB0ZW5kIHRvIHVzZSBhIHNpbmds ZSBsYXJnZSBOb3RlIHRvIEVkaXRvciBhdCB0aGUNCmJlZ2lubmluZyBvZiB0aGUgZHJhZnQsIHJh dGhlciB0aGFuIGEgbnVtYmVyIG9mIHNtYWxsZXIgbm90ZXMgDQpzcHJpbmtsZWQgdGhyb3VnaG91 dCB0aGUgZG9jdW1lbnQuDQoNClNlcGFyYXRlbHksIEkgc3VwcG9ydCB5b3VyIGlkZWEgb2YgdG9v bGluZyB0byBjYXRjaCB0aGUgY2FzZSB3aGVuDQphIHJlZmVyZW5jZSBvY2N1cnJpbmcgaW5zaWRl IGEgbW9kdWxlIGlzbid0IGFsc28gaHlwZXJsaW5rZWQgaW4gDQp0aGUgZHJhZnQsIGp1c3QgYWJv dmUgd2hlcmUgdGhlIG1vZHVsZSBpcyBsb2NhdGVkIGluIHRoZSBkcmFmdC4NCg0KS2VudCAvLyB5 YW5nIGRvY3Rvcg0KDQoNCj09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT0NCg0KV2lsbCB0aGUg UkZDIEVkaXRvciBrbm93IHRoYXQNCg0KICAgICAgIHJlZmVyZW5jZSAiZHJhZnQtaWV0Zi1uZXRt b2QtcmZjNzIyM2JpczogQSBZQU5HIERhdGEgTW9kZWwNCiAgICAgICAgICAgICAgICAgIGZvciBJ bnRlcmZhY2UgTWFuYWdlbWVudCI7DQppbg0KDQpkcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVsLTA5 DQoNCm5lZWRzIHJlcGxhY2luZyBieSBSRkN4eHh4IHdoZW4gdGhhdCBJLUQgYmVjb21lcyBhbiBS RkM/DQoNCk5vcm1hbGx5LCBzdWNoIGEgcmVmZXJlbmNlIHdvdWxkIGJlIFtkcmFmdC1pZXRmLW5l dG1vZC1yZmM3MjIzYmlzXSB3aXRoDQp0aGUgdW5kZXJseWluZyBIVE1ML1hNTCBhbmNob3IgYW5k IGF1dG9tYXRlZCB0b29scyBjYW4gcGljayB0aGlzIHVwIChJDQphc3N1bWUgdGhhdCB0aGUgUkZD IEVkaXRvciBpcyB3ZWxsIGF1dG9tYXRlZDotKQ0KDQpCdXQgd2hlbiB0aGUgTm9ybWF0aXZlIFJl ZmVyZW5jZSBpcyBpbiB0aGUgdGV4dCBvZiBhIFlBTkcgbW9kdWxlIGFuZA0KdGhlcmUgaXMgbm8g dW5kZXJseWluZyBhbmNob3IsIHdpbGwgdGhpcyBnZXQgbm90aWNlZCBhbmQgYWN0aW9uZWQ/DQoN Ck9yIHNob3VsZCB0aGVyZSBiZSBhDQoNCk5vdGUgdG8gUkZDIEVkaXRvcg0KDQphdHRhY2hlZCB0 byBzdWNoIHJlZmVyZW5jZXM/DQoNClRvbSBQZXRjaA0KDQpfX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fXw0KbmV0bW9kIG1haWxpbmcgbGlzdA0KbmV0bW9kQGll dGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt M0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1 aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQ b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09UUNUaGNoczRKZUdzcnpySmVhVWRRb1BRaTM3 cEN6NEZHZ2NfY2lsUExnZyZzPUVZSWh0cG90TmFYMDl0UTVoUjg2QnRVRDA0b3YtWW5yOWZ3QkNN YTJVZTAmZT0NCg0KDQo= From nobody Wed Feb 7 13:58:32 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A26D31270AB; Wed, 7 Feb 2018 13:58:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id scCcDuLD-Y5q; Wed, 7 Feb 2018 13:58:26 -0800 (PST) Received: from mail-io0-x241.google.com (mail-io0-x241.google.com [IPv6:2607:f8b0:4001:c06::241]) (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 1619B127873; Wed, 7 Feb 2018 13:58:25 -0800 (PST) Received: by mail-io0-x241.google.com with SMTP id l17so3657102ioc.3; Wed, 07 Feb 2018 13:58:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=q0IpYigziU2jlHGR7IAz1stl6pXgJxS58RJrn9B+gdc=; b=PHGN8KmGrjpYJEo0asZBZ0aKGmpbJ+WLKto9U+oOic02rQtFZaQFti/Wuqc168tGw/ rNYS73spJynGsQQ/dXN40fainB7p4OOzb/F/7JldNy347PlffARsVOoiocmaYTS3Ssat c0yMeOEirrjN8b57hSuS7TJHLjjv5FsQCwX8Gvf0Jut63wiSKSdXuQkvN9gD9MZo7j9m RSNSbFgSma9tOCtWbDsqQ537l/Sy+BEs1XMgWibfJnwbQjJKOKwouEp3JVGGSxPeeVZV VjQsZ/t9SZhQi204BvIoeX9yieCjtRcEkBh48IV7kzVNPWVBqANQJlzJ9WVyJ4LJnbUJ Rvfw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=q0IpYigziU2jlHGR7IAz1stl6pXgJxS58RJrn9B+gdc=; b=VYzO/jfcRyzuctzH0vnCqkWykAqjzarFYWEyd7grAD9u/epOnVzXh0jG9MhXxzrQVL Vnwi75clyFeigNAiZ96EeoKDrXTP3m9ARl1RbXQaTHYluiO232QAONf2uN5Lh2n9py8v TPlCRJ0NcmBZrGQFRC9C6E8GPOfnNp2m2HuIkVPQGNEuMaexN7X1V6e1MjerzjfUU1j3 LYxK79TTqEmrlSO/pc6BAcEgbu2fduUZTAz15aRYDt7QsCi64mySYrIzMnULXKqZeqVB QOvHst5INZ13DJCRPH+bmDyFVQEbcs5LsBVvftsCqD5CA4e1rxmxdAw9tR01qSSSVYd8 qSHg== X-Gm-Message-State: APf1xPB4HOspiOagD63lEQlQiSqB3MdPWmm1m0Z8Y2M7QMT9HU3O2jo/ 1rlDAVFqJLeE9+vfeKdB/4Y= X-Google-Smtp-Source: AH8x2249HC48NIccT/XB8mtWBNVMlCjW5qM2hGthM05caewsxfa5bPiTGgYHqL9jDOaBH6pEJumwxg== X-Received: by 10.107.143.14 with SMTP id r14mr9494893iod.191.1518040705223; Wed, 07 Feb 2018 13:58:25 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:8ff:cdce:63cb:9067]) by smtp.gmail.com with ESMTPSA id e7sm2924811ita.17.2018.02.07.13.58.23 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 07 Feb 2018 13:58:24 -0800 (PST) From: Mahesh Jethanandani Message-Id: <4A22F659-0656-4382-964D-B9319AF5CE93@gmail.com> Content-Type: multipart/alternative; boundary="Apple-Mail=_4D4DCC4F-24DD-4AA1-8D66-28B33500B47E" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Wed, 7 Feb 2018 13:58:22 -0800 In-Reply-To: <20180207.192803.834988416883038576.mbj@tail-f.com> Cc: netconf@ietf.org, netmod@ietf.org To: Martin Bjorklund , Andy Bierman References: <20180207.192803.834988416883038576.mbj@tail-f.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 21:58:31 -0000 --Apple-Mail=_4D4DCC4F-24DD-4AA1-8D66-28B33500B47E Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 It appears that there is some consensus around the issue of = =E2=80=9Cwith-defaults=E2=80=9D for operational datastore. Andy, would = you agree with what has been suggested? It also appears that text needs to be added to explain the behavior = w.r.t. operational datastore. If everyone agrees, authors, can you = propose the text that needs to be updated. Thanks. > On Feb 7, 2018, at 10:28 AM, Martin Bjorklund wrote: >=20 > Andy Bierman > wrote: >> On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton = wrote: >>=20 >>>=20 >>>=20 >>> On 07/02/2018 14:23, Andy Bierman wrote: >>>=20 >>>=20 >>>=20 >>> On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton = wrote: >>>=20 >>>> Hi Andy, >>>>=20 >>>> On 07/02/2018 02:33, Andy Bierman wrote: >>>>=20 >>>>=20 >>>>=20 >>>> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani < >>>> mjethanandani@gmail.com> wrote: >>>>=20 >>>>> For folks that provided comments as part of LC, please verify that = your >>>>> comments have been adequately addressed by -03 version of the = draft. >>>>>=20 >>>>>=20 >>>>=20 >>>> Most comments have been addressed. >>>>=20 >>>>=20 >>>> The "with-defaults" parameter does not apply when interacting = with an >>>>=20 >>>> operational datastore. >>>>=20 >>>>=20 >>>> There is no explanation of why the with-defaults parameter does not = apply >>>> to . >>>> This is confusing. The solution that has been a standard for years = still >>>> applies to >>>> all datastores, except a completely different mechanism = (origin-filter) >>>> is used instead >>>> for 1 datastore. >>>>=20 >>>> If the server code can identify a default so it can be tagged >>>> origin=3Dor:default, then it can >>>> also support with-defaults. >>>>=20 >>>> I prefer the sentence above be changed, so that a server MAY = implement >>>> with-defaults >>>> for . If the client sends it should = be OK >>>> to honor it instead >>>> of returning an error. >>>>=20 >>>> I have two concerns with changing this to a MAY: >>>>=20 >>>> (1) The most useful "with-defaults" behavior differs for = vs >>>> the configuration datastores, but with-defaults only allows a = single >>>> standard behavior to be specified. >>>>=20 >>>> E.g. for configuration datastores the most appropriate semantics = (if the >>>> client doesn't explicitly ask for something else) is "explicit". = i.e. you >>>> give back exactly what was put in. >>>>=20 >>>> But, for operational, the most appropriate semantics (if the client >>>> doesn't explicitly ask for something else) is something like = "report-all", >>>> i.e. the device reports the precise current state including any = defaults. >>>> However, we felt that this would return too much unnecessary data, = hence >>>> why the datastore architecture defines "in-use" data, allowing the = server >>>> to prune out any data that is clearly irrelevant. >>>>=20 >>>> (2) is a new datastore. I personally don't want each >>>> server choosing how the data is returned, which requires that = clients must >>>> handle all variants. It would be better for the draft to specify = the >>>> standard semantics to use unless a client has explicitly requested >>>> something else. >>>>=20 >>>> I'm not opposed to a "with-defaults-bis", or a new draft covering >>>> "with-defaults" for ", but I think that: >>>> (i) We shouldn't delay the NMDA protocol drafts for this, this can = be >>>> done as separate draft adding extra optional functionality. >>>> (ii) The semantics for retrieving data from operational (or >>>> notifications) should be as defined by "in-use" in the NMDA = architecture, >>>> unless a client has explicitly specified, or configured, a = different >>>> behavior. >>>> (iii) Probably the only existing option defined in "with-defaults" = that >>>> makes sense for is a variant of "trim" that is = specified to >>>> return what is defined as returning the "in-use" values, but also = excluding >>>> any values that match a default value specified in the schema. >>>>=20 >>>>=20 >>>=20 >>> I think your approach violates the Postel Principle. >>> "Be liberal in what you accept" is about robustness. >>> Rejecting parameters for no good reason is about fragility. >>>=20 >>> I never said change the behavior for if no = >>> is present. >>> If the parameter is provided it is trivial for the server to honor = it. >>> The most useful value (report-all) is the default, not leave out all >>> defaults, like . >>>=20 >>> OK, so one option is to allow the "with-defaults" parameter for the >>> datastore, but specify in both the NETCONF NMDA and = RESTCONF >>> NMDA drafts how "with-defaults" semantics apply to any operational >>> datastore: >>>=20 >>> 1) Regardless of what is reported in the "basic-mode" capability >>> parameter, the default behavior for is "report-all", = with >>> semantics as described below: >>> 2) "report-all" for operational datastores is defined as returning = all "in >>> use" values (i.e. as specified in section 5.3 of the NMDA = architecture, so >>> default values that are not "in use" are not returned). >>> 3) "trim" for operational datastores is defined as returning all = "in-use" >>> values (... as 5.3) except that values that match the value = specified in >>> the schema "default" statement are omitted. Note, clients cannot >>> distinguish between a value that is omitted because it is not in = use, vs a >>> value that is omitted because it matches the schema default. >>> 4) "explicit" for operational datastores is defined as returning the = same >>> as "report-all", defined above. >>> 5) "report-all-tagged" for operational datastores is defined as = returning >>> the same as "report-all", except that all values that match the = values >>> specified in the schema "default" statement are tagged, as described = in >>> with-defaults (RFC 5243). >>>=20 >>> Also note - there is no change in semantics or behavior to how >>> "with-defaults" works for conventional datastores. >>>=20 >>> Thoughts? >>>=20 >>>=20 >> This looks good. >>=20 >> Showing the work... >>=20 >> 1) there is no YANG default for parameter. >> The behavior if this parameter is missing is determined by the = operation >=20 > Right. So in this case (get-data of operational), it would return all > default values in use. >=20 >> 2) The operation returns all values in use. >> The only way to suppress defaults is to use >> (e.g., request all origins except 'default') >=20 > Or use with-defaults =3D trim. >=20 >> 3) The parameter for is mostly a NO-OP. >> It does not add or remove any nodes that would be returned. >> The "report-all-tagged" value does add the "default> attribute, = which >> is useful >> for clients that process these attributes already >>=20 >> 4) The values that are tagged default are the same ones that the = server tags >> as origin=3Ddefault. >>=20 >> 5) It still seems to up to the server "basic-mode" as to what is = considered >> "set by default". This messy aspect of NETCONF is minimized in >> because >> the server usually returns all values in use. >=20 >=20 >=20 > /martin >=20 >=20 >=20 >>=20 >>=20 >> Thanks, >>> Rob >>>=20 >>>=20 >>=20 >> Andy >>=20 >>=20 >>>=20 >>>=20 >>>=20 >>>=20 >>>> Thanks, >>>> Rob >>>>=20 >>>>=20 >>>>=20 >>> Andy >>>=20 >>>=20 >>>>=20 >>>>=20 >>>> Andy >>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>>> Thanks >>>>>=20 >>>>> Mahesh Jethanandani >>>>> mjethanandani@gmail.com >>>>>=20 >>>>>> On Feb 5, 2018, at 9:43 AM, Martin Bjorklund = wrote: >>>>>>=20 >>>>>> Hi, >>>>>>=20 >>>>>> Mahesh Jethanandani wrote: >>>>>>> This closes the LC for the two NDMA drafts for NETCONF and = RESTCONF. >>>>>>>=20 >>>>>>> As part of the LC, there were a couple of comments/questions >>>>>>> raised. In particular >>>>>>>=20 >>>>>>> - Vladmir reported an error, which Martin said is fixed in his = local >>>>> copy. >>>>>>=20 >>>>>> Fixed. >>>>>>=20 >>>>>>> - Robert suggested that =E2=80=9C/yang-library/checksum=E2=80=9D = should be a >>>>>>> reference. Juergen supported that comment, so I am assuming that >>>>>>> that will be incorporated into the draft. >>>>>>=20 >>>>>> Yes, fixed. >>>>>>=20 >>>>>>> - Andy had questions around datastore set to =E2=80=9Cconventional= =E2=80=9D >>>>>>=20 >>>>>> Fixed. >>>>>>=20 >>>>>>> , about origin filter limited to 1 source >>>>>>=20 >>>>>> Fixed. >>>>>>=20 >>>>>>> and the behavior of with-defaults. >>>>>>=20 >>>>>> There were no additional changes to the document from the = discussion >>>>>> about this. >>>>>>=20 >>>>>>> I see some discussion around it with the authors >>>>>>> agreeing that some of them need some text clarifying the >>>>>>> position. Can the authors please post the suggested = text/additions >>>>>>> for the WG to review. >>>>>>> - Anything else?? >>>>>>>=20 >>>>>>> Once an updated draft has been posted, I will do a writeup on = the >>>>>>> drafts and send it to IESG. >>>>>>=20 >>>>>> The issues above are now addressed, in >>>>>> draft-ietf-netconf-nmda-netconf-03. >>>>>>=20 >>>>>> There were no additional comments on >>>>>> draft-ietf-netconf-nmda-restconf-02, so I believe this version is >>>>>> ready. >>>>>>=20 >>>>>>=20 >>>>>> /martin >>>>>>=20 >>>>>>=20 >>>>>>>=20 >>>>>>> Thanks. >>>>>>>=20 >>>>>>>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder < >>>>> j.schoenwaelder@jacobs-university.de> wrote: >>>>>>>>=20 >>>>>>>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) = wrote: >>>>>>>>>=20 >>>>>>>>> I do have one additional thought below on >>>>> draft-ietf-netmod-revised-datastores section 5.3 default handling >>>>> process. See in-line... >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>> Well, this document is with the RFC editor now. I do not think = it >>>>> needs >>>>>>>> clarification. It already has text in 5.3 such as: >>>>>>>>=20 >>>>>>>> Requests to retrieve nodes from always return the >>>>> value >>>>>>>> in use if the node exists, regardless of any default value = specified >>>>>>>> in the YANG module. If no value is returned for a given node, = then >>>>>>>> this implies that the node is not used by the device. >>>>>>>>=20 >>>>>>>> /js >>>>>>>>=20 >>>>>>>>> From: Robert Wilton -X, January 31, 2018 6:31 AM >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Hi Andy, >>>>>>>>>=20 >>>>>>>>> On 31/01/2018 09:22, Andy Bierman wrote: >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder < >>>>> j.schoenwaelder@jacobs-university.de = >>>> -university.de>>>>> j.schoenwaelder@jacobs-university.de>>> wrote: >>>>>>>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: >>>>>>>>>> Hi, >>>>>>>>>>=20 >>>>>>>>>> I have some questions about these drafts. >>>>>>>>>>=20 >>>>>>>>>> 1) what if datastore set to "conventional"? >>>>>>>>>> There are many places where a datastore-ref type is used. >>>>>>>>>> However, "conventional" is valid for base "datastore", even >>>>> though >>>>>>>>>> it is ambiguous as a datastore selector. >>>>>>>>>=20 >>>>>>>>> We can add explicit text that an identity that does not = resolve to a >>>>>>>>> datastore implemented by the server results in an invalid = value >>>>> error. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> OK >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>> 2) origin filter is limited to 1 source >>>>>>>>>> This filtering seems rather limited. A client must retrieve >>>>>>>>>> and check >>>>>>>>>> all the values in use, then make repeated requests for each >>>>> source as a >>>>>>>>>> different >>>>>>>>>> leaf >>>>>>>>>=20 >>>>>>>>> If the client does , then it has all origin = information >>>>>>>>> and it can filter locally. That said, we could make = origin-filter a >>>>>>>>> leaf-list which is logically ORed so that one can retrieve >>>>>>>>> origin-filter=3Dor:system or origin-filter=3Dor:learned in one = request. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> OK >>>>>>>>>=20 >>>>>>>>>> 3) with-defaults broken >>>>>>>>>> The operational datastore does not support with-defaults. >>>>>>>>>> Instead, the client must use origin-filter=3Dor:default or >>>>> with-origin >>>>>>>>>> and check all the origin attributes. Since a client needs = to >>>>> use >>>>>>>>>> with-defaults for other datastores, this special handling = of >>>>>>>>>> >>>>>>>>>> seems unhelpful. >>>>>>>>>=20 >>>>>>>>> I think the with-defaults semantics for conventional = configuration >>>>>>>>> datastores are much more complicated than necessary for the >>>>>>>>> operational state datastore. Note that that the operational = state >>>>>>>>> datastore reports in-use values not really defaults: >>>>>>>>>=20 >>>>>>>>> foo >>>>>>>>>=20 >>>>>>>>> This reports that the value 'foo' is in use and that it = originates >>>>>>>>> from a default value. Note that this could also be >>>>>>>>>=20 >>>>>>>>> foo >>>>>>>>>=20 >>>>>>>>> in case the intended configuration datastore configured the = value >>>>>>>>> 'foo' (despite this value matching the default). The = with-defaults >>>>>>>>> solution is pretty complex because it tries to handle how = different >>>>>>>>> systems deal with configuration defaults. The idea is to not = carry >>>>>>>>> this complexity over to in-use values in the operational state >>>>>>>>> datastore. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> Before NMDA, the client could decide if it wanted to retrieve >>>>> default nodes or not. >>>>>>>>> This client-choice has been removed from NMDA, which is a = problem. >>>>>>>>> We tried to reach a sensible compromise on the data returned = from >>>>> operational (defined in section 5.3 of the NMDA architecture): >>>>>>>>> - it should return explicit values for everything that is = affecting >>>>> the actual running state of the device (regardless of whether the >>>>> operational value matches a schema default value). >>>>>>>>> - it does not need to, and should not, return operational = values >>>>> for stuff that isn't actually in use, i.e. don't return needless = and >>>>> unwanted data. >>>>>>>>>=20 >>>>>>>>> In particular, if no value is returned from a particular data = node >>>>> in then, barring mgmt protocol errors, a client can = assume >>>>> that any functionality associated with that data node is off (i.e. = not in >>>>> use). >>>>>>>>>=20 >>>>>>>>> Some examples to illustrate the behavior: >>>>>>>>>=20 >>>>>>>>> (i) If a protocol, e.g. OSPF, is not enabled/running then >>>>> does not need to return any data for it. It would = be >>>>> reasonable to return a flag to indicate that OSPF is not = enabled/running. >>>>>>>>>=20 >>>>>>>>> (ii) If you have some funky widget on an interface that = defaults to >>>>> being off and isn't being used then don't need to = return any >>>>> data for it. >>>>>>>>>=20 >>>>>>>>> (iii) But, if you have some funky widget on an interface that >>>>> defaults to being on, then the server should return data for it. = If it is >>>>> actually enabled, then it would indicate that it is on and return = any >>>>> associated values with its operational state, or if it is disabled = then it >>>>> should explicitly report that it is off. >>>>>>>>>=20 >>>>>>>>> (iv) I would regard that all applied configuration is "in use" = by >>>>> the system, even if it matches the default value, and hence it = should be >>>>> reported. >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> This behavior for is obviously slightly = different >>>>> from the existing with-default handling that is supported for = configuration >>>>> datastores. As I recall, there were a couple of reasons that we = decided to >>>>> have a different behavior for : >>>>>>>>> (a) to have consistent semantics for all servers, rather than >>>>> different servers supporting different with-defaults behaviors = (which makes >>>>> life harder for clients because they must cope with all variants). >>>>>>>>> (b) to remove any potential ambiguity if data isn't returned. = I.e. >>>>> with the existing with-defaults semantics it is not clear to me = that >>>>> servers will always return an explicit value to indicate that a = particular >>>>> widget is off if the schema defines that the default it that is = enabled. >>>>> If the server doesn't support a given widget at all, it is quite = plausible >>>>> that it will just return no data for it. In theory = features/deviations >>>>> should handle this, but those don't work so well if different = linecards >>>>> have different capabilities. Hence being explicit about stuff = that is in >>>>> use seems more robust. >>>>>>>>>=20 >>>>>>>>> These are good examples. It would be great if section = 5.3 >>>>> could be tweaked to make clearer the relationship between running = datastore >>>>> defaults and other operational datastore defaults for the same = tree. >>>>>>>>>=20 >>>>>>>>> For example, let=E2=80=99s say I create a configured = subscription, and the >>>>> default transport protocol is NETCONF. NETCONF will be used for = that >>>>> subscription even though the node might not be populated. In this = case, >>>>> the object would not appear in the running datastore, but MUST* = appear in >>>>> the operational datastore with the default origin (as it is = in-use). >>>>>>>>>=20 >>>>>>>>> This to me is the desired behavior as it doesn=E2=80=99t = incorrectly add >>>>> information to the running datastore, but shows what is in-use = within >>>>> operational. I suspect other such relationships for other = operational >>>>> tree defaults could be asserted, perhaps based on the origin. >>>>>>>>>=20 >>>>>>>>> (* Maybe =E2=80=98MUST eventually=E2=80=99, as obviously there = is a temporal >>>>> relationship between the two datastores.) >>>>>>>>>=20 >>>>>>>>> Eric >>>>>>>>>=20 >>>>>>>>> Thanks, >>>>>>>>> Rob >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> /js >>>>>>>>>=20 >>>>>>>>> Andy >>>>>>>>>=20 >>>>>>>>> -- >>>>>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >>>>> Germany >>>>> = > >>>>>>>>> Fax: +49 421 200 3103 = >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>>=20 >>>>>>>>> netmod mailing list >>>>>>>>>=20 >>>>>>>>> netmod@ietf.org = >>>> > >>>>>>>>>=20 >>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod < >>>>> https://www.ietf.org/mailman/listinfo/netmod> >>>>>>>>>=20 >>>>>>>>=20 >>>>>>>>> _______________________________________________ >>>>>>>>> netmod mailing list >>>>>>>>> netmod@ietf.org >>>>>>>>> https://www.ietf.org/mailman/listinfo/netmod < >>>>> https://www.ietf.org/mailman/listinfo/netmod> >>>>>>>>=20 >>>>>>>>=20 >>>>>>>> -- >>>>>>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH >>>>>>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | >>>>> Germany >>>>> = > >>>>>>>> Fax: +49 421 200 3103 = >>>> https://www.jacobs-university.de/>> >>>>>>>>=20 >>>>>>>> _______________________________________________ >>>>>>>> netmod mailing list >>>>>>>> netmod@ietf.org >>>>>>>> https://www.ietf.org/mailman/listinfo/netmod < >>>>> https://www.ietf.org/mailman/listinfo/netmod> >>>>>>> Mahesh Jethanandani >>>>>>> mjethanandani@gmail.com >>>>>>>=20 >>>>>=20 >>>>> _______________________________________________ >>>>> Netconf mailing list >>>>> Netconf@ietf.org >>>>> https://www.ietf.org/mailman/listinfo/netconf >>>>>=20 >>>>=20 >>>>=20 >>>>=20 >>>> _______________________________________________ >>>> Netconf mailing = listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf >>>>=20 >>>>=20 >>>>=20 >>>=20 >>>=20 > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf = Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_4D4DCC4F-24DD-4AA1-8D66-28B33500B47E Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8 It = appears that there is some consensus around the issue of = =E2=80=9Cwith-defaults=E2=80=9D for operational datastore. Andy, would = you agree with what has been suggested?

It also appears that text needs to be = added to explain the behavior w.r.t. operational datastore. If everyone = agrees, authors, can you propose the text that needs to be = updated.

Thanks.

On Feb 7, 2018, at 10:28 AM, = Martin Bjorklund <mbj@tail-f.com> wrote:

Andy Bierman <andy@yumaworks.com> wrote:
On Wed, Feb 7, 2018 at 8:11 = AM, Robert Wilton <rwilton@cisco.com> wrote:



On 07/02/2018 14:23, Andy Bierman wrote:



On Wed, Feb 7, 2018 at 3:14 AM, = Robert Wilton <rwilton@cisco.com> wrote:

Hi Andy,
On 07/02/2018 02:33, Andy Bierman wrote:



On Mon, Feb 5, 2018 at 1:33 PM, = Mahesh Jethanandani <
mjethanandani@gmail.com> wrote:

For folks that provided = comments as part of LC, please verify that your
comments = have been adequately addressed by -03 version of the draft.



Most = comments have been addressed.


   The "with-defaults" parameter does not = apply when interacting with an

       operational = datastore.


There is no = explanation of why the with-defaults parameter does not apply
to <operational>.
This is confusing. The = solution that has been a standard for years still
applies = to
all datastores, except a completely different mechanism = (origin-filter)
is used instead
for 1 = datastore.

If the server code can identify = a default so it can be tagged
origin=3Dor:default, then it = can
also support with-defaults.

I prefer the sentence above be changed, so that a server MAY = implement
with-defaults
for = <operational>.  If the client sends <with-defaults> it = should be OK
to honor it instead
of = returning an error.

I have two concerns = with changing this to a MAY:

(1) The most = useful "with-defaults" behavior differs for <operational> vs
the configuration datastores, but with-defaults only allows a = single
standard behavior to be specified.

E.g. for configuration datastores the most appropriate = semantics (if the
client doesn't explicitly ask for = something else) is "explicit". i.e. you
give back exactly = what was put in.

But, for operational, the = most appropriate semantics (if the client
doesn't = explicitly ask for something else) is something like "report-all",
i.e. the device reports the precise current state including = any defaults.
However, we felt that this would return too = much unnecessary data, hence
why the datastore = architecture defines "in-use" data, allowing the server
to = prune out any data that is clearly irrelevant.

(2) <operational> is a new datastore.  I = personally don't want each
server choosing how the data is = returned, which requires that clients must
handle all = variants.  It would be better for the draft to specify the
standard semantics to use unless a client has explicitly = requested
something else.

I'm = not opposed to a "with-defaults-bis", or a new draft covering
"with-defaults" for <operational>", but I think = that:
(i) We shouldn't delay the NMDA protocol drafts for = this, this can be
done as separate draft adding extra = optional functionality.
(ii) The semantics for retrieving = data from operational (or
notifications) should be as = defined by "in-use" in the NMDA architecture,
unless a = client has explicitly specified, or configured, a different
behavior.
(iii) Probably the only existing = option defined in "with-defaults" that
makes sense for = <operational> is a variant of "trim" that is specified to
return what is defined as returning the "in-use" values, but = also excluding
any values that match a default value = specified in the schema.



I think your approach violates = the Postel Principle.
"Be liberal in what you accept" is = about robustness.
Rejecting parameters for no good reason = is about fragility.

I never said change the = behavior for <operational> if no <with-defaults>
is present.
If the parameter is provided it is = trivial for the server to honor it.
The most useful value = (report-all) is the default, not leave out all
defaults, = like <get-config>.

OK, so one option = is to allow the "with-defaults" parameter for the
<operational> datastore, but specify in both the = NETCONF NMDA and RESTCONF
NMDA drafts how "with-defaults" = semantics apply to any operational
datastore:

1) Regardless of what is reported in the = "basic-mode" capability
parameter, the default behavior = for <operational> is "report-all", with
semantics as = described below:
2) "report-all" for operational = datastores is defined as returning all "in
use" values = (i.e. as specified in section 5.3 of the NMDA architecture, so
default values that are not "in use" are not returned).
3) "trim" for operational datastores is defined as returning = all "in-use"
values (... as 5.3) except that values that = match the value specified in
the schema "default" = statement are omitted.  Note, clients cannot
distinguish between a value that is omitted because it is not = in use, vs a
value that is omitted because it matches the = schema default.
4) "explicit" for operational datastores = is defined as returning the same
as "report-all", defined = above.
5) "report-all-tagged" for operational datastores = is defined as returning
the same as "report-all", except = that all values that match the values
specified in the = schema "default" statement are tagged, as described in
with-defaults (RFC 5243).

Also = note - there is no change in semantics or behavior to how
"with-defaults" works for conventional datastores.

Thoughts?


This looks good.

Showing the work...

1) there is = no YANG default for <with-defaults> parameter.
   The behavior if this parameter is missing = is determined by the operation

Right.  So in this case (get-data of = operational), it would return all
default values in use.
2) The <get-data> = operation returns all values in use.
   The = only way to suppress defaults is to use <origin-filter>
   (e.g., request all origins except = 'default')

Or use with-defaults =3D = trim.

3) The <with-defaults> = parameter for <operational> is mostly a NO-OP.
   It does not add or remove any nodes that = would be returned.
   The = "report-all-tagged" value does add the "default> attribute, which
is useful
   for clients that = process these attributes already

4) The = values that are tagged default are the same ones that the server tags
    as origin=3Ddefault.

5) It still seems to up to the server "basic-mode" as to what = is considered
    "set by default". = This messy aspect of NETCONF is minimized in
<get-data> because
    the server usually returns all values = in use.


/martin



Thanks,
Rob



Andy






Thanks,
Rob



Andy




Andy




Thanks

Mahesh = Jethanandani
mjethanandani@gmail.com

On Feb 5, 2018, at 9:43 = AM, Martin Bjorklund <mbj@tail-f.com> wrote:

Hi,

Mahesh Jethanandani = <mjethanandani@gmail.com> wrote:
This closes the LC for the two NDMA drafts for = NETCONF and RESTCONF.

As part of the LC, = there were a couple of comments/questions
raised. In = particular

- Vladmir reported an error, = which Martin said is fixed in his local
copy.

Fixed.

- Robert suggested that = =E2=80=9C/yang-library/checksum=E2=80=9D should be a
reference. Juergen supported that comment, so I am assuming = that
that will be incorporated into the draft.

Yes, fixed.

- Andy had questions = around datastore set to =E2=80=9Cconventional=E2=80=9D

Fixed.

, about origin filter = limited to 1 source

Fixed.

and the = behavior of with-defaults.

There= were no additional changes to the document from the discussion
about this.

I see some discussion around it with the = authors
agreeing that some of them need some text = clarifying the
position. Can the authors please post the = suggested text/additions
for the WG to review.
- Anything else??

Once an = updated draft has been posted, I will do a writeup on the
drafts and send it to IESG.

The issues above are now addressed, in
draft-ietf-netconf-nmda-netconf-03.

There were no additional comments on
draft-ietf-netconf-nmda-restconf-02, so I believe this = version is
ready.


/martin



Thanks.

On Jan 31, 2018, at = 10:16 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-u= niversity.de> wrote:

On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric = Voit (evoit) wrote:
I do have one additional thought below on
draft-ietf-= netmod-revised-datastores section 5.3 default handling
process.  See in-line...


Well, this document is with the = RFC editor now. I do not think it
needs
clarification. It = already has text in 5.3 such as:

Requests = to retrieve nodes from <operational> always return the
value
in use if the node = exists, regardless of any default value specified
in the = YANG module.  If no value is returned for a given node, then
this implies that the node is not used by the device.

/js

From: Robert Wilton -X, January 31, 2018 6:31 = AM


Hi Andy,

On 31/01/2018 09:22, Andy Bierman wrote:


On Wed, Jan 31, 2018 at 12:11 AM, Juergen = Schoenwaelder <
j.schoenwae= lder@jacobs-university.de <mailto:j.schoenwaelder@jacobs
-university.de><mailto:j.schoenwaelder@jacobs-university.= de <mailto:
j.schoenwaelder@jacobs-university.de>>> wrote:
On Tue, Jan 30, 2018 at = 12:35:33PM -0800, Andy Bierman wrote:
Hi,

I have some questions about these drafts.

1) what if datastore set to "conventional"?
 There are many places where a datastore-ref type is = used.
 However, "conventional" is valid for base = "datastore", even
though
 it = is ambiguous as a datastore selector.

We can add explicit text that an identity that does not = resolve to a
datastore implemented by the server results = in an invalid value
error.


OK


2) origin = filter is limited to 1 source
This filtering seems rather = limited.  A client must retrieve
<with-origin> = and check
 all the values in use, then make repeated = requests for each
source as a
different
 <origin-filter> leaf

If the client does = <with-origin>, then it has all origin information
and = it can filter locally. That said, we could make origin-filter a
leaf-list which is logically ORed so that one can retrieve
origin-filter=3Dor:system or origin-filter=3Dor:learned in = one request.


OK

3) = with-defaults broken
 The operational datastore does = not support with-defaults.
  Instead, the client = must use origin-filter=3Dor:default or
with-origin
  and check all the origin attributes.  Since = a client needs to
use
  with-defaults for other datastores, this special = handling of
<operational>
  seems unhelpful.

I think the with-defaults semantics for conventional = configuration
datastores are much more complicated than = necessary for the
operational state datastore. Note that = that the operational state
datastore reports in-use values = not really defaults:

<leaf = or:origin=3D'default'>foo</leaf>

This reports that the value 'foo' is in use and that it = originates
from a default value. Note that this could also = be

<leaf = or:origin=3D'intended'>foo</leaf>

in= case the intended configuration datastore configured the value
'foo' (despite this value matching the default). The = with-defaults
solution is pretty complex because it tries = to handle how different
systems deal with configuration = defaults. The idea is to not carry
this complexity over to = in-use values in the operational state
datastore.


Before NMDA, the client could = decide if it wanted to retrieve
default = nodes or not.
This client-choice has = been removed from NMDA, which is a problem.
We tried to = reach a sensible compromise on the data returned from
operational= (defined in section 5.3 of the NMDA architecture):
- it should return explicit values for everything that is = affecting
the = actual running state of the device (regardless of whether the
operational value matches a schema default value).
- it does not need to, and should not, return operational = values
for stuff = that isn't actually in use, i.e. don't return needless and
unwanted data.

In = particular, if no value is returned from a particular data node
in = <operational> then, barring mgmt protocol errors, a client can = assume
that any functionality associated with that data = node is off (i.e. not in
use).

Some examples to illustrate the behavior:

(i) If a protocol, e.g. OSPF,  is not enabled/running = then
<operati= onal> does not need to return any data for it.  It would be
reasonable to return a flag to indicate that OSPF is not = enabled/running.

(ii) If = you have some funky widget on an interface that defaults to
being off = and isn't being used then <operational> don't need to return = any
data for it.

(iii) = But, if you have some funky widget on an interface that
defaults = to being on, then the server should return data for it. If it is
actually enabled, then it would indicate that it is on and = return any
associated values with its operational state, = or if it is disabled then it
should explicitly report that = it is off.

(iv) I would regard that all = applied configuration is "in use" by
the = system, even if it matches the default value, and hence it should be
reported.


This behavior for <operational> is obviously slightly = different
from the = existing with-default handling that is supported for configuration
datastores.  As I recall, there were a couple of reasons = that we decided to
have a different behavior for = <operational>:
(a) to have consistent = semantics for all servers, rather than
different = servers supporting different with-defaults behaviors (which makes
life harder for clients because they must cope with all = variants).
(b) to remove any potential ambiguity if data = isn't returned.  I.e.
with the = existing with-defaults semantics it is not clear to me that
servers will always return an explicit value to indicate that = a particular
widget is off if the schema defines that the = default it that is enabled.
If the server doesn't support = a given widget at all, it is quite plausible
that it will = just return no data for it.  In theory features/deviations
should handle this, but those don't work so well if different = linecards
have different capabilities.  Hence being = explicit about stuff that is in
use seems more robust.

<eric> These are good examples.  It = would be great if section 5.3
could be = tweaked to make clearer the relationship between running datastore
defaults and other operational datastore defaults for the = same tree.

For example, let=E2=80=99s say I = create a configured subscription, and the
default = transport protocol is NETCONF.  NETCONF will be used for that
subscription even though the node might not be populated. =  In this case,
the object would not appear in the = running datastore, but MUST* appear in
the operational = datastore with the default origin (as it is in-use).

This to me is the desired behavior as it = doesn=E2=80=99t incorrectly add
information= to the running datastore, but shows what is in-use within
operational.   I suspect other such relationships = for other operational
tree defaults could be asserted, = perhaps based on the origin.

(* Maybe = =E2=80=98MUST eventually=E2=80=99, as obviously there is a temporal
relationshi= p between the two datastores.)

Eric

Thanks,
Rob





/js

Andy

--
Juergen Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen |
Germany
<https://maps.google.com/?q=3DCampus+Ring+1+%7C+28759+Bremen+%7C= +Germany&entry=3Dgmail&source=3Dg>
Fax:   +49 421 200 3103 =         <https://www.jacobs-uni= versity.de/>





_______________________________________________

netmod mailing list

netmod@ietf.org = <mailto:netmod@ietf.org><mailto:netmod@ietf.org
<mailto:= netmod@ietf.org>>

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


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


--
Juergen Schoenwaelder =           Jacobs = University Bremen gGmbH
Phone: +49 421 200 3587 =         Campus Ring 1 | 28759 = Bremen |
Germany
<https://maps.google.com/?q=3DCampus+Ring+1+%7C+28759+Bremen+%7C= +Germany&entry=3Dgmail&source=3Dg>
Fax:   +49 421 = 200 3103 =         <https://www.jacobs-uni= versity.de/ <
https://www.jacobs-unive= rsity.de/>>

_______________________________________________
netmod mailing list
netmod@ietf.org = <mailto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod <
https://www.ietf.org/mai= lman/listinfo/netmod>
Mahesh Jethanandani
mjethanandani@gmail.com


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



_______________________________________________
Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/n= etconf





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

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_4D4DCC4F-24DD-4AA1-8D66-28B33500B47E-- From nobody Wed Feb 7 14:03:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 605B5126D85 for ; Wed, 7 Feb 2018 14:03:01 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5JSzuYAH_Jzq for ; Wed, 7 Feb 2018 14:02:59 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 692D2124239 for ; Wed, 7 Feb 2018 14:02:58 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id x196so3514084lfd.12 for ; Wed, 07 Feb 2018 14:02:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=MC2pn6E9YXqmMyeADqXWyWJyiIF+Z+zO+ciW01jheEA=; b=YbizLR2H8BTC9ibbl7OpGfjw4HB/vYcpb3ab22+0l+xc7sewiCvZXRETTKpYfT9sv5 tWSemV89Do4CoBcf8gh0Xxbx677eIz73uYtBtr7Jk6T38s/oksrbAt20EZeLaD0qC90j LtYEZqQcqZ+Hc8T1AfEyycmyxu+lALmNRYi3+aUwQTimiM1cjku+RbfYhmXnMTwYkowB r/sc2Fh54mNLTGc5eI4M5zv9T3vlW+/6IKQNcjILsrJP7YIH0PEm7VmaixElGbRf6prs 1VBBVqrF+deUNXanLPK7HmlhPTmfdRqW+hFJwfT+WmxFxEoZMZ/3rptzUWedSa/OB2Oe j6Xg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=MC2pn6E9YXqmMyeADqXWyWJyiIF+Z+zO+ciW01jheEA=; b=K9bUxyJ9PY81wmK48hTgm06vOUMCUJ7ACj4h0gn7g7h5vqwEJhaIzPBWT7YJGtRQkb mMWtDeWQQwEmniVCbOnU9BkUirPfC7EfP3FOa1FxCkPr6Hm8cX05UGu/w5ZSkigzPCRh 5HA4nIR4xuIAauxs8y+A7NhUzQtWflfEVLp5eYlggREkBOREzo1aP+lOxt6xjymD7sD0 sfJnl/9MUtizhzvx1X/6scYKsHbuZZTHQNkfZqCpjegGIXpn9kE1jlG6xT/qWHxxiMY3 b186SObksZXgOmxMWe5ie3tzGSyykYfmYSG4qXd+GLt1y2ZUnG1nlNJ22AsUIKUCChh4 WMYw== X-Gm-Message-State: APf1xPBiGlu9V4puQNuJPTRIe4Kxc0I9I1UybG0Lr2JgzwoT1zvKpR4i Tj2E+ckmjWD30pV6ozOdnMX53feqbZdTMTTxnTZV2Q== X-Google-Smtp-Source: AH8x227X/VMq+QP+e4k0CazT6eX6YxxzyLZula2liIJdns/rDlwV2OYsIltkDRNRjY641j1kUYVvSiw14/F31r7xcDg= X-Received: by 10.25.26.200 with SMTP id a191mr4495567lfa.35.1518040976622; Wed, 07 Feb 2018 14:02:56 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.143.6 with HTTP; Wed, 7 Feb 2018 14:02:55 -0800 (PST) In-Reply-To: <201802071859.w17IxjwU073675@idle.juniper.net> References: <201802071859.w17IxjwU073675@idle.juniper.net> From: Andy Bierman Date: Wed, 7 Feb 2018 14:02:55 -0800 Message-ID: To: Phil Shafer Cc: joel jaeggli , NETMOD Working Group Content-Type: multipart/alternative; boundary="001a11401eda2a94100564a6758e" Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 22:03:01 -0000 --001a11401eda2a94100564a6758e Content-Type: text/plain; charset="UTF-8" Hi, Many good points. IMO it will be difficult to agree on the details of this draft without agreeing on the problem statement first. As a process issue, this seems like an important step. It is usually handled with WG charter text, but NETMOD has a free pass on new YANG modules somehow. I am interested in these tags as a new type of standard selection filter. It can be applied to data retrieval, NACM rules, YANG push subtree selection, and probably many more use-cases. So the problem statement might be: There is a need for standardized mechanisms to classify YANG data nodes with tags, which can be used in protocol operations to select matching data nodes, based on tag values. This work includes the management and assignment of tags, and their generalized use within protocol operations. Andy On Wed, Feb 7, 2018 at 10:59 AM, Phil Shafer wrote: > Andy Bierman writes: > >The draft avoids discussion of any useful operations based on tags. > > Nor does it really clearly say "what" is being tagged. The absract > talks about "used to help classify and organize modules", but the > Introduction lacks any expansion on this. There's really no clear > problem statement or a clear definition of why we need tags or what > one would use them for. > > It would also be helpful to understand why "#hashtag" and the string > format ("ietf:routing", "vendor:super-duper:...") are chosen over > YANG identities. It seems like identity naming standards and inheritance > would be good features. > > Also it's not clear why these would be configurable rather that > controlled by the module author. I'd rather have the OAM standard > YANG module say something like: > > module ietf-oam { > import "ietf-category" { prefix ietf-category; } > > identify ietf-oam { > base ietf-category:ietf-standard; > description "This module category represents something > OAM related."; > } > > ietf-category:module-category ietf-oam; > ... > } > > The draft says: > > Implementations that do not support the reset rpc statement (whether > at all, or just for a particular rpc or module) MUST respond with an > YANG transport protocol-appropriate rpc layer error when such a > statement is received. > > The entire idea of NETCONF/YANG is that the client _knows_ what it > can safely send instead of tossing spaghetti at the wall until > something sticks. Avoid programming-by-error-detection, which > creates fragile infrastructure. > > Use "feature" to control optional portions of a YANG module. I'd > suggest one feature for "reset" support and another for "read-only", > since IMHO the idea of someone munging the categories of standard > modules is, well, disconcerting. > > "Local" tags are not well explained. The idea of a user/admin > tagging modules means that something is broken. Users shouldn't > understand YANG modules. Users use applications, some of which are > home-grown. Is "local" appropriate for my "audit interfaces" script? > > 6.1 is missing the list "module-tags". > > 9.1 advocates putting vital information in the description string, > which is IMHO not a good idea. We want to put as much information > in machine-readable format as possible, so I can ask ietf.org > questions like "give me a list of ietf-oam-related yang modules" > and get a nice list. > > It also talks about "SHOULD" and "MAY" tags without giving any > clue as to why or when this would be appropriate or useful. > > So my vote would be that this document needs some significant work > and expansion before it's a supportable draft. I think the authors > have more in their heads than they've put into the draft and I'd > like to see the rest of their thoughts. > > Thanks, > Phil > --001a11401eda2a94100564a6758e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

Many good points.
IMO it = will be difficult to agree on the details of this draft
without a= greeing on the problem statement first.
As a process issue, this = seems like an important step.
It is usually handled with WG chart= er text, but NETMOD
has a free pass on new YANG modules somehow.<= /div>

I am interested in these tags as a new type of sta= ndard selection filter.
It can be applied to data retrieval, NACM= rules, YANG push subtree selection,
and probably many more use-c= ases.=C2=A0 So the problem statement
might be:

=C2=A0 =C2=A0There is a need for standardized mechanisms to classify= YANG data nodes with tags,
=C2=A0 =C2=A0which can be used in pro= tocol operations to select matching data nodes, based on tag values.
<= div>=C2=A0 =C2=A0This work includes the management and assignment of tags, = and their generalized use
=C2=A0 =C2=A0within protocol operations= .


Andy
=

On Wed,= Feb 7, 2018 at 10:59 AM, Phil Shafer <phil@juniper.net> wrot= e:
Andy Bierman writes:
>The draft avoids discussion of any useful operations based on tags.

Nor does it really clearly say "what" is being tagged.=C2=A0 The = absract
talks about "used to help classify and organize modules", but the=
Introduction lacks any expansion on this.=C2=A0 There's really no clear=
problem statement or a clear definition of why we need tags or what
one would use them for.

It would also be helpful to understand why "#hashtag" and the str= ing
format ("ietf:routing", "vendor:super-duper:...") are c= hosen over
YANG identities.=C2=A0 It seems like identity naming standards and inherita= nce
would be good features.

Also it's not clear why these would be configurable rather that
controlled by the module author.=C2=A0 I'd rather have the OAM standard=
YANG module say something like:

=C2=A0 =C2=A0 module ietf-oam {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 import "ietf-category" { prefix ietf-= category; }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 identify ietf-oam {
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 base ietf-category:ietf-standard;=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "This module cat= egory represents something
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0OAM related.";
=C2=A0 =C2=A0 =C2=A0 =C2=A0 }

=C2=A0 =C2=A0 =C2=A0 =C2=A0 ietf-category:module-category ietf-oam;
=C2=A0 =C2=A0 =C2=A0 =C2=A0 ...
=C2=A0 =C2=A0 }

The draft says:

=C2=A0 =C2=A0Implementations that do not support the reset rpc statement (w= hether
=C2=A0 =C2=A0at all, or just for a particular rpc or module) MUST respond w= ith an
=C2=A0 =C2=A0YANG transport protocol-appropriate rpc layer error when such = a
=C2=A0 =C2=A0statement is received.

The entire idea of NETCONF/YANG is that the client _knows_ what it
can safely send instead of tossing spaghetti at the wall until
something sticks.=C2=A0 Avoid programming-by-error-detection, which creates fragile infrastructure.

Use "feature" to control optional portions of a YANG module.=C2= =A0 I'd
suggest one feature for "reset" support and another for "rea= d-only",
since IMHO the idea of someone munging the categories of standard
modules is, well, disconcerting.

"Local" tags are not well explained.=C2=A0 The idea of a user/adm= in
tagging modules means that something is broken.=C2=A0 Users shouldn't understand YANG modules.=C2=A0 Users use applications, some of which are home-grown.=C2=A0 Is "local" appropriate for my "audit inter= faces" script?

6.1 is missing the list "module-tags".

9.1 advocates putting vital information in the description string,
which is IMHO not a good idea.=C2=A0 We want to put as much information
in machine-readable format as possible, so I can ask ietf.org
questions like "give me a list of ietf-oam-related yang modules"<= br> and get a nice list.

It also talks about "SHOULD" and "MAY" tags without giv= ing any
clue as to why or when this would be appropriate or useful.

So my vote would be that this document needs some significant work
and expansion before it's a supportable draft.=C2=A0 I think the author= s
have more in their heads than they've put into the draft and I'd like to see the rest of their thoughts.

Thanks,
=C2=A0Phil

--001a11401eda2a94100564a6758e-- From nobody Wed Feb 7 14:04:22 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 56B6C127735 for ; Wed, 7 Feb 2018 14:04:20 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bQS6RhtFxNAh for ; Wed, 7 Feb 2018 14:04:16 -0800 (PST) Received: from mail-lf0-x233.google.com (mail-lf0-x233.google.com [IPv6:2a00:1450:4010:c07::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 D68791270AB for ; Wed, 7 Feb 2018 14:04:15 -0800 (PST) Received: by mail-lf0-x233.google.com with SMTP id f136so3545330lff.8 for ; Wed, 07 Feb 2018 14:04:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=SzQKASp6b4y/U3AQeeemlx6IgF/jkWgw3zuHp/I52M4=; b=Yu+4O0E1LtPQ+jHlTB734SbmhXPbfEuVwUoSAOKthGJdhgmlZjzQgWr404NLb07LWK gJAbC2bV9GeAwTL/Ti/pRhptuIS7Hk5wgjcvuLQsjHCkll2tfsw2SKCcyXvbqmalJXmg 9SvGXLnFaIKQAtN4xALH8dkopp4gE21ao2ajIyVBkak9ObkjjeaBqK4uAbXd75uSO7C0 LGkZCsI+nRyRW3dU7V76jjudoHsvIeG58BV67ve+U7+ivAkUjVMWynP+1FVtbXvbrujv SFByiKpC1yHTohjKexBsjansTOeAxXFikG+HNq2Hw8e6Afn1itV8xCw02DmS/z/+pVVJ RY0w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=SzQKASp6b4y/U3AQeeemlx6IgF/jkWgw3zuHp/I52M4=; b=udB1nBkMeWp/ZspbizDnSR02dbOPd8nqrkBoxiNWA8FPLaDxu7tvuDwbsfdFXeX1Fb U0NQuSrSd+z/4c0kowUAvbF47TsduN0JIlQRk4ZbK05e/7Q9Y8teRKQvUBgtP/7wXH+X CHZh2lia21cXus3RvBiGCrAHRwR5oXUoJbNylI3hLXIoamwzds01hpdztSZy9SxHuZg5 Klgck4LfNl943Lt/LghkMsteIq2QBpPC79hd/ZFR5CWoEFNygQRG4u9x1P5EROGw2heh l/mtLV6BGSEuexEabQDzdKJJfhLYvqGDDbl0evCciLqBFPQ2zgUYSwvBCfAliq7MfrRv +PVQ== X-Gm-Message-State: APf1xPB8Jo6K7PG/JJgG+uN1fjw6Sfm02h9wg6kd7glQhM6qA27rjlRd Ng0Lu0M26mExfCx2N67Ij3cUXxElzhtR+65cPe1Thg== X-Google-Smtp-Source: AH8x224bladNnyyBsnOhZzn7D1mUsOWzpljIs4Qv090yz7iAWwu6TmaA09u3khMUIj96APuHYxWZCfnZW/l9n/KNFls= X-Received: by 10.46.93.156 with SMTP id v28mr4836823lje.5.1518041053914; Wed, 07 Feb 2018 14:04:13 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.143.6 with HTTP; Wed, 7 Feb 2018 14:04:13 -0800 (PST) In-Reply-To: <4A22F659-0656-4382-964D-B9319AF5CE93@gmail.com> References: <20180207.192803.834988416883038576.mbj@tail-f.com> <4A22F659-0656-4382-964D-B9319AF5CE93@gmail.com> From: Andy Bierman Date: Wed, 7 Feb 2018 14:04:13 -0800 Message-ID: To: Mahesh Jethanandani Cc: Martin Bjorklund , Netconf , NetMod WG Content-Type: multipart/alternative; boundary="001a114cbd74c5ff880564a679ac" Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 22:04:20 -0000 --001a114cbd74c5ff880564a679ac Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 7, 2018 at 1:58 PM, Mahesh Jethanandani wrote: > It appears that there is some consensus around the issue of > =E2=80=9Cwith-defaults=E2=80=9D for operational datastore. Andy, would yo= u agree with what > has been suggested? > > Yes. > It also appears that text needs to be added to explain the behavior w.r.t= . > operational datastore. If everyone agrees, authors, can you propose the > text that needs to be updated. > > Thanks. > > Andy > On Feb 7, 2018, at 10:28 AM, Martin Bjorklund wrote: > > Andy Bierman wrote: > > On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton wrote: > > > > On 07/02/2018 14:23, Andy Bierman wrote: > > > > On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton wrote: > > Hi Andy, > > On 07/02/2018 02:33, Andy Bierman wrote: > > > > On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani < > mjethanandani@gmail.com> wrote: > > For folks that provided comments as part of LC, please verify that your > comments have been adequately addressed by -03 version of the draft. > > > > Most comments have been addressed. > > > The "with-defaults" parameter does not apply when interacting with an > > operational datastore. > > > There is no explanation of why the with-defaults parameter does not apply > to . > This is confusing. The solution that has been a standard for years still > applies to > all datastores, except a completely different mechanism (origin-filter) > is used instead > for 1 datastore. > > If the server code can identify a default so it can be tagged > origin=3Dor:default, then it can > also support with-defaults. > > I prefer the sentence above be changed, so that a server MAY implement > with-defaults > for . If the client sends it should be OK > to honor it instead > of returning an error. > > I have two concerns with changing this to a MAY: > > (1) The most useful "with-defaults" behavior differs for vs > the configuration datastores, but with-defaults only allows a single > standard behavior to be specified. > > E.g. for configuration datastores the most appropriate semantics (if the > client doesn't explicitly ask for something else) is "explicit". i.e. you > give back exactly what was put in. > > But, for operational, the most appropriate semantics (if the client > doesn't explicitly ask for something else) is something like "report-all"= , > i.e. the device reports the precise current state including any defaults. > However, we felt that this would return too much unnecessary data, hence > why the datastore architecture defines "in-use" data, allowing the server > to prune out any data that is clearly irrelevant. > > (2) is a new datastore. I personally don't want each > server choosing how the data is returned, which requires that clients mus= t > handle all variants. It would be better for the draft to specify the > standard semantics to use unless a client has explicitly requested > something else. > > I'm not opposed to a "with-defaults-bis", or a new draft covering > "with-defaults" for ", but I think that: > (i) We shouldn't delay the NMDA protocol drafts for this, this can be > done as separate draft adding extra optional functionality. > (ii) The semantics for retrieving data from operational (or > notifications) should be as defined by "in-use" in the NMDA architecture, > unless a client has explicitly specified, or configured, a different > behavior. > (iii) Probably the only existing option defined in "with-defaults" that > makes sense for is a variant of "trim" that is specified to > return what is defined as returning the "in-use" values, but also excludi= ng > any values that match a default value specified in the schema. > > > > I think your approach violates the Postel Principle. > "Be liberal in what you accept" is about robustness. > Rejecting parameters for no good reason is about fragility. > > I never said change the behavior for if no > is present. > If the parameter is provided it is trivial for the server to honor it. > The most useful value (report-all) is the default, not leave out all > defaults, like . > > OK, so one option is to allow the "with-defaults" parameter for the > datastore, but specify in both the NETCONF NMDA and RESTCON= F > NMDA drafts how "with-defaults" semantics apply to any operational > datastore: > > 1) Regardless of what is reported in the "basic-mode" capability > parameter, the default behavior for is "report-all", with > semantics as described below: > 2) "report-all" for operational datastores is defined as returning all "i= n > use" values (i.e. as specified in section 5.3 of the NMDA architecture, s= o > default values that are not "in use" are not returned). > 3) "trim" for operational datastores is defined as returning all "in-use" > values (... as 5.3) except that values that match the value specified in > the schema "default" statement are omitted. Note, clients cannot > distinguish between a value that is omitted because it is not in use, vs = a > value that is omitted because it matches the schema default. > 4) "explicit" for operational datastores is defined as returning the same > as "report-all", defined above. > 5) "report-all-tagged" for operational datastores is defined as returning > the same as "report-all", except that all values that match the values > specified in the schema "default" statement are tagged, as described in > with-defaults (RFC 5243). > > Also note - there is no change in semantics or behavior to how > "with-defaults" works for conventional datastores. > > Thoughts? > > > This looks good. > > Showing the work... > > 1) there is no YANG default for parameter. > The behavior if this parameter is missing is determined by the operati= on > > > Right. So in this case (get-data of operational), it would return all > default values in use. > > 2) The operation returns all values in use. > The only way to suppress defaults is to use > (e.g., request all origins except 'default') > > > Or use with-defaults =3D trim. > > 3) The parameter for is mostly a NO-OP. > It does not add or remove any nodes that would be returned. > The "report-all-tagged" value does add the "default> attribute, which > is useful > for clients that process these attributes already > > 4) The values that are tagged default are the same ones that the server > tags > as origin=3Ddefault. > > 5) It still seems to up to the server "basic-mode" as to what is consider= ed > "set by default". This messy aspect of NETCONF is minimized in > because > the server usually returns all values in use. > > > > > /martin > > > > > > Thanks, > > Rob > > > > Andy > > > > > > > Thanks, > Rob > > > > Andy > > > > > Andy > > > > > Thanks > > Mahesh Jethanandani > mjethanandani@gmail.com > > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund wrote: > > Hi, > > Mahesh Jethanandani wrote: > > This closes the LC for the two NDMA drafts for NETCONF and RESTCONF. > > As part of the LC, there were a couple of comments/questions > raised. In particular > > - Vladmir reported an error, which Martin said is fixed in his local > > copy. > > > Fixed. > > - Robert suggested that =E2=80=9C/yang-library/checksum=E2=80=9D should b= e a > reference. Juergen supported that comment, so I am assuming that > that will be incorporated into the draft. > > > Yes, fixed. > > - Andy had questions around datastore set to =E2=80=9Cconventional=E2=80= =9D > > > Fixed. > > , about origin filter limited to 1 source > > > Fixed. > > and the behavior of with-defaults. > > > There were no additional changes to the document from the discussion > about this. > > I see some discussion around it with the authors > agreeing that some of them need some text clarifying the > position. Can the authors please post the suggested text/additions > for the WG to review. > - Anything else?? > > Once an updated draft has been posted, I will do a writeup on the > drafts and send it to IESG. > > > The issues above are now addressed, in > draft-ietf-netconf-nmda-netconf-03. > > There were no additional comments on > draft-ietf-netconf-nmda-restconf-02, so I believe this version is > ready. > > > /martin > > > > Thanks. > > On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote: > > > I do have one additional thought below on > > draft-ietf-netmod-revised-datastores section 5.3 default handling > process. See in-line... > > > > Well, this document is with the RFC editor now. I do not think it > > needs > > clarification. It already has text in 5.3 such as: > > Requests to retrieve nodes from always return the > > value > > in use if the node exists, regardless of any default value specified > in the YANG module. If no value is returned for a given node, then > this implies that the node is not used by the device. > > /js > > From: Robert Wilton -X, January 31, 2018 6:31 AM > > > Hi Andy, > > On 31/01/2018 09:22, Andy Bierman wrote: > > > On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de -university.de> j.schoenwaelder@jacobs-university.de>>> wrote: > > On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: > Hi, > > I have some questions about these drafts. > > 1) what if datastore set to "conventional"? > There are many places where a datastore-ref type is used. > However, "conventional" is valid for base "datastore", even > > though > > it is ambiguous as a datastore selector. > > > We can add explicit text that an identity that does not resolve to a > datastore implemented by the server results in an invalid value > > error. > > > > OK > > > 2) origin filter is limited to 1 source > This filtering seems rather limited. A client must retrieve > and check > all the values in use, then make repeated requests for each > > source as a > > different > leaf > > > If the client does , then it has all origin information > and it can filter locally. That said, we could make origin-filter a > leaf-list which is logically ORed so that one can retrieve > origin-filter=3Dor:system or origin-filter=3Dor:learned in one request. > > > OK > > 3) with-defaults broken > The operational datastore does not support with-defaults. > Instead, the client must use origin-filter=3Dor:default or > > with-origin > > and check all the origin attributes. Since a client needs to > > use > > with-defaults for other datastores, this special handling of > > seems unhelpful. > > > I think the with-defaults semantics for conventional configuration > datastores are much more complicated than necessary for the > operational state datastore. Note that that the operational state > datastore reports in-use values not really defaults: > > foo > > This reports that the value 'foo' is in use and that it originates > from a default value. Note that this could also be > > foo > > in case the intended configuration datastore configured the value > 'foo' (despite this value matching the default). The with-defaults > solution is pretty complex because it tries to handle how different > systems deal with configuration defaults. The idea is to not carry > this complexity over to in-use values in the operational state > datastore. > > > Before NMDA, the client could decide if it wanted to retrieve > > default nodes or not. > > This client-choice has been removed from NMDA, which is a problem. > We tried to reach a sensible compromise on the data returned from > > operational (defined in section 5.3 of the NMDA architecture): > > - it should return explicit values for everything that is affecting > > the actual running state of the device (regardless of whether the > operational value matches a schema default value). > > - it does not need to, and should not, return operational values > > for stuff that isn't actually in use, i.e. don't return needless and > unwanted data. > > > In particular, if no value is returned from a particular data node > > in then, barring mgmt protocol errors, a client can assume > that any functionality associated with that data node is off (i.e. not in > use). > > > Some examples to illustrate the behavior: > > (i) If a protocol, e.g. OSPF, is not enabled/running then > > does not need to return any data for it. It would be > reasonable to return a flag to indicate that OSPF is not enabled/running. > > > (ii) If you have some funky widget on an interface that defaults to > > being off and isn't being used then don't need to return an= y > data for it. > > > (iii) But, if you have some funky widget on an interface that > > defaults to being on, then the server should return data for it. If it is > actually enabled, then it would indicate that it is on and return any > associated values with its operational state, or if it is disabled then i= t > should explicitly report that it is off. > > > (iv) I would regard that all applied configuration is "in use" by > > the system, even if it matches the default value, and hence it should be > reported. > > > > This behavior for is obviously slightly different > > from the existing with-default handling that is supported for configurati= on > datastores. As I recall, there were a couple of reasons that we decided = to > have a different behavior for : > > (a) to have consistent semantics for all servers, rather than > > different servers supporting different with-defaults behaviors (which mak= es > life harder for clients because they must cope with all variants). > > (b) to remove any potential ambiguity if data isn't returned. I.e. > > with the existing with-defaults semantics it is not clear to me that > servers will always return an explicit value to indicate that a particula= r > widget is off if the schema defines that the default it that is enabled. > If the server doesn't support a given widget at all, it is quite plausibl= e > that it will just return no data for it. In theory features/deviations > should handle this, but those don't work so well if different linecards > have different capabilities. Hence being explicit about stuff that is in > use seems more robust. > > > These are good examples. It would be great if section 5.3 > > could be tweaked to make clearer the relationship between running datasto= re > defaults and other operational datastore defaults for the same tree. > > > For example, let=E2=80=99s say I create a configured subscription, and th= e > > default transport protocol is NETCONF. NETCONF will be used for that > subscription even though the node might not be populated. In this case, > the object would not appear in the running datastore, but MUST* appear in > the operational datastore with the default origin (as it is in-use). > > > This to me is the desired behavior as it doesn=E2=80=99t incorrectly add > > information to the running datastore, but shows what is in-use within > operational. I suspect other such relationships for other operational > tree defaults could be asserted, perhaps based on the origin. > > > (* Maybe =E2=80=98MUST eventually=E2=80=99, as obviously there is a tempo= ral > > relationship between the two datastores.) > > > Eric > > Thanks, > Rob > > > > > > > /js > > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > > Germany > > Bremen+%7C+Germany&entry=3Dgmail&source=3Dg> > > Fax: +49 421 200 3103 > > > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > > > > https://www.ietf.org/mailman/listinfo/netmod < > > https://www.ietf.org/mailman/listinfo/netmod> > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod < > > https://www.ietf.org/mailman/listinfo/netmod> > > > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > > Germany > Bremen+%7C+Germany&entry=3Dgmail&source=3Dg> > > Fax: +49 421 200 3103 > https://www.jacobs-university.de/>> > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod < > > https://www.ietf.org/mailman/listinfo/netmod> > > Mahesh Jethanandani > mjethanandani@gmail.com > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > > > _______________________________________________ > Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo= / > netconf > > > > > > _______________________________________________ > Netconf mailing list > Netconf@ietf.org > https://www.ietf.org/mailman/listinfo/netconf > > > Mahesh Jethanandani > mjethanandani@gmail.com > > --001a114cbd74c5ff880564a679ac Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 7, 2018 at 1:58 PM, Mahesh Jethanandani &= lt;mjethananda= ni@gmail.com> wrote:
It appears that = there is some consensus around the issue of =E2=80=9Cwith-defaults=E2=80=9D= for operational datastore. Andy, would you agree with what has been sugges= ted?


Yes.
=C2=A0
It also appea= rs that text needs to be added to explain the behavior w.r.t. operational d= atastore. If everyone agrees, authors, can you propose the text that needs = to be updated.

Thanks.


Andy
=C2=A0
On Feb 7, 2018, at 10:28 = AM, Martin Bjorklund <mbj@tail-f.com> wrote:

Andy Bier= man <andy@yuma= works.com> wrote:
On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton <rwilton@cisco.com> wrote:=



On 07/02/2018 14:23, Andy Bierman= wrote:



On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton <rwilton@cisco.com&= gt; wrote:

Hi Andy,

On 07/02/2018 0= 2:33, Andy Bierman wrote:



On Mon, Feb 5, 2018 at 1:33 PM, Ma= hesh Jethanandani <
mjethanandani@gmail.com> wrote:

For folks that provided comments as part of LC, please verify tha= t your
comments have been adequately addressed by -03 version of the dra= ft.



Most comments have been addressed.

<= br>=C2=A0=C2=A0=C2=A0The "with-defaults" parameter does not apply= when interacting with an

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= operational datastore.


There is no explanation of why the with-d= efaults parameter does not apply
to <operational>.
This is conf= using. The solution that has been a standard for years still
applies to<= br>all datastores, except a completely different mechanism (origin-filter)<= br>is used instead
for 1 datastore.

If the server code can identi= fy a default so it can be tagged
origin=3Dor:default, then it can
als= o support with-defaults.

I prefer the sentence above be changed, so = that a server MAY implement
with-defaults
for <operational>.=C2= =A0 If the client sends <with-defaults> it should be OK
to honor i= t instead
of returning an error.

I have two concerns with changin= g this to a MAY:

(1) The most useful "with-defaults" behav= ior differs for <operational> vs
the configuration datastores, but= with-defaults only allows a single
standard behavior to be specified.
E.g. for configuration datastores the most appropriate semantics (if = the
client doesn't explicitly ask for something else) is "expli= cit". i.e. you
give back exactly what was put in.

But, for o= perational, the most appropriate semantics (if the client
doesn't ex= plicitly ask for something else) is something like "report-all",<= br>i.e. the device reports the precise current state including any defaults= .
However, we felt that this would return too much unnecessary data, hen= ce
why the datastore architecture defines "in-use" data, allow= ing the server
to prune out any data that is clearly irrelevant.

= (2) <operational> is a new datastore.=C2=A0 I personally don't wa= nt each
server choosing how the data is returned, which requires that cl= ients must
handle all variants.=C2=A0 It would be better for the draft t= o specify the
standard semantics to use unless a client has explicitly r= equested
something else.

I'm not opposed to a "with-defa= ults-bis", or a new draft covering
"with-defaults" for &l= t;operational>", but I think that:
(i) We shouldn't delay th= e NMDA protocol drafts for this, this can be
done as separate draft addi= ng extra optional functionality.
(ii) The semantics for retrieving data = from operational (or
notifications) should be as defined by "in-use= " in the NMDA architecture,
unless a client has explicitly specifie= d, or configured, a different
behavior.
(iii) Probably the only exist= ing option defined in "with-defaults" that
makes sense for <= ;operational> is a variant of "trim" that is specified to
r= eturn what is defined as returning the "in-use" values, but also = excluding
any values that match a default value specified in the schema.=



I think your approach violates the Postel Prin= ciple.
"Be liberal in what you accept" is about robustness.Rejecting parameters for no good reason is about fragility.

I never= said change the behavior for <operational> if no <with-defaults&g= t;
is present.
If the parameter is provided it is trivial for the ser= ver to honor it.
The most useful value (report-all) is the default, not = leave out all
defaults, like <get-config>.

OK, so one optio= n is to allow the "with-defaults" parameter for the
<operat= ional> datastore, but specify in both the NETCONF NMDA and RESTCONF
N= MDA drafts how "with-defaults" semantics apply to any operational=
datastore:

1) Regardless of what is reported in the "basic-= mode" capability
parameter, the default behavior for <operationa= l> is "report-all", with
semantics as described below:
2= ) "report-all" for operational datastores is defined as returning= all "in
use" values (i.e. as specified in section 5.3 of the = NMDA architecture, so
default values that are not "in use" are= not returned).
3) "trim" for operational datastores is define= d as returning all "in-use"
values (... as 5.3) except that va= lues that match the value specified in
the schema "default" st= atement are omitted.=C2=A0 Note, clients cannot
distinguish between a va= lue that is omitted because it is not in use, vs a
value that is omitted= because it matches the schema default.
4) "explicit" for oper= ational datastores is defined as returning the same
as "report-all&= quot;, defined above.
5) "report-all-tagged" for operational d= atastores is defined as returning
the same as "report-all", ex= cept that all values that match the values
specified in the schema "= ;default" statement are tagged, as described in
with-defaults (RFC = 5243).

Also note - there is no change in semantics or behavior to ho= w
"with-defaults" works for conventional datastores.

Th= oughts?


This looks good.

Showing the work...=

1) there is no YANG default for <with-defaults> parameter.=C2=A0=C2=A0=C2=A0The behavior if this parameter is missing is determined = by the operation

Right.= =C2=A0 So in this case (get-data of operational), it would return all
= default values in use.

2) The <get-data> operation returns all values in use.
= =C2=A0=C2=A0=C2=A0The only way to suppress defaults is to use <origin-fi= lter>
=C2=A0=C2=A0=C2=A0(e.g., request all origins except 'defaul= t')

Or use with-def= aults =3D trim.

3) The <with-defaults> param= eter for <operational> is mostly a NO-OP.
=C2=A0=C2=A0=C2=A0It doe= s not add or remove any nodes that would be returned.
=C2=A0=C2=A0=C2=A0= The "report-all-tagged" value does add the "default> attr= ibute, which
is useful
=C2=A0=C2=A0=C2=A0for clients that process the= se attributes already

4) The values that are tagged default are the = same ones that the server tags
=C2=A0=C2=A0=C2=A0=C2=A0as origin=3Ddefau= lt.

5) It still seems to up to the server "basic-mode" as = to what is considered
=C2=A0=C2=A0=C2=A0=C2=A0"set by default"= . This messy aspect of NETCONF is minimized in
<get-data> because<= br>=C2=A0=C2=A0=C2=A0=C2=A0the server usually returns all values in use.



/martin





Thanks,
Rob



Andy






Thanks,
Rob



Andy


=


Andy




Thanks

Mahesh Jethanandani
mjethanandani@gmail.com

On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:<= br>
Hi,

Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
This closes the LC for the two NDMA drafts for NETCONF= and RESTCONF.

As part of the LC, there were a couple of comments/qu= estions
raised. In particular

- Vladmir reported an error, which = Martin said is fixed in his local
copy.

Fixed.

- Robert= suggested that =E2=80=9C/yang-library/checksum=E2=80=9D should be a
ref= erence. Juergen supported that comment, so I am assuming that
that will = be incorporated into the draft.

Yes, fixed.

- Andy had questions around datastore set to =E2=80= =9Cconventional=E2=80=9D

Fixed.

, about origin filter limited to 1 source

Fix= ed.

and the behavior of with-defaults.
=

There were no additional changes to the document from the = discussion
about this.

I see some discu= ssion around it with the authors
agreeing that some of them need some te= xt clarifying the
position. Can the authors please post the suggested te= xt/additions
for the WG to review.
- Anything else??

Once an u= pdated draft has been posted, I will do a writeup on the
drafts and send= it to IESG.

The issues above are now addressed, in
= draft-ietf-netconf-nmda-netconf-03.

There were no additional co= mments on
draft-ietf-netconf-nmda-restconf-02, so I believe this ve= rsion is
ready.


/martin


=
Thanks.

On Jan 31, 2018, at 10:16 AM, = Juergen Schoenwaelder <
j.schoe= nwaelder@jacobs-university.de> wrote:

On Wed, Jan 31,= 2018 at 04:53:48PM +0000, Eric Voit (evoit) wrote:

I do have one additional thought below on
draft-ietf-netmod-revised-datastores s= ection 5.3 default handling
process.=C2=A0 See in-line...


Well, this document is with the RFC = editor now. I do not think it
nee= ds
clarification. It already has text in 5.3 such as:

Request= s to retrieve nodes from <operational> always return the
value
in use if the node exists, regard= less of any default value specified
in the YANG module.=C2=A0 If no valu= e is returned for a given node, then
this implies that the node is not u= sed by the device.

/js

From: Robert= Wilton -X, January 31, 2018 6:31 AM


Hi Andy,

On 31/01/20= 18 09:22, Andy Bierman wrote:


On Wed, Jan 31, 2018 at 12:11 AM, = Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs<= br>-university.de>= ;<mailto:j.schoenwaelder@jacobs-university.de <mailto:<= br>j.schoenwaelder@jacobs-university.de>>> wrote:
On Tue, Jan 30, 2018 at 1= 2:35:33PM -0800, Andy Bierman wrote:
Hi,

I have some questions ab= out these drafts.

1) what if datastore set to "conventional&quo= t;?
=C2=A0There are many places where a datastore-ref type is used.
= =C2=A0However, "conventional" is valid for base "datastore&q= uot;, even
though
=C2=A0= it is ambiguous as a datastore selector.

We can add exp= licit text that an identity that does not resolve to a
datastore impleme= nted by the server results in an invalid value
error.


O= K


2) origin filter is limited to 1 sou= rce
This filtering seems rather limited.=C2=A0 A client must retrieve<with-origin> and check
=C2=A0all the values in use, then make re= peated requests for each
source as a
different
=C2=A0<origin-filter> leaf
=
If the client does <with-origin>, then it has all origin informat= ion
and it can filter locally. That said, we could make origin-filter a<= br>leaf-list which is logically ORed so that one can retrieve
origin-fil= ter=3Dor:system or origin-filter=3Dor:learned in one request.


OK=

3) with-defaults broken
=C2=A0The oper= ational datastore does not support with-defaults.
=C2=A0=C2=A0Instead, t= he client must use origin-filter=3Dor:default or
with-origin
=C2=A0=C2=A0and check all the origin= attributes.=C2=A0 Since a client needs to
use
=C2=A0=C2=A0with-defaults for other datastores, this= special handling of
<operational>
=C2=A0=C2=A0seems unhelpful.=

I think the with-defaults semantics for conventional c= onfiguration
datastores are much more complicated than necessary for the=
operational state datastore. Note that that the operational state
da= tastore reports in-use values not really defaults:

<leaf or:origi= n=3D'default'>foo</leaf>

This reports that the valu= e 'foo' is in use and that it originates
from a default value. N= ote that this could also be

<leaf or:origin=3D'intended'&= gt;foo</leaf>

in case the intended configuration datastor= e configured the value
'foo' (despite this value matching the de= fault). The with-defaults
solution is pretty complex because it tries to= handle how different
systems deal with configuration defaults. The idea= is to not carry
this complexity over to in-use values in the operationa= l state
datastore.


Before NMDA, the client could decide if it= wanted to retrieve
= default nodes or not.
This client-choice ha= s been removed from NMDA, which is a problem.
We tried to reach a sensib= le compromise on the data returned from
operational (defined in section 5.3 of the NMDA archite= cture):
- it should return explicit values = for everything that is affecting
=
the actual running state of the device (regardless of whether = the
operational value matches a schema default value).
- it does not need to, and should not, return operational va= lues
for stuff that = isn't actually in use, i.e. don't return needless and
unwanted d= ata.

In particular, if no value is retu= rned from a particular data node
=
in <operational> then, barring mgmt protocol errors, a c= lient can assume
that any functionality associated with that data node i= s off (i.e. not in
use).

Some exam= ples to illustrate the behavior:

(i) If a protocol, e.g. OSPF, =C2= =A0is not enabled/running then
<operational> does not need to return any data for it.=C2= =A0 It would be
reasonable to return a flag to indicate that OSPF is not= enabled/running.

(ii) If you have some= funky widget on an interface that defaults to
being off and isn't being used then <oper= ational> don't need to return any
data for it.

(iii) But, if you have some funky widget on an interface = that
defaults to bei= ng on, then the server should return data for it. If it is
actually enab= led, then it would indicate that it is on and return any
associated valu= es with its operational state, or if it is disabled then it
should expli= citly report that it is off.

(iv) I wo= uld regard that all applied configuration is "in use" by
the system, even if it match= es the default value, and hence it should be
reported.


This behavior for <operational> is obviously s= lightly different
fr= om the existing with-default handling that is supported for configurationdatastores.=C2=A0 As I recall, there were a couple of reasons that we dec= ided to
have a different behavior for <operational>:
(a) to have consistent semantics for all servers, rather= than
different serv= ers supporting different with-defaults behaviors (which makes
life harde= r for clients because they must cope with all variants).
(b) to remove any potential ambiguity if data isn't retur= ned.=C2=A0 I.e.
with= the existing with-defaults semantics it is not clear to me that
servers= will always return an explicit value to indicate that a particular
widg= et is off if the schema defines that the default it that is enabled.
If = the server doesn't support a given widget at all, it is quite plausible=
that it will just return no data for it.=C2=A0 In theory features/devia= tions
should handle this, but those don't work so well if different = linecards
have different capabilities.=C2=A0 Hence being explicit about = stuff that is in
use seems more robust.
=
<eric> These are good examples.=C2=A0 It would be great if sectio= n 5.3
could be tweak= ed to make clearer the relationship between running datastore
defaults a= nd other operational datastore defaults for the same tree.

For example, let=E2=80=99s say I create a configured su= bscription, and the
= default transport protocol is NETCONF.=C2=A0 NETCONF will be used for that<= br>subscription even though the node might not be populated.=C2=A0 In this = case,
the object would not appear in the running datastore, but MUST* ap= pear in
the operational datastore with the default origin (as it is in-u= se).

This to me is the desired behavior= as it doesn=E2=80=99t incorrectly add
information to the running datastore, but shows what is = in-use within
operational. =C2=A0=C2=A0I suspect other such relationship= s for other operational
tree defaults could be asserted, perhaps based o= n the origin.

(* Maybe =E2=80=98MUST ev= entually=E2=80=99, as obviously there is a temporal
relationship between the two datastores.)

Eric

Thanks,
Rob





/js

Andy

--
Juergen Schoenwaelder =C2=A0=C2= =A0=C2=A0=C2=A0=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=A0=C2=A0=C2= =A0=C2=A0Campus Ring 1 | 28759 Br= emen |
Germany
<https://maps.google.com/?q=3DCa= mpus+Ring+1+%7C+28759+Bremen+%7C+Germany&entry=3Dgmail&so= urce=3Dg>
Fax: =C2=A0=C2=A0+49 421 2= 00 3103 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<https://www.jacobs-un= iversity.de/>





______________________________<= wbr>_________________

netmod mailing list

netmod@ietf.org <mailto:netmod@ietf.org><= mailto:netmod@ietf.org=
<mailto:netmod@ietf.org>>= ;

https://www.ietf.org/mailman/l= istinfo/netmod <
https://www.ietf.org/mailman/listinfo/netmod>


_________= ______________________________________
netmod mailing list
netmod@ietf.org <mai= lto:netmod@ietf.org>
https://www.ietf.org/mailman/listinfo/netmod <
https://www.ietf.org/mailma= n/listinfo/netmod>


--
Juergen Schoenwaelder = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0Jacobs Universi= ty Bremen gGmbH
Phone: +49 421 200 3587 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0Campus Ring 1 |= 28759 Bremen |
Germany
&l= t;https://maps.= google.com/?q=3DCampus+Ring+1+%7C+28759+Bremen+%7C+Germany&en= try=3Dgmail&source=3Dg>
Fax: =C2=A0=C2=A0+49 421 200 = 3103 =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<https://www.jacobs-unive= rsity.de/ <
https://www.jacobs-univer= sity.de/>>

__________________________________= _____________
netmod mailing list
netmod@ietf.org <mailto:netmod@ietf.org>
https://www.ietf.org/= mailman/listinfo/netmod <
https://www.ietf.org/mailman/listinfo/netmod>
Mahesh Jethanandani
mjethanandani@gmail.c= om


______________________________<= wbr>_________________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/m= ailman/listinfo/netconf




__________= _____________________________________
Netconf mailing listNetconf@ietf.orghttps= ://www.ietf.org/mailman/listinfo/netconf



<= /blockquote>

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

Mahesh Jethanandani


--001a114cbd74c5ff880564a679ac-- From nobody Wed Feb 7 15:03:59 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BF65F127522 for ; Wed, 7 Feb 2018 15:03:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FUligSr7jORO for ; Wed, 7 Feb 2018 15:03:53 -0800 (PST) Received: from mail-lf0-x22c.google.com (mail-lf0-x22c.google.com [IPv6:2a00:1450:4010:c07::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6623F126DED for ; Wed, 7 Feb 2018 15:03:52 -0800 (PST) Received: by mail-lf0-x22c.google.com with SMTP id u20so1533718lff.11 for ; Wed, 07 Feb 2018 15:03:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=6HzpFj3e8UGnLMuC6acxwDENhH6z+Ua38ZX2ldsC7jo=; b=PlGLGAXhEia6UkCZF1ZnzARJomai/+c/TXNstANJyZjlhFtqnS8Vkvp5VOwSKG9qp7 yYMS/kL1IxNp76dz2oEe4GvT28tw8Lse4UCjWghFWaySEBpwn9vdne7HLABWw3owriJA f6A4LF1RtS7YtSm0M13ka518FL52rpkOTqL5aHzPIiDv2sm/IgEv8vuXkXGdunrkTZfQ Vlvy9BbaDrgXfg0hpChlb7vpYVV2zknVYwZ1rDicnqMyO0HBDl3AiNB1oxYXEjjOJpGq v4v04zsYABsl2RIrkT7qcmMzcJTqNMlurg2I172HkNYzeWzKLm57eDEWjg0apj62lY3C xGWw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=6HzpFj3e8UGnLMuC6acxwDENhH6z+Ua38ZX2ldsC7jo=; b=C9xag2XsPyx1f7EL9Sem3L/HUdYl6RH1d8qlEpS2ajREfiiFj8SJEQJDiMetH+LFIn kOIhUDXYn1rFBykgd5kevobycO8hWCFX/hh1P7iDvt1sntTjCQ+jpPSuOAVqEEOIwSUh E0ma2/TkS2Oq37ItLPnKQ7FInGcZSMCWAtKomxDwVPqTfJ9R8eWfHRCFzx6bUu0q+2b4 sCcWQSRFFsB8HGWRKQZTSJdogsf9MfbPD15fWeqX79yJijnFoM+4EL5pDRyHTO7cGxAn Fs6atIQLgr1v4DWPllq3qssb6OI5dHQhCXJ+JXhe+rm0M6e8yP0z1IB8SuFS3UuVhAhM AA2w== X-Gm-Message-State: APf1xPAZV+/GDYCWLO8RUUhVcPaGoRiSZDaayuLdrHPPartJvyAYHS9q bJt+uTbXM24Y9g+pRvlXRhXdM+a2FfmZoC5MfhcDmg== X-Google-Smtp-Source: AH8x225Z2jexPPOFcYli4DN89lmacIFtj97LSPhnuPXSVt/Df/eNBfcs6hcFIlyb9eBLwb809Lc4JY8OvowrnQUwz8w= X-Received: by 10.46.47.13 with SMTP id v13mr5057943ljv.15.1518044630480; Wed, 07 Feb 2018 15:03:50 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.143.6 with HTTP; Wed, 7 Feb 2018 15:03:49 -0800 (PST) In-Reply-To: <20180207.192803.834988416883038576.mbj@tail-f.com> References: <20180207.192803.834988416883038576.mbj@tail-f.com> From: Andy Bierman Date: Wed, 7 Feb 2018 15:03:49 -0800 Message-ID: To: Martin Bjorklund Cc: Robert Wilton , Netconf , NetMod WG Content-Type: multipart/alternative; boundary="089e082f330cf417c00564a74e56" Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 Feb 2018 23:03:57 -0000 --089e082f330cf417c00564a74e56 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Feb 7, 2018 at 10:28 AM, Martin Bjorklund wrote: > Andy Bierman wrote: > > On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton wrote= : > > > > > > > > > > > On 07/02/2018 14:23, Andy Bierman wrote: > > > > > > > > > > > > On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton > wrote: > > > > > >> Hi Andy, > > >> > > >> On 07/02/2018 02:33, Andy Bierman wrote: > > >> > > >> > > >> > > >> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani < > > >> mjethanandani@gmail.com> wrote: > > >> > > >>> For folks that provided comments as part of LC, please verify that > your > > >>> comments have been adequately addressed by -03 version of the draft= . > > >>> > > >>> > > >> > > >> Most comments have been addressed. > > >> > > >> > > >> The "with-defaults" parameter does not apply when interacting > with an > > >> > > >> operational datastore. > > >> > > >> > > >> There is no explanation of why the with-defaults parameter does not > apply > > >> to . > > >> This is confusing. The solution that has been a standard for years > still > > >> applies to > > >> all datastores, except a completely different mechanism > (origin-filter) > > >> is used instead > > >> for 1 datastore. > > >> > > >> If the server code can identify a default so it can be tagged > > >> origin=3Dor:default, then it can > > >> also support with-defaults. > > >> > > >> I prefer the sentence above be changed, so that a server MAY impleme= nt > > >> with-defaults > > >> for . If the client sends it should be > OK > > >> to honor it instead > > >> of returning an error. > > >> > > >> I have two concerns with changing this to a MAY: > > >> > > >> (1) The most useful "with-defaults" behavior differs for > vs > > >> the configuration datastores, but with-defaults only allows a single > > >> standard behavior to be specified. > > >> > > >> E.g. for configuration datastores the most appropriate semantics (if > the > > >> client doesn't explicitly ask for something else) is "explicit". i.e= . > you > > >> give back exactly what was put in. > > >> > > >> But, for operational, the most appropriate semantics (if the client > > >> doesn't explicitly ask for something else) is something like > "report-all", > > >> i.e. the device reports the precise current state including any > defaults. > > >> However, we felt that this would return too much unnecessary data, > hence > > >> why the datastore architecture defines "in-use" data, allowing the > server > > >> to prune out any data that is clearly irrelevant. > > >> > > >> (2) is a new datastore. I personally don't want each > > >> server choosing how the data is returned, which requires that client= s > must > > >> handle all variants. It would be better for the draft to specify th= e > > >> standard semantics to use unless a client has explicitly requested > > >> something else. > > >> > > >> I'm not opposed to a "with-defaults-bis", or a new draft covering > > >> "with-defaults" for ", but I think that: > > >> (i) We shouldn't delay the NMDA protocol drafts for this, this can b= e > > >> done as separate draft adding extra optional functionality. > > >> (ii) The semantics for retrieving data from operational (or > > >> notifications) should be as defined by "in-use" in the NMDA > architecture, > > >> unless a client has explicitly specified, or configured, a different > > >> behavior. > > >> (iii) Probably the only existing option defined in "with-defaults" > that > > >> makes sense for is a variant of "trim" that is > specified to > > >> return what is defined as returning the "in-use" values, but also > excluding > > >> any values that match a default value specified in the schema. > > >> > > >> > > > > > > I think your approach violates the Postel Principle. > > > "Be liberal in what you accept" is about robustness. > > > Rejecting parameters for no good reason is about fragility. > > > > > > I never said change the behavior for if no > > > > is present. > > > If the parameter is provided it is trivial for the server to honor it= . > > > The most useful value (report-all) is the default, not leave out all > > > defaults, like . > > > > > > OK, so one option is to allow the "with-defaults" parameter for the > > > datastore, but specify in both the NETCONF NMDA and > RESTCONF > > > NMDA drafts how "with-defaults" semantics apply to any operational > > > datastore: > > > > > > 1) Regardless of what is reported in the "basic-mode" capability > > > parameter, the default behavior for is "report-all", wi= th > > > semantics as described below: > > > 2) "report-all" for operational datastores is defined as returning al= l > "in > > > use" values (i.e. as specified in section 5.3 of the NMDA > architecture, so > > > default values that are not "in use" are not returned). > > > 3) "trim" for operational datastores is defined as returning all > "in-use" > > > values (... as 5.3) except that values that match the value specified > in > > > the schema "default" statement are omitted. Note, clients cannot > > > distinguish between a value that is omitted because it is not in use, > vs a > > > value that is omitted because it matches the schema default. > > > 4) "explicit" for operational datastores is defined as returning the > same > > > as "report-all", defined above. > > > 5) "report-all-tagged" for operational datastores is defined as > returning > > > the same as "report-all", except that all values that match the value= s > > > specified in the schema "default" statement are tagged, as described = in > > > with-defaults (RFC 5243). > > > > > > Also note - there is no change in semantics or behavior to how > > > "with-defaults" works for conventional datastores. > > > > > > Thoughts? > > > > > > > > This looks good. > > > > Showing the work... > > > > 1) there is no YANG default for parameter. > > The behavior if this parameter is missing is determined by the > operation > > Right. So in this case (get-data of operational), it would return all > default values in use. > OK > > > 2) The operation returns all values in use. > > The only way to suppress defaults is to use > > (e.g., request all origins except 'default') > > Or use with-defaults =3D trim. > Yes -- because the definition in RFC 6243 is worded to exclude nodes. It should be clear in some draft how basic-mode applies to origin=3Ddefault within . Applying sec 2 of 6243... config=3Dtrue: If basic-mode=3Dreport-all then origin=3Ddefault will never be present If basic-mode=3Dtrim then origin=3Ddefault is only possible if the value-in= -use is the YANG default If basic-mode=3Dexplicit then origin=3Ddefault is only possible if the configured value was not explicitly set by a client. Sec 2.3.1 is not clear if the YANG default value is relevant or not. It could be that if the configured value not explicitly set, then any value-in-use (not just the YANG default) could be tagged origin=3Ddefault. config=3Dfalse: report-all: default ignored, no nodes treated as default trim: node removed if value=3DYANG default explicit: all config=3Dfalse nodes are set by the server, so no nodes treat= ed as default This draft makes with-defaults mandatory-to-implement. It is a SHOULD implement now. (I approve!). The with-defaults capability MUST be advertised by the NMDA server, including the basic-mode parameter. The also-supported parameter MAY be included. Is it possible for report-all-tagged to apply to nodes that are learned (i.e., not origin=3Ddefault)? > > 3) The parameter for is mostly a NO-OP. > > It does not add or remove any nodes that would be returned. > > The "report-all-tagged" value does add the "default> attribute, whi= ch > > is useful > > for clients that process these attributes already > > > > 4) The values that are tagged default are the same ones that the server > tags > > as origin=3Ddefault. > > > > 5) It still seems to up to the server "basic-mode" as to what is > considered > > "set by default". This messy aspect of NETCONF is minimized in > > because > > the server usually returns all values in use. > > > > /martin > > > Andy > > > > > > > Thanks, > > > Rob > > > > > > > > > > Andy > > > > > > > > > > > > > > > > > > >> Thanks, > > >> Rob > > >> > > >> > > >> > > > Andy > > > > > > > > >> > > >> > > >> Andy > > >> > > >> > > >> > > >> > > >>> Thanks > > >>> > > >>> Mahesh Jethanandani > > >>> mjethanandani@gmail.com > > >>> > > >>> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund > wrote: > > >>> > > > >>> > Hi, > > >>> > > > >>> > Mahesh Jethanandani wrote: > > >>> >> This closes the LC for the two NDMA drafts for NETCONF and > RESTCONF. > > >>> >> > > >>> >> As part of the LC, there were a couple of comments/questions > > >>> >> raised. In particular > > >>> >> > > >>> >> - Vladmir reported an error, which Martin said is fixed in his > local > > >>> copy. > > >>> > > > >>> > Fixed. > > >>> > > > >>> >> - Robert suggested that =E2=80=9C/yang-library/checksum=E2=80=9D= should be a > > >>> >> reference. Juergen supported that comment, so I am assuming tha= t > > >>> >> that will be incorporated into the draft. > > >>> > > > >>> > Yes, fixed. > > >>> > > > >>> >> - Andy had questions around datastore set to =E2=80=9Cconvention= al=E2=80=9D > > >>> > > > >>> > Fixed. > > >>> > > > >>> >> , about origin filter limited to 1 source > > >>> > > > >>> > Fixed. > > >>> > > > >>> >> and the behavior of with-defaults. > > >>> > > > >>> > There were no additional changes to the document from the > discussion > > >>> > about this. > > >>> > > > >>> >> I see some discussion around it with the authors > > >>> >> agreeing that some of them need some text clarifying the > > >>> >> position. Can the authors please post the suggested > text/additions > > >>> >> for the WG to review. > > >>> >> - Anything else?? > > >>> >> > > >>> >> Once an updated draft has been posted, I will do a writeup on th= e > > >>> >> drafts and send it to IESG. > > >>> > > > >>> > The issues above are now addressed, in > > >>> > draft-ietf-netconf-nmda-netconf-03. > > >>> > > > >>> > There were no additional comments on > > >>> > draft-ietf-netconf-nmda-restconf-02, so I believe this version is > > >>> > ready. > > >>> > > > >>> > > > >>> > /martin > > >>> > > > >>> > > > >>> >> > > >>> >> Thanks. > > >>> >> > > >>> >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoenwaelder < > > >>> j.schoenwaelder@jacobs-university.de> wrote: > > >>> >>> > > >>> >>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Eric Voit (evoit) > wrote: > > >>> >>>> > > >>> >>>> I do have one additional thought below on > > >>> draft-ietf-netmod-revised-datastores section 5.3 default handling > > >>> process. See in-line... > > >>> >>>> > > >>> >>> > > >>> >>> Well, this document is with the RFC editor now. I do not think = it > > >>> needs > > >>> >>> clarification. It already has text in 5.3 such as: > > >>> >>> > > >>> >>> Requests to retrieve nodes from always return th= e > > >>> value > > >>> >>> in use if the node exists, regardless of any default value > specified > > >>> >>> in the YANG module. If no value is returned for a given node, > then > > >>> >>> this implies that the node is not used by the device. > > >>> >>> > > >>> >>> /js > > >>> >>> > > >>> >>>> From: Robert Wilton -X, January 31, 2018 6:31 AM > > >>> >>>> > > >>> >>>> > > >>> >>>> Hi Andy, > > >>> >>>> > > >>> >>>> On 31/01/2018 09:22, Andy Bierman wrote: > > >>> >>>> > > >>> >>>> > > >>> >>>> On Wed, Jan 31, 2018 at 12:11 AM, Juergen Schoenwaelder < > > >>> j.schoenwaelder@jacobs-university.de > >>> -university.de> > >>> j.schoenwaelder@jacobs-university.de>>> wrote: > > >>> >>>>> On Tue, Jan 30, 2018 at 12:35:33PM -0800, Andy Bierman wrote: > > >>> >>>>> Hi, > > >>> >>>>> > > >>> >>>>> I have some questions about these drafts. > > >>> >>>>> > > >>> >>>>> 1) what if datastore set to "conventional"? > > >>> >>>>> There are many places where a datastore-ref type is used. > > >>> >>>>> However, "conventional" is valid for base "datastore", even > > >>> though > > >>> >>>>> it is ambiguous as a datastore selector. > > >>> >>>> > > >>> >>>> We can add explicit text that an identity that does not resolv= e > to a > > >>> >>>> datastore implemented by the server results in an invalid valu= e > > >>> error. > > >>> >>>> > > >>> >>>> > > >>> >>>> OK > > >>> >>>> > > >>> >>>> > > >>> >>>>> 2) origin filter is limited to 1 source > > >>> >>>>> This filtering seems rather limited. A client must retrieve > > >>> >>>>> and check > > >>> >>>>> all the values in use, then make repeated requests for each > > >>> source as a > > >>> >>>>> different > > >>> >>>>> leaf > > >>> >>>> > > >>> >>>> If the client does , then it has all origin > information > > >>> >>>> and it can filter locally. That said, we could make > origin-filter a > > >>> >>>> leaf-list which is logically ORed so that one can retrieve > > >>> >>>> origin-filter=3Dor:system or origin-filter=3Dor:learned in one > request. > > >>> >>>> > > >>> >>>> > > >>> >>>> OK > > >>> >>>> > > >>> >>>>> 3) with-defaults broken > > >>> >>>>> The operational datastore does not support with-defaults. > > >>> >>>>> Instead, the client must use origin-filter=3Dor:default or > > >>> with-origin > > >>> >>>>> and check all the origin attributes. Since a client needs > to > > >>> use > > >>> >>>>> with-defaults for other datastores, this special handling = of > > >>> >>>>> > > >>> >>>>> seems unhelpful. > > >>> >>>> > > >>> >>>> I think the with-defaults semantics for conventional > configuration > > >>> >>>> datastores are much more complicated than necessary for the > > >>> >>>> operational state datastore. Note that that the operational > state > > >>> >>>> datastore reports in-use values not really defaults: > > >>> >>>> > > >>> >>>> foo > > >>> >>>> > > >>> >>>> This reports that the value 'foo' is in use and that it > originates > > >>> >>>> from a default value. Note that this could also be > > >>> >>>> > > >>> >>>> foo > > >>> >>>> > > >>> >>>> in case the intended configuration datastore configured the > value > > >>> >>>> 'foo' (despite this value matching the default). The > with-defaults > > >>> >>>> solution is pretty complex because it tries to handle how > different > > >>> >>>> systems deal with configuration defaults. The idea is to not > carry > > >>> >>>> this complexity over to in-use values in the operational state > > >>> >>>> datastore. > > >>> >>>> > > >>> >>>> > > >>> >>>> Before NMDA, the client could decide if it wanted to retrieve > > >>> default nodes or not. > > >>> >>>> This client-choice has been removed from NMDA, which is a > problem. > > >>> >>>> We tried to reach a sensible compromise on the data returned > from > > >>> operational (defined in section 5.3 of the NMDA architecture): > > >>> >>>> - it should return explicit values for everything that is > affecting > > >>> the actual running state of the device (regardless of whether the > > >>> operational value matches a schema default value). > > >>> >>>> - it does not need to, and should not, return operational valu= es > > >>> for stuff that isn't actually in use, i.e. don't return needless an= d > > >>> unwanted data. > > >>> >>>> > > >>> >>>> In particular, if no value is returned from a particular data > node > > >>> in then, barring mgmt protocol errors, a client can > assume > > >>> that any functionality associated with that data node is off (i.e. > not in > > >>> use). > > >>> >>>> > > >>> >>>> Some examples to illustrate the behavior: > > >>> >>>> > > >>> >>>> (i) If a protocol, e.g. OSPF, is not enabled/running then > > >>> does not need to return any data for it. It would be > > >>> reasonable to return a flag to indicate that OSPF is not > enabled/running. > > >>> >>>> > > >>> >>>> (ii) If you have some funky widget on an interface that > defaults to > > >>> being off and isn't being used then don't need to > return any > > >>> data for it. > > >>> >>>> > > >>> >>>> (iii) But, if you have some funky widget on an interface that > > >>> defaults to being on, then the server should return data for it. If > it is > > >>> actually enabled, then it would indicate that it is on and return a= ny > > >>> associated values with its operational state, or if it is disabled > then it > > >>> should explicitly report that it is off. > > >>> >>>> > > >>> >>>> (iv) I would regard that all applied configuration is "in use" > by > > >>> the system, even if it matches the default value, and hence it > should be > > >>> reported. > > >>> >>>> > > >>> >>>> > > >>> >>>> This behavior for is obviously slightly differen= t > > >>> from the existing with-default handling that is supported for > configuration > > >>> datastores. As I recall, there were a couple of reasons that we > decided to > > >>> have a different behavior for : > > >>> >>>> (a) to have consistent semantics for all servers, rather than > > >>> different servers supporting different with-defaults behaviors > (which makes > > >>> life harder for clients because they must cope with all variants). > > >>> >>>> (b) to remove any potential ambiguity if data isn't returned. > I.e. > > >>> with the existing with-defaults semantics it is not clear to me tha= t > > >>> servers will always return an explicit value to indicate that a > particular > > >>> widget is off if the schema defines that the default it that is > enabled. > > >>> If the server doesn't support a given widget at all, it is quite > plausible > > >>> that it will just return no data for it. In theory > features/deviations > > >>> should handle this, but those don't work so well if different > linecards > > >>> have different capabilities. Hence being explicit about stuff that > is in > > >>> use seems more robust. > > >>> >>>> > > >>> >>>> These are good examples. It would be great if section > 5.3 > > >>> could be tweaked to make clearer the relationship between running > datastore > > >>> defaults and other operational datastore defaults for the same tree= . > > >>> >>>> > > >>> >>>> For example, let=E2=80=99s say I create a configured subscript= ion, and > the > > >>> default transport protocol is NETCONF. NETCONF will be used for th= at > > >>> subscription even though the node might not be populated. In this > case, > > >>> the object would not appear in the running datastore, but MUST* > appear in > > >>> the operational datastore with the default origin (as it is in-use)= . > > >>> >>>> > > >>> >>>> This to me is the desired behavior as it doesn=E2=80=99t incor= rectly add > > >>> information to the running datastore, but shows what is in-use with= in > > >>> operational. I suspect other such relationships for other > operational > > >>> tree defaults could be asserted, perhaps based on the origin. > > >>> >>>> > > >>> >>>> (* Maybe =E2=80=98MUST eventually=E2=80=99, as obviously there= is a temporal > > >>> relationship between the two datastores.) > > >>> >>>> > > >>> >>>> Eric > > >>> >>>> > > >>> >>>> Thanks, > > >>> >>>> Rob > > >>> >>>> > > >>> >>>> > > >>> >>>> > > >>> >>>> > > >>> >>>> > > >>> >>>> > > >>> >>>> /js > > >>> >>>> > > >>> >>>> Andy > > >>> >>>> > > >>> >>>> -- > > >>> >>>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >>> >>>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > >>> Germany > > >>> Bremen+%7C+Germany&entry=3Dgmail&source=3Dg> > > >>> >>>> Fax: +49 421 200 3103 university.de/> > > >>> >>>> > > >>> >>>> > > >>> >>>> > > >>> >>>> > > >>> >>>> > > >>> >>>> _______________________________________________ > > >>> >>>> > > >>> >>>> netmod mailing list > > >>> >>>> > > >>> >>>> netmod@ietf.org > >>> > > > >>> >>>> > > >>> >>>> https://www.ietf.org/mailman/listinfo/netmod < > > >>> https://www.ietf.org/mailman/listinfo/netmod> > > >>> >>>> > > >>> >>> > > >>> >>>> _______________________________________________ > > >>> >>>> netmod mailing list > > >>> >>>> netmod@ietf.org > > >>> >>>> https://www.ietf.org/mailman/listinfo/netmod < > > >>> https://www.ietf.org/mailman/listinfo/netmod> > > >>> >>> > > >>> >>> > > >>> >>> -- > > >>> >>> Juergen Schoenwaelder Jacobs University Bremen gGmbH > > >>> >>> Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | > > >>> Germany > > >>> Bremen+%7C+Germany&entry=3Dgmail&source=3Dg> > > >>> >>> Fax: +49 421 200 3103 university.de/ < > > >>> https://www.jacobs-university.de/>> > > >>> >>> > > >>> >>> _______________________________________________ > > >>> >>> netmod mailing list > > >>> >>> netmod@ietf.org > > >>> >>> https://www.ietf.org/mailman/listinfo/netmod < > > >>> https://www.ietf.org/mailman/listinfo/netmod> > > >>> >> Mahesh Jethanandani > > >>> >> mjethanandani@gmail.com > > >>> >> > > >>> > > >>> _______________________________________________ > > >>> Netconf mailing list > > >>> Netconf@ietf.org > > >>> https://www.ietf.org/mailman/listinfo/netconf > > >>> > > >> > > >> > > >> > > >> _______________________________________________ > > >> Netconf mailing listNetconf@ietf.orghttps://ww > w.ietf.org/mailman/listinfo/netconf > > >> > > >> > > >> > > > > > > > --089e082f330cf417c00564a74e56 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 7, 2018 at 10:28 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Andy Bierman <andy@yumaworks.com> wrote:
> On Wed, Feb 7, 2018 at 8:11 AM, Robert Wilton <rwilton@cisco.com> wrote:
>
> >
> >
> > On 07/02/2018 14:23, Andy Bierman wrote:
> >
> >
> >
> > On Wed, Feb 7, 2018 at 3:14 AM, Robert Wilton <rwilton@cisco.com> wrote:
> >
> >> Hi Andy,
> >>
> >> On 07/02/2018 02:33, Andy Bierman wrote:
> >>
> >>
> >>
> >> On Mon, Feb 5, 2018 at 1:33 PM, Mahesh Jethanandani <
> >> mjethanandani@gmai= l.com> wrote:
> >>
> >>> For folks that provided comments as part of LC, please ve= rify that your
> >>> comments have been adequately addressed by -03 version of= the draft.
> >>>
> >>>
> >>
> >> Most comments have been addressed.
> >>
> >>
> >>=C2=A0 =C2=A0 =C2=A0The "with-defaults" parameter do= es not apply when interacting with an
> >>
> >>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0operational datastore.
> >>
> >>
> >> There is no explanation of why the with-defaults parameter do= es not apply
> >> to <operational>.
> >> This is confusing. The solution that has been a standard for = years still
> >> applies to
> >> all datastores, except a completely different mechanism (orig= in-filter)
> >> is used instead
> >> for 1 datastore.
> >>
> >> If the server code can identify a default so it can be tagged=
> >> origin=3Dor:default, then it can
> >> also support with-defaults.
> >>
> >> I prefer the sentence above be changed, so that a server MAY = implement
> >> with-defaults
> >> for <operational>.=C2=A0 If the client sends <with-d= efaults> it should be OK
> >> to honor it instead
> >> of returning an error.
> >>
> >> I have two concerns with changing this to a MAY:
> >>
> >> (1) The most useful "with-defaults" behavior differ= s for <operational> vs
> >> the configuration datastores, but with-defaults only allows a= single
> >> standard behavior to be specified.
> >>
> >> E.g. for configuration datastores the most appropriate semant= ics (if the
> >> client doesn't explicitly ask for something else) is &quo= t;explicit". i.e. you
> >> give back exactly what was put in.
> >>
> >> But, for operational, the most appropriate semantics (if the = client
> >> doesn't explicitly ask for something else) is something l= ike "report-all",
> >> i.e. the device reports the precise current state including a= ny defaults.
> >> However, we felt that this would return too much unnecessary = data, hence
> >> why the datastore architecture defines "in-use" dat= a, allowing the server
> >> to prune out any data that is clearly irrelevant.
> >>
> >> (2) <operational> is a new datastore.=C2=A0 I personall= y don't want each
> >> server choosing how the data is returned, which requires that= clients must
> >> handle all variants.=C2=A0 It would be better for the draft t= o specify the
> >> standard semantics to use unless a client has explicitly requ= ested
> >> something else.
> >>
> >> I'm not opposed to a "with-defaults-bis", or a = new draft covering
> >> "with-defaults" for <operational>", but = I think that:
> >> (i) We shouldn't delay the NMDA protocol drafts for this,= this can be
> >> done as separate draft adding extra optional functionality. > >> (ii) The semantics for retrieving data from operational (or > >> notifications) should be as defined by "in-use" in = the NMDA architecture,
> >> unless a client has explicitly specified, or configured, a di= fferent
> >> behavior.
> >> (iii) Probably the only existing option defined in "with= -defaults" that
> >> makes sense for <operational> is a variant of "tri= m" that is specified to
> >> return what is defined as returning the "in-use" va= lues, but also excluding
> >> any values that match a default value specified in the schema= .
> >>
> >>
> >
> > I think your approach violates the Postel Principle.
> > "Be liberal in what you accept" is about robustness. > > Rejecting parameters for no good reason is about fragility.
> >
> > I never said change the behavior for <operational> if no &l= t;with-defaults>
> > is present.
> > If the parameter is provided it is trivial for the server to hono= r it.
> > The most useful value (report-all) is the default, not leave out = all
> > defaults, like <get-config>.
> >
> > OK, so one option is to allow the "with-defaults" param= eter for the
> > <operational> datastore, but specify in both the NETCONF NM= DA and RESTCONF
> > NMDA drafts how "with-defaults" semantics apply to any = operational
> > datastore:
> >
> > 1) Regardless of what is reported in the "basic-mode" c= apability
> > parameter, the default behavior for <operational> is "= report-all", with
> > semantics as described below:
> > 2) "report-all" for operational datastores is defined a= s returning all "in
> > use" values (i.e. as specified in section 5.3 of the NMDA ar= chitecture, so
> > default values that are not "in use" are not returned).=
> > 3) "trim" for operational datastores is defined as retu= rning all "in-use"
> > values (... as 5.3) except that values that match the value speci= fied in
> > the schema "default" statement are omitted.=C2=A0 Note,= clients cannot
> > distinguish between a value that is omitted because it is not in = use, vs a
> > value that is omitted because it matches the schema default.
> > 4) "explicit" for operational datastores is defined as = returning the same
> > as "report-all", defined above.
> > 5) "report-all-tagged" for operational datastores is de= fined as returning
> > the same as "report-all", except that all values that m= atch the values
> > specified in the schema "default" statement are tagged,= as described in
> > with-defaults (RFC 5243).
> >
> > Also note - there is no change in semantics or behavior to how > > "with-defaults" works for conventional datastores.
> >
> > Thoughts?
> >
> >
> This looks good.
>
> Showing the work...
>
> 1) there is no YANG default for <with-defaults> parameter.
>=C2=A0 =C2=A0 =C2=A0The behavior if this parameter is missing is determ= ined by the operation

Right.=C2=A0 So in this case (get-data of operational), it would return all=
default values in use.


O= K

=C2=A0

> 2) The <get-data> operation returns all values in use.
>=C2=A0 =C2=A0 =C2=A0The only way to suppress defaults is to use <ori= gin-filter>
>=C2=A0 =C2=A0 =C2=A0(e.g., request all origins except 'default'= )

Or use with-defaults =3D trim.


Yes -- because the definition in RFC 6243 is worded to exclude nodes= .

It should be clear in some draft how basic-mode = applies to origin=3Ddefault within <operational>.

Applying sec 2 of 6243...

config=3Dtrue:

If basic-mode=3Dreport-all then origin=3Ddefault will= never be present

If basic-mode=3Dtrim then origin= =3Ddefault is only possible if the value-in-use
is the YANG defau= lt

If basic-mode=3Dexplicit then origin=3Ddefault = is only possible if the configured value was not
explicitly set b= y a client.=C2=A0 Sec 2.3.1 is not clear if the YANG default value is relev= ant or not.
It could be that if the configured value not explicit= ly set, then any value-in-use (not just the
YANG default) could b= e tagged origin=3Ddefault.


config= =3Dfalse:

report-all: default ignored, no nodes tr= eated as default
trim: node removed if value=3DYANG default
=
explicit: all config=3Dfalse nodes are set by the server, so no nodes = treated as default


This draft makes= with-defaults mandatory-to-implement.
It is a SHOULD implement n= ow. =C2=A0(I approve!).

The with-defaults capabili= ty MUST be advertised by the NMDA server, including
the basic-mod= e parameter. The also-supported parameter MAY be included.

Is it possible for report-all-tagged to apply to nodes that are le= arned (i.e., not origin=3Ddefault)?



> 3) The <with-defaults> parameter for <operational> is most= ly a NO-OP.
>=C2=A0 =C2=A0 =C2=A0It does not add or remove any nodes that would be r= eturned.
>=C2=A0 =C2=A0 =C2=A0The "report-all-tagged" value does add th= e "default> attribute, which
> is useful
>=C2=A0 =C2=A0 =C2=A0for clients that process these attributes already >
> 4) The values that are tagged default are the same ones that the serve= r tags
>=C2=A0 =C2=A0 =C2=A0 as origin=3Ddefault.
>
> 5) It still seems to up to the server "basic-mode" as to wha= t is considered
>=C2=A0 =C2=A0 =C2=A0 "set by default". This messy aspect of N= ETCONF is minimized in
> <get-data> because
>=C2=A0 =C2=A0 =C2=A0 the server usually returns all values in use.



/martin




Andy

=C2=A0

>
>
> Thanks,
> > Rob
> >
> >
>
> Andy
>
>
> >
> >
> >
> >
> >> Thanks,
> >> Rob
> >>
> >>
> >>
> > Andy
> >
> >
> >>
> >>
> >> Andy
> >>
> >>
> >>
> >>
> >>> Thanks
> >>>
> >>> Mahesh Jethanandani
> >>> mjethanandani@= gmail.com
> >>>
> >>> > On Feb 5, 2018, at 9:43 AM, Martin Bjorklund <mbj@tail-f.com> wrote:
> >>> >
> >>> > Hi,
> >>> >
> >>> > Mahesh Jethanandani <mjethanandani@gmail.com> wrote:
> >>> >> This closes the LC for the two NDMA drafts for N= ETCONF and RESTCONF.
> >>> >>
> >>> >> As part of the LC, there were a couple of commen= ts/questions
> >>> >> raised. In particular
> >>> >>
> >>> >> - Vladmir reported an error, which Martin said i= s fixed in his local
> >>> copy.
> >>> >
> >>> > Fixed.
> >>> >
> >>> >> - Robert suggested that =E2=80=9C/yang-library/c= hecksum=E2=80=9D should be a
> >>> >>=C2=A0 reference. Juergen supported that comment,= so I am assuming that
> >>> >>=C2=A0 that will be incorporated into the draft.<= br> > >>> >
> >>> > Yes, fixed.
> >>> >
> >>> >> - Andy had questions around datastore set to =E2= =80=9Cconventional=E2=80=9D
> >>> >
> >>> > Fixed.
> >>> >
> >>> >>=C2=A0 , about origin filter limited to 1 source<= br> > >>> >
> >>> > Fixed.
> >>> >
> >>> >>=C2=A0 and the behavior of with-defaults.
> >>> >
> >>> > There were no additional changes to the document fro= m the discussion
> >>> > about this.
> >>> >
> >>> >>=C2=A0 I see some discussion around it with the a= uthors
> >>> >>=C2=A0 agreeing that some of them need some text = clarifying the
> >>> >>=C2=A0 position. Can the authors please post the = suggested text/additions
> >>> >>=C2=A0 for the WG to review.
> >>> >> - Anything else??
> >>> >>
> >>> >> Once an updated draft has been posted, I will do= a writeup on the
> >>> >> drafts and send it to IESG.
> >>> >
> >>> > The issues above are now addressed, in
> >>> > draft-ietf-netconf-nmda-netconf-03.
> >>> >
> >>> > There were no additional comments on
> >>> > draft-ietf-netconf-nmda-restconf-02, so I belie= ve this version is
> >>> > ready.
> >>> >
> >>> >
> >>> > /martin
> >>> >
> >>> >
> >>> >>
> >>> >> Thanks.
> >>> >>
> >>> >>> On Jan 31, 2018, at 10:16 AM, Juergen Schoen= waelder <
> >>> j= .schoenwaelder@jacobs-university.de> wrote:
> >>> >>>
> >>> >>> On Wed, Jan 31, 2018 at 04:53:48PM +0000, Er= ic Voit (evoit) wrote:
> >>> >>>>
> >>> >>>> I do have one additional thought below o= n
> >>> draft-ietf-netmod-revised-datastores section 5.3 def= ault handling
> >>> process.=C2=A0 See in-line...
> >>> >>>>
> >>> >>>
> >>> >>> Well, this document is with the RFC editor n= ow. I do not think it
> >>> needs
> >>> >>> clarification. It already has text in 5.3 su= ch as:
> >>> >>>
> >>> >>>=C2=A0 Requests to retrieve nodes from <op= erational> always return the
> >>> value
> >>> >>>=C2=A0 in use if the node exists, regardless = of any default value specified
> >>> >>>=C2=A0 in the YANG module.=C2=A0 If no value = is returned for a given node, then
> >>> >>>=C2=A0 this implies that the node is not used= by the device.
> >>> >>>
> >>> >>> /js
> >>> >>>
> >>> >>>> From: Robert Wilton -X, January 31, 2018= 6:31 AM
> >>> >>>>
> >>> >>>>
> >>> >>>> Hi Andy,
> >>> >>>>
> >>> >>>> On 31/01/2018 09:22, Andy Bierman wrote:=
> >>> >>>>
> >>> >>>>
> >>> >>>> On Wed, Jan 31, 2018 at 12:11 AM, Juerge= n Schoenwaelder <
> >>> j= .schoenwaelder@jacobs-university.de <mailto:j.schoenwaelder@jacobs
> >>> -university.de><mailto:j.schoenwaelder@jacobs-university.de <mailto:
> >>> j= .schoenwaelder@jacobs-university.de>>> wrote:
> >>> >>>>> On Tue, Jan 30, 2018 at 12:35:33PM -= 0800, Andy Bierman wrote:
> >>> >>>>> Hi,
> >>> >>>>>
> >>> >>>>> I have some questions about these dr= afts.
> >>> >>>>>
> >>> >>>>> 1) what if datastore set to "co= nventional"?
> >>> >>>>>=C2=A0 =C2=A0There are many places wh= ere a datastore-ref type is used.
> >>> >>>>>=C2=A0 =C2=A0However, "conventio= nal" is valid for base "datastore", even
> >>> though
> >>> >>>>>=C2=A0 =C2=A0it is ambiguous as a dat= astore selector.
> >>> >>>>
> >>> >>>> We can add explicit text that an identit= y that does not resolve to a
> >>> >>>> datastore implemented by the server resu= lts in an invalid value
> >>> error.
> >>> >>>>
> >>> >>>>
> >>> >>>> OK
> >>> >>>>
> >>> >>>>
> >>> >>>>> 2) origin filter is limited to 1 sou= rce
> >>> >>>>>=C2=A0 This filtering seems rather li= mited.=C2=A0 A client must retrieve
> >>> >>>>> <with-origin> and check
> >>> >>>>>=C2=A0 =C2=A0all the values in use, t= hen make repeated requests for each
> >>> source as a
> >>> >>>>> different
> >>> >>>>>=C2=A0 =C2=A0<origin-filter> le= af
> >>> >>>>
> >>> >>>> If the client does <with-origin>, = then it has all origin information
> >>> >>>> and it can filter locally. That said, we= could make origin-filter a
> >>> >>>> leaf-list which is logically ORed so tha= t one can retrieve
> >>> >>>> origin-filter=3Dor:system or origin-filt= er=3Dor:learned in one request.
> >>> >>>>
> >>> >>>>
> >>> >>>> OK
> >>> >>>>
> >>> >>>>> 3) with-defaults broken
> >>> >>>>>=C2=A0 =C2=A0The operational datastor= e does not support with-defaults.
> >>> >>>>>=C2=A0 =C2=A0 Instead, the client mus= t use origin-filter=3Dor:default or
> >>> with-origin
> >>> >>>>>=C2=A0 =C2=A0 and check all the origi= n attributes.=C2=A0 Since a client needs to
> >>> use
> >>> >>>>>=C2=A0 =C2=A0 with-defaults for other= datastores, this special handling of
> >>> >>>>> <operational>
> >>> >>>>>=C2=A0 =C2=A0 seems unhelpful.
> >>> >>>>
> >>> >>>> I think the with-defaults semantics for = conventional configuration
> >>> >>>> datastores are much more complicated tha= n necessary for the
> >>> >>>> operational state datastore. Note that t= hat the operational state
> >>> >>>> datastore reports in-use values not real= ly defaults:
> >>> >>>>
> >>> >>>> <leaf or:origin=3D'default'&g= t;foo</leaf>
> >>> >>>>
> >>> >>>> This reports that the value 'foo'= ; is in use and that it originates
> >>> >>>> from a default value. Note that this cou= ld also be
> >>> >>>>
> >>> >>>> <leaf or:origin=3D'intended'&= gt;foo</leaf>
> >>> >>>>
> >>> >>>> in case the intended configuration datas= tore configured the value
> >>> >>>> 'foo' (despite this value matchi= ng the default). The with-defaults
> >>> >>>> solution is pretty complex because it tr= ies to handle how different
> >>> >>>> systems deal with configuration defaults= . The idea is to not carry
> >>> >>>> this complexity over to in-use values in= the operational state
> >>> >>>> datastore.
> >>> >>>>
> >>> >>>>
> >>> >>>> Before NMDA, the client could decide if = it wanted to retrieve
> >>> default nodes or not.
> >>> >>>> This client-choice has been removed from= NMDA, which is a problem.
> >>> >>>> We tried to reach a sensible compromise = on the data returned from
> >>> operational (defined in section 5.3 of the NMDA architect= ure):
> >>> >>>> - it should return explicit values for e= verything that is affecting
> >>> the actual running state of the device (regardless of whe= ther the
> >>> operational value matches a schema default value).
> >>> >>>> - it does not need to, and should not, r= eturn operational values
> >>> for stuff that isn't actually in use, i.e. don't = return needless and
> >>> unwanted data.
> >>> >>>>
> >>> >>>> In particular, if no value is returned f= rom a particular data node
> >>> in <operational> then, barring mgmt protocol errors= , a client can assume
> >>> that any functionality associated with that data node is = off (i.e. not in
> >>> use).
> >>> >>>>
> >>> >>>> Some examples to illustrate the behavior= :
> >>> >>>>
> >>> >>>> (i) If a protocol, e.g. OSPF,=C2=A0 is n= ot enabled/running then
> >>> <operational> does not need to return any data for = it.=C2=A0 It would be
> >>> reasonable to return a flag to indicate that OSPF is not = enabled/running.
> >>> >>>>
> >>> >>>> (ii) If you have some funky widget on an= interface that defaults to
> >>> being off and isn't being used then <operational&g= t; don't need to return any
> >>> data for it.
> >>> >>>>
> >>> >>>> (iii) But, if you have some funky widget= on an interface that
> >>> defaults to being on, then the server should return data = for it. If it is
> >>> actually enabled, then it would indicate that it is on an= d return any
> >>> associated values with its operational state, or if it is= disabled then it
> >>> should explicitly report that it is off.
> >>> >>>>
> >>> >>>> (iv) I would regard that all applied con= figuration is "in use" by
> >>> the system, even if it matches the default value, and hen= ce it should be
> >>> reported.
> >>> >>>>
> >>> >>>>
> >>> >>>> This behavior for <operational> is= obviously slightly different
> >>> from the existing with-default handling that is supported= for configuration
> >>> datastores.=C2=A0 As I recall, there were a couple of rea= sons that we decided to
> >>> have a different behavior for <operational>:
> >>> >>>> (a) to have consistent semantics for all= servers, rather than
> >>> different servers supporting different with-defaults beha= viors (which makes
> >>> life harder for clients because they must cope with all v= ariants).
> >>> >>>> (b) to remove any potential ambiguity if= data isn't returned.=C2=A0 I.e.
> >>> with the existing with-defaults semantics it is not clear= to me that
> >>> servers will always return an explicit value to indicate = that a particular
> >>> widget is off if the schema defines that the default it t= hat is enabled.
> >>> If the server doesn't support a given widget at all, = it is quite plausible
> >>> that it will just return no data for it.=C2=A0 In theory = features/deviations
> >>> should handle this, but those don't work so well if d= ifferent linecards
> >>> have different capabilities.=C2=A0 Hence being explicit a= bout stuff that is in
> >>> use seems more robust.
> >>> >>>>
> >>> >>>> <eric> These are good examples.=C2= =A0 It would be great if section 5.3
> >>> could be tweaked to make clearer the relationship between= running datastore
> >>> defaults and other operational datastore defaults for the= same tree.
> >>> >>>>
> >>> >>>> For example, let=E2=80=99s say I create = a configured subscription, and the
> >>> default transport protocol is NETCONF.=C2=A0 NETCONF will= be used for that
> >>> subscription even though the node might not be populated.= =C2=A0 In this case,
> >>> the object would not appear in the running datastore, but= MUST* appear in
> >>> the operational datastore with the default origin (as it = is in-use).
> >>> >>>>
> >>> >>>> This to me is the desired behavior as it= doesn=E2=80=99t incorrectly add
> >>> information to the running datastore, but shows what is i= n-use within
> >>> operational.=C2=A0 =C2=A0I suspect other such relationshi= ps for other operational
> >>> tree defaults could be asserted, perhaps based on the ori= gin.
> >>> >>>>
> >>> >>>> (* Maybe =E2=80=98MUST eventually=E2=80= =99, as obviously there is a temporal
> >>> relationship between the two datastores.)
> >>> >>>>
> >>> >>>> Eric
> >>> >>>>
> >>> >>>> Thanks,
> >>> >>>> Rob
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> /js
> >>> >>>>
> >>> >>>> Andy
> >>> >>>>
> >>> >>>> --
> >>> >>>> 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
> >>> <https://maps.google.com/?q=3DCampus+Ring+1+%= 7C+28759+Bremen+%7C+Germany&entry=3Dgmail&source=3Dg&= gt;
> >>> >>>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.d= e/>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>>
> >>> >>>> ___________________________________= ____________
> >>> >>>>
> >>> >>>> netmod mailing list
> >>> >>>>
> >>> >>>> netmo= d@ietf.org <mailto:netmod@ietf.or= g><mailto:netmod@ietf.org=
> >>> <mailto:netmod@ietf= .org>>
> >>> >>>>
> >>> >>>> https://www.ietf.org/= mailman/listinfo/netmod <
> >>> https://www.ietf.org/mailman/list= info/netmod>
> >>> >>>>
> >>> >>>
> >>> >>>> ___________________________________= ____________
> >>> >>>> netmod mailing list
> >>> >>>> netmo= d@ietf.org <mailto:netmod@ietf.or= g>
> >>> >>>> https://www.ietf.org/= mailman/listinfo/netmod <
> >>> https://www.ietf.org/mailman/list= info/netmod>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>> 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
> >>> <https://maps.google.com/?q=3DCampus+Ring+1+%= 7C+28759+Bremen+%7C+Germany&entry=3Dgmail&source=3Dg&= gt;
> >>> >>> Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/<= /a> <
> >>> https://www.jacobs-university.de/>>= ;
> >>> >>>
> >>> >>> _______________________________________= ________
> >>> >>> netmod mailing list
> >>> >>> netmod@ie= tf.org <mailto:netmod@ietf.org>
> >>> >>> https://www.ietf.org/mail= man/listinfo/netmod <
> >>> https://www.ietf.org/mailman/list= info/netmod>
> >>> >> Mahesh Jethanandani
> >>> >> mjeth= anandani@gmail.com
> >>> >>
> >>>
> >>> _______________________________________________
> >>> Netconf mailing list
> >>> Netconf@ietf.org<= br> > >>> https://www.ietf.org/mailman/lis= tinfo/netconf
> >>>
> >>
> >>
> >>
> >> _______________________________________________
> >> Netconf mailing listNetconf@ietf.orghttps://www.ietf.org/mailman/listinfo/netconf
> >>
> >>
> >>
> >
> >

--089e082f330cf417c00564a74e56-- From nobody Wed Feb 7 16:41:30 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B7528126CF9 for ; Wed, 7 Feb 2018 16:41:27 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xhFY2GyF4ToD for ; Wed, 7 Feb 2018 16:41:24 -0800 (PST) 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 52028124207 for ; Wed, 7 Feb 2018 16:41:23 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 9389814E15F7; Thu, 8 Feb 2018 01:41:21 +0100 (CET) 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 DmWh4MnQNnQq; Thu, 8 Feb 2018 01:41:21 +0100 (CET) Received: from localhost (localhost [127.0.0.1]) by mail.transpacket.com (Postfix) with ESMTP id 6CF1E14E15F8; Thu, 8 Feb 2018 01:41:21 +0100 (CET) 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 Bofw2MXD3jWb; Thu, 8 Feb 2018 01:41:21 +0100 (CET) Received: from [192.168.43.32] (77.18.48.72.tmi.telenormobil.no [77.18.48.72]) by mail.transpacket.com (Postfix) with ESMTPSA id 30E3114E15EC; Thu, 8 Feb 2018 01:41:21 +0100 (CET) To: Andy Bierman , phil@juniper.net References: <201802071859.w17IxjwU073675@idle.juniper.net> Cc: netmod@ietf.org From: Vladimir Vassilev Message-ID: <39f4e20a-0147-a419-c0f3-6da2a6ee659a@transpacket.com> Date: Thu, 8 Feb 2018 01:41:20 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nb Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 00:41:28 -0000 On 02/07/2018 11:02 PM, Andy Bierman wrote: > Hi, > > Many good points. > IMO it will be difficult to agree on the details of this draft > without agreeing on the problem statement first. > As a process issue, this seems like an important step. +1 > It is usually handled with WG charter text, but NETMOD > has a free pass on new YANG modules somehow. > > I am interested in these tags as a new type of standard selection filte= r. > It can be applied to data retrieval, NACM rules, YANG push subtree=20 > selection, > and probably many more use-cases.=C2=A0 So the problem statement > might be: > > =C2=A0 =C2=A0There is a need for standardized mechanisms to classify YA= NG data=20 > nodes with tags, > =C2=A0 =C2=A0which can be used in protocol operations to select matchin= g data=20 > nodes, based on tag values. > =C2=A0 =C2=A0This work includes the management and assignment of tags, = and their=20 > generalized use > =C2=A0 =C2=A0within protocol operations. A practical usecase example in addition to this text could really help.=20 I suspect Phil is right that "the authors have more in their heads than they've put into the draft" but even with=20 this text an example is needed to illistrate the purpose of this work. Vladimir > > > Andy > > > On Wed, Feb 7, 2018 at 10:59 AM, Phil Shafer > wrote: > > Andy Bierman writes: > >The draft avoids discussion of any useful operations based on tags= . > > Nor does it really clearly say "what" is being tagged. The absract > talks about "used to help classify and organize modules", but the > Introduction lacks any expansion on this.=C2=A0 There's really no c= lear > problem statement or a clear definition of why we need tags or what > one would use them for. > > It would also be helpful to understand why "#hashtag" and the strin= g > format ("ietf:routing", "vendor:super-duper:...") are chosen over > YANG identities.=C2=A0 It seems like identity naming standards and > inheritance > would be good features. > > Also it's not clear why these would be configurable rather that > controlled by the module author.=C2=A0 I'd rather have the OAM stan= dard > YANG module say something like: > > =C2=A0 =C2=A0 module ietf-oam { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 import "ietf-category" { prefix ietf-ca= tegory; } > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 identify ietf-oam { > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 base ietf-category:ietf-s= tandard; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 description "This module = category represents something > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0= =C2=A0 =C2=A0 =C2=A0OAM related."; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 } > > =C2=A0 =C2=A0 =C2=A0 =C2=A0 ietf-category:module-category ietf-oam; > =C2=A0 =C2=A0 =C2=A0 =C2=A0 ... > =C2=A0 =C2=A0 } > > The draft says: > > =C2=A0 =C2=A0Implementations that do not support the reset rpc stat= ement > (whether > =C2=A0 =C2=A0at all, or just for a particular rpc or module) MUST r= espond > with an > =C2=A0 =C2=A0YANG transport protocol-appropriate rpc layer error wh= en such a > =C2=A0 =C2=A0statement is received. > > The entire idea of NETCONF/YANG is that the client _knows_ what it > can safely send instead of tossing spaghetti at the wall until > something sticks.=C2=A0 Avoid programming-by-error-detection, which > creates fragile infrastructure. > > Use "feature" to control optional portions of a YANG module.=C2=A0 = I'd > suggest one feature for "reset" support and another for "read-only"= , > since IMHO the idea of someone munging the categories of standard > modules is, well, disconcerting. > > "Local" tags are not well explained.=C2=A0 The idea of a user/admin > tagging modules means that something is broken.=C2=A0 Users shouldn= 't > understand YANG modules.=C2=A0 Users use applications, some of whic= h are > home-grown.=C2=A0 Is "local" appropriate for my "audit interfaces" = script? > > 6.1 is missing the list "module-tags". > > 9.1 advocates putting vital information in the description string, > which is IMHO not a good idea.=C2=A0 We want to put as much informa= tion > in machine-readable format as possible, so I can ask ietf.org > > questions like "give me a list of ietf-oam-related yang modules" > and get a nice list. > > It also talks about "SHOULD" and "MAY" tags without giving any > clue as to why or when this would be appropriate or useful. > > So my vote would be that this document needs some significant work > and expansion before it's a supportable draft.=C2=A0 I think the au= thors > have more in their heads than they've put into the draft and I'd > like to see the rest of their thoughts. > > Thanks, > =C2=A0Phil > > > > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Wed Feb 7 17:06:22 2018 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 9990C1270AB; Wed, 7 Feb 2018 17:06:20 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: Spencer Dawkins To: "The IESG" Cc: draft-ietf-netmod-yang-tree-diagrams@ietf.org, Joel Jaeggli , netmod-chairs@ietf.org, joelja@gmail.com, netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151805198062.17216.16879713781545025345.idtracker@ietfa.amsl.com> Date: Wed, 07 Feb 2018 17:06:20 -0800 Archived-At: Subject: [netmod] Spencer Dawkins' Yes on draft-ietf-netmod-yang-tree-diagrams-05: (with COMMENT) X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 01:06:20 -0000 Spencer Dawkins has entered the following ballot position for draft-ietf-netmod-yang-tree-diagrams-05: Yes When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ ---------------------------------------------------------------------- COMMENT: ---------------------------------------------------------------------- This is really accessible for those of us who don't speak YANG fluently, but have working groups that are starting on YANG models. Thanks for doing it. From nobody Wed Feb 7 23:03:08 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA68A12D85E for ; Wed, 7 Feb 2018 23:03:06 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id i1H6qtBPbkY9 for ; Wed, 7 Feb 2018 23:03:04 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0134.outbound.protection.outlook.com [104.47.1.134]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 30AB4127698 for ; Wed, 7 Feb 2018 23:03:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=59e8kwFPc5Pd43feVF/BLtYS+FFffXg5Zx1HHkhmIvI=; b=PJG89+2IeQYnC4pIxX16gZUAte9khWqz9JrXaiJyDx3SXoH+dc0GqKrjLFp8VOb5fqFipAbZKG6CbnZRS7vBJhHsJo4ESscAvhb5xZVwFZwzy3snJP6bvzdCdm2vkWalsJkS35a2H1Z2zYKTTif73c8XJXCn6lz7z++pOFuQZLk= Received: from VI1PR07MB1725.eurprd07.prod.outlook.com (10.166.143.21) by VI1PR07MB1439.eurprd07.prod.outlook.com (10.165.238.21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Thu, 8 Feb 2018 07:03:01 +0000 Received: from VI1PR07MB1725.eurprd07.prod.outlook.com ([fe80::4419:1f5d:8922:53f1]) by VI1PR07MB1725.eurprd07.prod.outlook.com ([fe80::4419:1f5d:8922:53f1%14]) with mapi id 15.20.0485.009; Thu, 8 Feb 2018 07:03:01 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netmod@ietf.org" Thread-Topic: Question on range for parent-rel-pos in ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos Thread-Index: AdOgqtnl8wUy/91/QhiSAjsfnnWWZw== Date: Thu, 8 Feb 2018 07:03:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [92.48.145.188] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1439; 6:tHi3J/4GxEkg9C2Sylpe9pI3Xc4Y3qxayEV+4toBqC7GW0kkM9ACIO/BwRTiRgfte+BrnptmDTRbnz1REt/qZoA7xQzBftwMk3MkqdBGofZNUNLoWrbL1diO9yLXEt9QecqySi7/H0WQn0n9XuEUFs+Samo7hPuG5zGplxyVrsT9z0NKD8Qcb9p9UzVqoHxR+HMoQeB7M0+OSY/GA7i33VGVhRbQUl8YjA6vw22+S7OsT8kxiB+NPLGgE9QJOHmeQ+hqEC6qWfzPlewfTx5XkGRQKkljSXsupsa9w93kdIbtM60JIiolPMUeYrjrDXKIecNT+DV2d3C6WZslvsnGPFWdG/nGqVJYE9T3LH3h+EaEl/IzbgVuw2HaWEZnf9oG; 5:JzEh504q4tMtPF3X76nKpofeYSPRZGeTMNTbAwhE2u57WZwxHueRQRyZnyjTlx3lltsp8C38AlVmQ9oXWhX0bUAZ6t2g1frTU1LHKzf0GXk4nDo8LFTEergVW/M2Dlb/DqgWjgNfV7zC8dIWWIXAZHaIfvRfXMvxu3ReDeVqHVc=; 24:/YSB7YQDWjTB+NZvNUx+wHMIyBJgiUpz/tby+ZAQhXyU714KOzrhNMFHqKsqyks50wKyw65ufYBu6+JHRcO1W07tr+xPgbN0kz70jZ4mdnk=; 7:oPS8qJtx/Kota41WmdmXik79XrXheVXFJJ4XHtxhJIqFRRoVQuXY5l4w6gbehGhE12wvycWH4GiHztlfIJOobAsujCLZDG96r6hj+B2DOad8jBzUcuJTg6YSD6ZtakQW3HL7sZatKOSDxdN+xL4KiEHJqzy/+VSnRhiVBO43QGfVQ69HWl53LXOxEw5dm6wc4bQg4Jj6YF9TCyxWj0grqUKsuIBT/3tktfMFGaBBx6KgDRu2VzCJnaymHeJRMQBM x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: e3f5c18b-1e78-4da8-4e0a-08d56ec1fe22 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:VI1PR07MB1439; x-ms-traffictypediagnostic: VI1PR07MB1439: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231101)(11241501184)(806099)(2400082)(944501161)(3002001)(6055026)(6041288)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:VI1PR07MB1439; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1439; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(979002)(39860400002)(376002)(39380400002)(396003)(346002)(366004)(189003)(199004)(102836004)(5640700003)(5630700001)(2900100001)(6436002)(6116002)(790700001)(14454004)(3846002)(6506007)(5250100002)(55016002)(2501003)(9686003)(54896002)(6306002)(33656002)(53936002)(5660300001)(478600001)(8936002)(186003)(7696005)(105586002)(25786009)(81156014)(26005)(316002)(8676002)(1730700003)(99286004)(81166006)(106356001)(7736002)(3660700001)(66066001)(74316002)(3280700002)(6916009)(97736004)(2351001)(68736007)(86362001)(2906002)(145543001)(145603002)(969003)(989001)(999001)(1009001)(1019001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1439; H:VI1PR07MB1725.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: H2KFZ/sVa+klrx6qbj4E1LBkNGcJSkEt+uK44YJkyeRKzpNxbn+z4/OKSRTwUDJbFTdjjUk5DIisGX1/oLs16ZesdPVJiPW7CBaSiv35QLodiKEQWwMNZvpl6ihOEJ6I spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB172523110F57300A070A102F94F30VI1PR07MB1725eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: e3f5c18b-1e78-4da8-4e0a-08d56ec1fe22 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 07:03:01.2635 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1439 Archived-At: Subject: [netmod] Question on range for parent-rel-pos in ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 07:03:07 -0000 --_000_VI1PR07MB172523110F57300A070A102F94F30VI1PR07MB1725eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, During implementation we came across the following anomaly: According to RFC 6933 entPhysicalParentRelPos the value should be set to -1= in case there is no parent. The hardware YANG model defines this leaf as int32 with range "0 .. 2147483= 647", To be in-line with the referred RFC, shouldn't the range be extended= as "-1 .. 2147483647"? Regards, Bart --_000_VI1PR07MB172523110F57300A070A102F94F30VI1PR07MB1725eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

During implementation we came a= cross the following anomaly:

 

According to RFC 6933 entPhysic= alParentRelPos the value should be set to -1 in case there is no parent.

The hardware YANG model defines= this leaf as int32 with range "0 .. 2147483647”,  To be in= -line with the referred RFC, shouldn’t the range be extended as "= ;-1 .. 2147483647”?

 

Regards, Bart=

--_000_VI1PR07MB172523110F57300A070A102F94F30VI1PR07MB1725eurp_-- From nobody Wed Feb 7 23:21:19 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 99804126DC2 for ; Wed, 7 Feb 2018 23:21:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KjXgf0Zp5lEv for ; Wed, 7 Feb 2018 23:21:16 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 14B451200E5 for ; Wed, 7 Feb 2018 23:21:16 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DB64EE91; Thu, 8 Feb 2018 08:21:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id aCXnKtLFZCNO; Thu, 8 Feb 2018 08:21:14 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 8 Feb 2018 08:21:14 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C11662014E; Thu, 8 Feb 2018 08:21:14 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id B4MDC2rlbhHK; Thu, 8 Feb 2018 08:21:14 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 295BE2014B; Thu, 8 Feb 2018 08:21:14 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id 03FB0423D4F7; Thu, 8 Feb 2018 08:21:13 +0100 (CET) Date: Thu, 8 Feb 2018 08:21:13 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Phil Shafer , NETMOD Working Group Message-ID: <20180208072113.qssx74pydml6422b@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Phil Shafer , NETMOD Working Group References: <201802071859.w17IxjwU073675@idle.juniper.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 07:21:18 -0000 On Wed, Feb 07, 2018 at 02:02:55PM -0800, Andy Bierman wrote: > IMO it will be difficult to agree on the details of this draft > without agreeing on the problem statement first. +1 > I am interested in these tags as a new type of standard selection filter. > It can be applied to data retrieval, NACM rules, YANG push subtree > selection, > and probably many more use-cases. So the problem statement > might be: > > There is a need for standardized mechanisms to classify YANG data nodes > with tags, > which can be used in protocol operations to select matching data nodes, > based on tag values. > This work includes the management and assignment of tags, and their > generalized use > within protocol operations. The I-D talks about tags for YANG _modules_, you are talking about tags for YANG data nodes and you seem to imply that these tags are associated to instance data and that they can be used in protocol operations. (And then I note we already have metadata that can be associated to instance data. And there was Andy's packages work, which can be seen as another way to tag collections of schema nodes.) So yes, there is a need to agree on what the problem is that is to be solved (and to consider how solutions fit into the framework we already have in place). /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Wed Feb 7 23:36:23 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D769F126DC2; Wed, 7 Feb 2018 23:36:21 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sxxhjWIzoJFV; Wed, 7 Feb 2018 23:36:20 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE77D1200E5; Wed, 7 Feb 2018 23:36:19 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 97A2EA24; Thu, 8 Feb 2018 08:36:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id MNYtlcXu7nRY; Thu, 8 Feb 2018 08:36:17 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 8 Feb 2018 08:36:18 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 749622014E; Thu, 8 Feb 2018 08:36:18 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id rAfq9m0-Nsqe; Thu, 8 Feb 2018 08:36:18 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id D16672014B; Thu, 8 Feb 2018 08:36:17 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B5548423D593; Thu, 8 Feb 2018 08:36:17 +0100 (CET) Date: Thu, 8 Feb 2018 08:36:17 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Martin Bjorklund , Netconf , NetMod WG Message-ID: <20180208073617.yico4gvfrl6xdusw@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , NetMod WG References: <20180207.192803.834988416883038576.mbj@tail-f.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 07:36:22 -0000 On Wed, Feb 07, 2018 at 03:03:49PM -0800, Andy Bierman wrote: > > > > > 2) The operation returns all values in use. > > > The only way to suppress defaults is to use > > > (e.g., request all origins except 'default') > > > > Or use with-defaults = trim. > > Yes -- because the definition in RFC 6243 is worded to exclude nodes. > > It should be clear in some draft how basic-mode applies to origin=default > within . Frankly, carrying the different basic modes over to sounds like a mistake. Complexity for no real value. > Applying sec 2 of 6243... > > config=true: > > If basic-mode=report-all then origin=default will never be present > > If basic-mode=trim then origin=default is only possible if the value-in-use > is the YANG default > > If basic-mode=explicit then origin=default is only possible if the > configured value was not > explicitly set by a client. Sec 2.3.1 is not clear if the YANG default > value is relevant or not. > It could be that if the configured value not explicitly set, then any > value-in-use (not just the > YANG default) could be tagged origin=default. > > > config=false: > > report-all: default ignored, no nodes treated as default > trim: node removed if value=YANG default > explicit: all config=false nodes are set by the server, so no nodes treated > as default Who needs all this to manage a network? > This draft makes with-defaults mandatory-to-implement. > It is a SHOULD implement now. (I approve!). > > The with-defaults capability MUST be advertised by the NMDA server, > including > the basic-mode parameter. The also-supported parameter MAY be included. > > Is it possible for report-all-tagged to apply to nodes that are learned > (i.e., not origin=default)? So here is an alternate proposal: The NMDA documents are silent about with-defaults and if someone wants to use with-defaults with datastores then an update of RFC 6243 needs to be written. This way, implementations can choose to not do any of the with-defaults magic. What we may consider, though, is to have a way to negate origin-filter so that we can exclude specific origins - right now to emulate this one has to (a) know all possible origins and then (b) list all origins except the one not wanted. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 8 00:24:05 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 195A212422F for ; Thu, 8 Feb 2018 00:23:57 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jDXjVz6VWCjh for ; Thu, 8 Feb 2018 00:23:55 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8730512D879 for ; Thu, 8 Feb 2018 00:23:55 -0800 (PST) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id B0EB91AE046C; Thu, 8 Feb 2018 09:23:54 +0100 (CET) Date: Thu, 08 Feb 2018 09:23:54 +0100 (CET) Message-Id: <20180208.092354.1733219897860431005.mbj@tail-f.com> To: bart.bogaert@nokia.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Question on range for parent-rel-pos in ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 08:23:57 -0000 "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: > Hi, > > During implementation we came across the following anomaly: > > According to RFC 6933 entPhysicalParentRelPos the value should be > set to -1 in case there is no parent. > The hardware YANG model defines this leaf as int32 with range "0 > .. 2147483647", To be in-line with the referred RFC, shouldn't the > range be extended as "-1 .. 2147483647"? In MIBs, people often use special values to indicate that the underlying thing doesn't exist. In YANG we try to avoid this, and instead not instantiate the node. This should probably have been clarified in the YANG module. /martin From nobody Thu Feb 8 00:28:12 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AA99126D0C for ; Thu, 8 Feb 2018 00:28:11 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6qfya-o6sON for ; Thu, 8 Feb 2018 00:28:08 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on071d.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe02::71d]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89EFB120726 for ; Thu, 8 Feb 2018 00:28:07 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=MsMMpUd88fQ+ZHO6FByWLNVBIDCeImSCkdwJ4mrYb9c=; b=HqA5r8fyyW6ial9A0U19w+QOS9Aq8Oq9RBpvGZ0bWvLIi8LSh4gErfMmSyExIqSKWnOb1cz8QXcXZDWWRhnAa0OEn6eLrVRA8ruZW1KGB5dxdDvhBnv0Csag0RM6uULf+lc6WObB1BtSKmHpYBFRALkAcYCsZygtAY8iMDyTKtg= Received: from VI1PR07MB1725.eurprd07.prod.outlook.com (10.166.143.21) by VI1SPR8PMB116.eurprd07.prod.outlook.com (10.163.248.20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.5; Thu, 8 Feb 2018 08:28:05 +0000 Received: from VI1PR07MB1725.eurprd07.prod.outlook.com ([fe80::4419:1f5d:8922:53f1]) by VI1PR07MB1725.eurprd07.prod.outlook.com ([fe80::4419:1f5d:8922:53f1%14]) with mapi id 15.20.0485.009; Thu, 8 Feb 2018 08:28:05 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: Martin Bjorklund CC: "netmod@ietf.org" Thread-Topic: [netmod] Question on range for parent-rel-pos in ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos Thread-Index: AdOgqtnl8wUy/91/QhiSAjsfnnWWZwAC04gAAAAQeSA= Date: Thu, 8 Feb 2018 08:28:04 +0000 Message-ID: References: <20180208.092354.1733219897860431005.mbj@tail-f.com> In-Reply-To: <20180208.092354.1733219897860431005.mbj@tail-f.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.245.212.218] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1SPR8PMB116; 6:pKGU9In4W061PGsNNd7lRKs641iUJZ+dz6bMfUQMc/hWOw3Bv22EqKeUdBstXH7jQbRQSziePfBOXDSEs3Jr0FlU2VEGpt+mM9EQtiQrVaV0o0zMJzEG3rMqWRcePGvxO5qEvEoj4ukGIOPpYEEhPwUUTKJA6vn3o8LsLGT86AoUBRDy291Ol633OvY0WYUmPbBUcFpUgUyAwOzI01b3f84ny15nAz9sPcbNgvkUGapucvxz5eYFxJxpfX/fZsnlOKzwNq3Exh0vUDUi6iz0HBgPdFwNT40ERA6MOJJY4wsU+gfBmxx+D7zBP+GBk6hrkRAlK5QOJmySA56HtsUhYWCjY7ix3QZf2DYXwfZ4FZsLLnP/+FSZxUA1iYRoF94d; 5:ZkzKEnyaQWvnt4i2q2KhXNNaOzD6HtifOi4gQM09CjbckkC1Js/Xg4y5kOxred2rLfGHylyI8ogxeHAmQTYQy+xhLLLcLQ2PZPI9XJQVifgChZA2UEVXtJ971pFDxaByk6WmHWvM/TZUc6ohdeZS1hVsK5yQOt7soTaCXYmju80=; 24:rAcmyeyyAghVzTnOw1RBFd8tUiewojv+IuRUStZ2NyPIXSVHJGGDywT4z96g9OTpr9azRQ8Iwt10cHP+ORceJ7HPstpD7Z2H0q7DQhlcVPs=; 7:XDrngPuNuBCSMho/TXMOR0lkP65bLYpvj5uVhEByw/ar+MWPZD8HVmojcOWmIqoKCx0KRlMd/GU5t51MRjgacIagGVKgFvT8SPtEzmPeXPiD1IQE9sa6Vw87Rzz3XHWh5aX//DO+NO/dm6TYb/8C2Vl9gQd2ogO9WCLPFCSwliM3KWgeFGoL6iWuuS83reYhwCNZc4JWr2DsXz5WMuUd7HNixK2SNnQM616N4j6+Y+d1heBtDgtUDq/uCxseGQVz x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: df7931fa-0e89-4866-ef00-08d56ecde02e x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7193020); SRVR:VI1SPR8PMB116; x-ms-traffictypediagnostic: VI1SPR8PMB116: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(82608151540597); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231101)(11241501184)(806099)(2400082)(944501161)(6055026)(6041288)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:VI1SPR8PMB116; BCL:0; PCL:0; RULEID:; SRVR:VI1SPR8PMB116; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(396003)(346002)(39380400002)(366004)(39860400002)(199004)(189003)(13464003)(229853002)(74316002)(7736002)(5660300001)(9686003)(97736004)(6116002)(6436002)(55016002)(7696005)(68736007)(66066001)(26005)(2906002)(6346003)(3846002)(102836004)(99286004)(186003)(305945005)(76176011)(53546011)(6506007)(316002)(33656002)(4326008)(81156014)(81166006)(8676002)(6246003)(86362001)(5250100002)(106356001)(25786009)(105586002)(3280700002)(478600001)(53936002)(14454004)(3660700001)(6916009)(2950100002)(2900100001)(8936002)(145543001)(145603002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1SPR8PMB116; H:VI1PR07MB1725.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-microsoft-antispam-message-info: qpGF3Q9uJFrIwE0YNS2Pwz0dZVT2RE5WqWo8AVhUfJHZvWF6do3JHJoFirhRlVbPQ21q43vYiiMAi/kaemP8p7Rete5lMENd/4TVBdgl2s7t5Zg31hE2Y3nrJe2xqmst spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: df7931fa-0e89-4866-ef00-08d56ecde02e X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 08:28:04.9753 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1SPR8PMB116 Archived-At: Subject: Re: [netmod] Question on range for parent-rel-pos in ietf-hatrdware.yang versus RFC 6933 entPhysicalParentRelPos X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 08:28:11 -0000 Thanks Martin, this makes sense. Regards, Bart -----Original Message----- From: Martin Bjorklund [mailto:mbj@tail-f.com]=20 Sent: Thursday, February 8, 2018 9:24 AM To: Bogaert, Bart (Nokia - BE/Antwerp) Cc: netmod@ietf.org Subject: Re: [netmod] Question on range for parent-rel-pos in ietf-hatrdwar= e.yang versus RFC 6933 entPhysicalParentRelPos "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: > Hi, >=20 > During implementation we came across the following anomaly: >=20 > According to RFC 6933 entPhysicalParentRelPos the value should be set=20 > to -1 in case there is no parent. > The hardware YANG model defines this leaf as int32 with range "0 ..=20 > 2147483647", To be in-line with the referred RFC, shouldn't the range=20 > be extended as "-1 .. 2147483647"? In MIBs, people often use special values to indicate that the underlying th= ing doesn't exist. In YANG we try to avoid this, and instead not instantia= te the node. This should probably have been clarified in the YANG module. /martin From nobody Thu Feb 8 00:28:47 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CC393127599 for ; Thu, 8 Feb 2018 00:28:45 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nklmWNa8gEi0 for ; Thu, 8 Feb 2018 00:28:44 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 01A92120726 for ; Thu, 8 Feb 2018 00:28:44 -0800 (PST) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 1E5971AE046C; Thu, 8 Feb 2018 09:28:43 +0100 (CET) Date: Thu, 08 Feb 2018 09:28:42 +0100 (CET) Message-Id: <20180208.092842.2168364015138329939.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: andy@yumaworks.com, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180208072113.qssx74pydml6422b@elstar.local> References: <201802071859.w17IxjwU073675@idle.juniper.net> <20180208072113.qssx74pydml6422b@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 08:28:46 -0000 Hi, In the light of this discussion, I would like to clarify that my support is for the problem of tagging *modules*, which I believe this draft is all about. I don't think we should extend this to tagging *nodes*; I think that requires a different mechanism. /martin Juergen Schoenwaelder wrote: > On Wed, Feb 07, 2018 at 02:02:55PM -0800, Andy Bierman wrote: > > > IMO it will be difficult to agree on the details of this draft > > without agreeing on the problem statement first. > > +1 > > > I am interested in these tags as a new type of standard selection filter. > > It can be applied to data retrieval, NACM rules, YANG push subtree > > selection, > > and probably many more use-cases. So the problem statement > > might be: > > > > There is a need for standardized mechanisms to classify YANG data nodes > > with tags, > > which can be used in protocol operations to select matching data nodes, > > based on tag values. > > This work includes the management and assignment of tags, and their > > generalized use > > within protocol operations. > > The I-D talks about tags for YANG _modules_, you are talking about > tags for YANG data nodes and you seem to imply that these tags are > associated to instance data and that they can be used in protocol > operations. (And then I note we already have metadata that can be > associated to instance data. And there was Andy's packages work, which > can be seen as another way to tag collections of schema nodes.) > > So yes, there is a need to agree on what the problem is that is to be > solved (and to consider how solutions fit into the framework we > already have in place). > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod > From nobody Thu Feb 8 00:40:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52F76120726 for ; Thu, 8 Feb 2018 00:40:55 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GpHjq-64fhZa for ; Thu, 8 Feb 2018 00:40:53 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0093.outbound.protection.outlook.com [104.47.2.93]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B7E561201FA for ; Thu, 8 Feb 2018 00:40:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=KVgCx+nsO/4tLuB8GgB4vMWNRNWIAqIduy26JtgkaCA=; b=kM8Rszwuoys9TzgMsn9TM4Z8ZXeyQzn+/1awF48xc6FKPoZLiA5yZ3mdqqcAG44fhrW9bFi3g12QBGFrjIPXGtz2ZMWi5psYqixdoxJJ8PEgD1wqPVkuwDX0c1C9hXvRuQweuG4FshhNvvddpUpTkntjWBfycT54izSCIZbk8oY= Received: from VI1PR07MB1725.eurprd07.prod.outlook.com (10.166.143.21) by VI1PR07MB1647.eurprd07.prod.outlook.com (10.166.142.153) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Thu, 8 Feb 2018 08:40:50 +0000 Received: from VI1PR07MB1725.eurprd07.prod.outlook.com ([fe80::4419:1f5d:8922:53f1]) by VI1PR07MB1725.eurprd07.prod.outlook.com ([fe80::4419:1f5d:8922:53f1%14]) with mapi id 15.20.0485.009; Thu, 8 Feb 2018 08:40:50 +0000 From: "Bogaert, Bart (Nokia - BE/Antwerp)" To: "netmod@ietf.org" Thread-Topic: Question on schema-mount Thread-Index: AdOguHm9UsRSzQHlTRaVUEIrKf1I5w== Date: Thu, 8 Feb 2018 08:40:50 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=bart.bogaert@nokia.com; x-originating-ip: [135.245.212.218] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; VI1PR07MB1647; 6:vi29gJ8258sYGBx4Xl0PVia0zwhnmo0O2nCPrc/nRPpiI4uyPyq2kLfGLH7D2zKMKw65Qo2QFxjDo6FTViNWsiGxqIcIlrEAK/Fsd5JZ41BzVhriKjZbKZeK3KJRHlkmFIW9eAUwudptqyX2Cr3xjRWpLel9MvWZCUvliT+sCfmN/4eDfgcB9y7fXLRIZnqt3RO1KzCN4IMOBoZOxPx/9Vvc4qg0KHVvOS42yd9LQoVHdJcHf4qytkRIPADOCBDYgtrp7dGAqM5aA55ikBuzF4mA3HIVkIzmqO4LpdFkrXTYbcysuaAX5VhjNXS1mmPcCEwkBetgP4ozUapmcAmDv1poYm8bWvauSb3Mx8eihNrimTIIQG64Sto5bfjDbXw6; 5:bPrumMfKO2REvSUYfRXk/jXK5g4+9H/H9TpvpFq2MG+c4LJCfKvCTt83JrcPoduSRg0M6m2XshSvnX6MOuRU9MKHKtmIPTNNL4WyZDuXjwI0OYUf8PXbYf6UYrMJL0ZzO7yeFZ7r1IpRS1QDa2nSopwrFVHv5mqKoGm18BLIMeA=; 24:wg6UsMf1Agqg3E1MvAtvmLencJAHaxhxvBsB0P0isSOfbpnRpseTXsL96vxhLatFbXzEJOA/Jjae2Sas8fl8vhWIPASzTJQPm/D4qhCL0Zw=; 7:kLIoBEylM1lzQm0P0vz5NAYLI7A9hZo8VkQINWrZaLe+/VRZyyG4JphNm6mXpz9pDw3Usgbe+/e/kK+7TlO/lll4USlIZCUAJziRXVwJ/8xJGoTgC2x5WPK58Mypjnlz3+bg5XZzZNA6hqz98vXk78HCo0/q+p7G2YakWya0ce/UIOMTt9dEzg+3xRcYj3vBVOX3LypgT62U9C0z4r78cUHjNf611I7SI3GcegD3B34MXevT+F0w/GqAwEeeYkt4 x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: 0a453d14-8ec1-4d80-8b98-08d56ecfa845 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7193020); SRVR:VI1PR07MB1647; x-ms-traffictypediagnostic: VI1PR07MB1647: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(28532068793085)(158342451672863)(21748063052155); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231101)(11241501184)(806099)(2400082)(944501161)(93006095)(93001095)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(20161123564045)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:VI1PR07MB1647; BCL:0; PCL:0; RULEID:; SRVR:VI1PR07MB1647; x-forefront-prvs: 0577AD41D6 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39380400002)(346002)(39860400002)(376002)(189003)(199004)(51874003)(8676002)(6916009)(1730700003)(81166006)(81156014)(3660700001)(7736002)(14454004)(3280700002)(5660300001)(6506007)(102836004)(86362001)(105586002)(59450400001)(68736007)(26005)(7696005)(74316002)(8936002)(33656002)(25786009)(97736004)(66066001)(5630700001)(2900100001)(186003)(53936002)(5640700003)(55016002)(9686003)(54896002)(6306002)(106356001)(2351001)(790700001)(6116002)(2906002)(6436002)(316002)(99286004)(3846002)(478600001)(2501003)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR07MB1647; H:VI1PR07MB1725.eurprd07.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-microsoft-antispam-message-info: fU/e9id1keKhFBPsXA785314+1gZ3acwQjQuQbfI9WyOMVL0mzHSIziGwMdWDM7sPPs1bWAZmf9FjLbNDcWCr+fBnWLEZPM81scvdfExoi96VoEm3DOXFpzXjiQMuoLp spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: multipart/alternative; boundary="_000_VI1PR07MB17259C46D65AA5A94EE58FF294F30VI1PR07MB1725eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 0a453d14-8ec1-4d80-8b98-08d56ecfa845 X-MS-Exchange-CrossTenant-originalarrivaltime: 08 Feb 2018 08:40:50.2115 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR07MB1647 Archived-At: Subject: [netmod] Question on schema-mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 08:40:55 -0000 --_000_VI1PR07MB17259C46D65AA5A94EE58FF294F30VI1PR07MB1725eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Hi, We have a question w.r.t. deletion of entry in a list using mounted schema = knowing that in NC/Y there is no such thing as a "cascading delete" (leafre= f constructions in many cases even makes it impossible to delete a resource= if it is still referred). How does this apply to such a schema being mounted. Using the example from= the draft: +--rw interfaces | +--rw interface* [name] | ... +--rw logical-device* [name] +--rw name | ... +--rw interfaces +--rw interface* [name] ... Is it possible in this case to delete /logical-device[name=3D'x'] and the s= erver has to remove all the data associated with the mounted schema? Or do= es the edit-config also explicitly has to delete the data related to the mo= unted schema? I could not find something in the draft that deals with this (or it is ther= e, but then I did not understand that section very well). Thanks in advance, Bart --_000_VI1PR07MB17259C46D65AA5A94EE58FF294F30VI1PR07MB1725eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

 

We have a question w.r.t. delet= ion of entry in a list using mounted schema knowing that in NC/Y there is n= o such thing as a “cascading delete” (leafref constructions in = many cases even makes it impossible to delete a resource if it is still referred).

 

How does this apply to such a s= chema being mounted.  Using the example from the draft:

 

     +--rw interfaces

     |  +--rw interface* [name]=

     |     ...<= /o:p>

     +--rw logical-device* [name]

        +--rw name

        |   ...=

        +--rw interfa= ces

          += --rw interface* [name]

          =    ...

 

Is it possible in this case to = delete /logical-device[name=3D’x’] and the server has to remove= all the data associated with the mounted schema?  Or does the edit-co= nfig also explicitly has to delete the data related to the mounted schema?

 

I could not find something in t= he draft that deals with this (or it is there, but then I did not understan= d that section very well).

 

Thanks in advance,

Bart

 

--_000_VI1PR07MB17259C46D65AA5A94EE58FF294F30VI1PR07MB1725eurp_-- From nobody Thu Feb 8 00:56:23 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F08712421A for ; Thu, 8 Feb 2018 00:56:22 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jFoxxiQArOWD for ; Thu, 8 Feb 2018 00:56:20 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3529E1204DA for ; Thu, 8 Feb 2018 00:56:20 -0800 (PST) Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id CDDB71AE046C; Thu, 8 Feb 2018 09:56:18 +0100 (CET) Date: Thu, 08 Feb 2018 09:56:18 +0100 (CET) Message-Id: <20180208.095618.615736342809160042.mbj@tail-f.com> To: bart.bogaert@nokia.com Cc: netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] Question on schema-mount X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 08:56:22 -0000 Hi, "Bogaert, Bart (Nokia - BE/Antwerp)" wrote: > Hi, > > We have a question w.r.t. deletion of entry in a list using mounted > schema knowing that in NC/Y there is no such thing as a "cascading > delete" (leafref constructions in many cases even makes it impossible > to delete a resource if it is still referred). > > How does this apply to such a schema being mounted. Using the example > from the draft: > > +--rw interfaces > | +--rw interface* [name] > | ... > +--rw logical-device* [name] > +--rw name > | ... > +--rw interfaces > +--rw interface* [name] > ... > > Is it possible in this case to delete /logical-device[name='x'] and > the server has to remove all the data associated with the mounted > schema? Or does the edit-config also explicitly has to delete the > data related to the mounted schema? This is not a generic schema mount question, but a question for the model that provides the mount. Suppose the model that defines logical-device also augments the /interfaces list with an leaf to assign interfaces to logical-devices: augment /if:interfaces/if:interface { leaf assign-to-logical-device { type leafref { path /logical-device/name; } } } Then you wouldn't be able to delete the logical-device if it still has an interface assigned to it. Also, if you actually remove /logical-device[name='x'], schema mount doesn't say anything about what really happens - will the server first delete all config on the logical device and then delete the logical device entry in the parent, or will the server just delete the entry in the parent? These are all questions for the specific model. I don't know if the LNE/NI documents specify this behaviour, but they probably should. > I could not find something in the draft that deals with this (or it is > there, but then I did not understand that section very well). Schema mount doesn't change anything in this regard; it doesn't add any magical implicit delete or anything like that. /martin From nobody Thu Feb 8 01:12:54 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 695E512D7F8 for ; Thu, 8 Feb 2018 01:12:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HB9NO9YvLoYf for ; Thu, 8 Feb 2018 01:12:51 -0800 (PST) Received: from mail-lf0-x22b.google.com (mail-lf0-x22b.google.com [IPv6:2a00:1450:4010:c07::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E102B126B6E for ; Thu, 8 Feb 2018 01:12:50 -0800 (PST) Received: by mail-lf0-x22b.google.com with SMTP id a204so5383061lfa.2 for ; Thu, 08 Feb 2018 01:12:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=jLJ/r81zeS9Bv4bAZf4T1IC0puOHoWZfqAlZVegPttU=; b=2CzU3ZbTBx4zGTUo+T14x6yXAs31lBllBLi53/dVAn/8u2zDGMJ1xXTJBHc2x3pIB0 c6Sqp9BJalqJ2dxpMaep+onktVNbMGijCET4GYHvmZ8fD6OlZZIEjZ3H/T30PCPfuRcX XEIK6BjIEgsnD39zvGF+aaaNv0GgqVyYjstRe9RNu45dmMjgjrKxEwUnEFd4pIdDf1uF H45l6SrOdHQsbn9tYaQ1rDGDrdM85whmK7CV5WsYX8xCRolI3k2zcotXzb/NpyfArzqP AVQESDVv7FGFXe8rC8UcsufZ7g3frpoPIX6q0VFZpskK+nG+0P4oiMODGGjJAwOsviK6 SpPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=jLJ/r81zeS9Bv4bAZf4T1IC0puOHoWZfqAlZVegPttU=; b=Qn8ZyAjrh6iAOY+BvAJvtejjAsZO46/BeHcWXYl0DZSkjf7B2dRjl1mT9BkWVqEuP8 +gXW0x45J8bBt7J2QV23e5FvUW9cJ7fesRNEazhmor1lzcBwQG4LBa4oom8ZVK8VkhT3 Xk2tGq1duySs7qWDHNTeLsANwXOK7MyIIz+V6AxgJ0kk8/6o1rbFQ80OR61F5HQ6UdOU wqEPyWLXbcYf/ybYUW8R7bTxWAnD4DuElURtg69H7kw89Qxc3vthKbGzWZldaOHUJO2C xgmk+/0oEnIvS53TwY2uuAmzIZATAq+sH6csbDsddQt84B+tuFTvsu82ibaQsfHF+ZvG pEhQ== X-Gm-Message-State: APf1xPCJnTrnZ7k3cy38RoqOs4NXccjHfUDIuHP9AzmtysDkcOWXa8I2 kvRmJFiX92Tv/Q99RKCHNlG7ilexSI84NkyglazJLg== X-Google-Smtp-Source: AH8x226GRQ8znWc44w9i8O13Rgt4mk65qcVlJCpuRam8vvYG5q9j3OjsKbcPuRp/qUUXP2kgl3ir3KPZc/HmRhF9uqA= X-Received: by 10.46.47.13 with SMTP id v13mr5925708ljv.15.1518081169043; Thu, 08 Feb 2018 01:12:49 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.143.6 with HTTP; Thu, 8 Feb 2018 01:12:48 -0800 (PST) In-Reply-To: <20180208.092842.2168364015138329939.mbj@tail-f.com> References: <201802071859.w17IxjwU073675@idle.juniper.net> <20180208072113.qssx74pydml6422b@elstar.local> <20180208.092842.2168364015138329939.mbj@tail-f.com> From: Andy Bierman Date: Thu, 8 Feb 2018 01:12:48 -0800 Message-ID: To: Martin Bjorklund Cc: Juergen Schoenwaelder , NetMod WG Content-Type: multipart/alternative; boundary="089e082f330cd264900564afd006" Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 09:12:53 -0000 --089e082f330cd264900564afd006 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 8, 2018 at 12:28 AM, Martin Bjorklund wrote: > Hi, > > In the light of this discussion, I would like to clarify that my > support is for the problem of tagging *modules*, which I believe this > draft is all about. I don't think we should extend this to tagging > *nodes*; I think that requires a different mechanism. > > > If it is about tagging modules, then the draft should really explain why this is useful and provide examples of problems solved with module tags. It can be used to tag all nodes in a module the same way. This might be useful granularity for something. A vendor might also create their own protocol mechanisms to utilize the standard tag values and ignoring the rest of this draft. > /martin > > Andy > > Juergen Schoenwaelder wrote: > > On Wed, Feb 07, 2018 at 02:02:55PM -0800, Andy Bierman wrote: > > > > > IMO it will be difficult to agree on the details of this draft > > > without agreeing on the problem statement first. > > > > +1 > > > > > I am interested in these tags as a new type of standard selection > filter. > > > It can be applied to data retrieval, NACM rules, YANG push subtree > > > selection, > > > and probably many more use-cases. So the problem statement > > > might be: > > > > > > There is a need for standardized mechanisms to classify YANG data > nodes > > > with tags, > > > which can be used in protocol operations to select matching data > nodes, > > > based on tag values. > > > This work includes the management and assignment of tags, and their > > > generalized use > > > within protocol operations. > > > > The I-D talks about tags for YANG _modules_, you are talking about > > tags for YANG data nodes and you seem to imply that these tags are > > associated to instance data and that they can be used in protocol > > operations. (And then I note we already have metadata that can be > > associated to instance data. And there was Andy's packages work, which > > can be seen as another way to tag collections of schema nodes.) > > > > So yes, there is a need to agree on what the problem is that is to be > > solved (and to consider how solutions fit into the framework we > > already have in place). > > > > /js > > > > -- > > Juergen Schoenwaelder Jacobs University Bremen gGmbH > > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > > Fax: +49 421 200 3103 > > > > _______________________________________________ > > netmod mailing list > > netmod@ietf.org > > https://www.ietf.org/mailman/listinfo/netmod > > > --089e082f330cd264900564afd006 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 8, 2018 at 12:28 AM, Martin Bjorklund <= ;mbj@tail-f.com>= wrote:
Hi,

In the light of this discussion, I would like to clarify that my
support is for the problem of tagging *modules*, which I believe this
draft is all about.=C2=A0 I don't think we should extend this to taggin= g
*nodes*; I think that requires a different mechanism.



If it is about tagging modules, then t= he draft should really explain why
this is useful and provide exa= mples of problems
solved with module tags. It can be used to tag = all nodes in a module the same way.
This might be useful granular= ity for something.

A vendor might also create thei= r own protocol
mechanisms to utilize the standard tag values
and ignoring the rest of this draft.


=C2=A0
/martin


Andy
=C2=A0

Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
> On Wed, Feb 07, 2018 at 02:02:55PM -0800, Andy Bierman wrote:
>
> > IMO it will be difficult to agree on the details of this draft > > without agreeing on the problem statement first.
>
> +1
>
> > I am interested in these tags as a new type of standard selection= filter.
> > It can be applied to data retrieval, NACM rules, YANG push subtre= e
> > selection,
> > and probably many more use-cases.=C2=A0 So the problem statement<= br> > > might be:
> >
> >=C2=A0 =C2=A0 There is a need for standardized mechanisms to class= ify YANG data nodes
> > with tags,
> >=C2=A0 =C2=A0 which can be used in protocol operations to select m= atching data nodes,
> > based on tag values.
> >=C2=A0 =C2=A0 This work includes the management and assignment of = tags, and their
> > generalized use
> >=C2=A0 =C2=A0 within protocol operations.
>
> The I-D talks about tags for YANG _modules_, you are talking about
> tags for YANG data nodes and you seem to imply that these tags are
> associated to instance data and that they can be used in protocol
> operations. (And then I note we already have metadata that can be
> associated to instance data. And there was Andy's packages work, w= hich
> can be seen as another way to tag collections of schema nodes.)
>
> So yes, there is a need to agree on what the problem is that is to be<= br> > solved (and to consider how solutions fit into the framework we
> already have in place).
>
> /js
>
> --
> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U= niversity 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<= ;https://www.jacobs-university.de/>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

--089e082f330cd264900564afd006-- From nobody Thu Feb 8 01:17:39 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C629D12D86D for ; Thu, 8 Feb 2018 01:17:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.596 X-Spam-Level: X-Spam-Status: No, score=-3.596 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, 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, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=SrSomlR7; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.com header.b=kfmOa2of Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M8XrtmgNbV5H for ; Thu, 8 Feb 2018 01:17:36 -0800 (PST) Received: from sessmg23.ericsson.net (sessmg23.ericsson.net [193.180.251.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 067371204DA for ; Thu, 8 Feb 2018 01:17:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518081453; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=nsJpbszWxImzEuWUBfpW3HMLYNGGy08M8sUBQHC9jJI=; b=SrSomlR7zLbCwc8RN9zbvRoQhdmK0rxhXDFPzr+u45GV4WcUoCcdjeSpuTOgbMpU Wa9mM1UjaV+/+ohxLVQWRPO+oHBGkj9zCOIzRlmqW9Y3egy3Pk9vEfHHKXlI/BSx /FAzwmb1x8J5HIyg2cs1csB4kSNdKdysuRvHNGBvq1Y=; X-AuditID: c1b4fb2d-87c029c000005540-10-5a7c15ad67f0 Received: from ESESSHC006.ericsson.se (Unknown_Domain [153.88.183.36]) by sessmg23.ericsson.net (Symantec Mail Security) with SMTP id A4.15.21824.DA51C7A5; Thu, 8 Feb 2018 10:17:33 +0100 (CET) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.36) with Microsoft SMTP Server (TLS) id 14.3.352.0; Thu, 8 Feb 2018 10:17:33 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=LuVqiC6ojyBN16LspD2c+5Y/zW/g2NTHe08FMxJ0Y/A=; b=kfmOa2ofo0oxkJUShQmqll5F1/PQRPMBGogPKHClLQYbVLkxcfy9H7aq8nFW5VeTU1s0IWgTLOoX6Zz4MTlsT4Qbr9CwpfaC/xvp4twN72J0YA9lZskXLAien8PIjoOZXUn3TTEPF+PrCOxu2Xkd4kEqz7m5s7Mh/UgFiTEZUtc= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.25] (89.135.192.225) by AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.7; Thu, 8 Feb 2018 09:17:31 +0000 References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com> To: "netmod@ietf.org" , "netconf@ietf.org" From: Balazs Lengyel X-Forwarded-Message-Id: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com> Message-ID: Date: Thu, 8 Feb 2018 10:17:25 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com> Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [89.135.192.225] X-ClientProxiedBy: HE1P190CA0042.EURP190.PROD.OUTLOOK.COM (2603:10a6:7:52::31) To AM4PR07MB3425.eurprd07.prod.outlook.com (2603:10a6:205:b::10) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 63b72971-0935-409f-616d-08d56ed4c8b6 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:AM4PR07MB3425; X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 3:8dC0Oymb96fvpKXdiuBko/qZSLwARlJA4bzD1umLCHBfM22kKdTo0pbG3S27pAEOLTKWmqD0JUe6ASV9BiRHesMGUqmyb1YE43FuHZ8eCSNbKIGEeBr0E3qiHNYcR922xqYwIEiiUMEokdlOf2xXOwEQ4gkhZADP9qag4BWkVwjJUeNt+fjaga03pwDoqKjEBW9S9pa91wyK/P9oNGT9SfFFFMsIXSfHM0eErjblkNJ7IpP0kXZkx3eITBP10UFn; 25:sAlNuFkIDIP9usl593bRiRt6OZHR8Y4wrJODY8uEQ4SdyZ/aLfgK7DySfJ2TqyhlDUnx6vFE2CQccVIBb/EBZLSaUMDjRDFTTdHXnfwUrc/gl1LMdTczCH9tvVj43clEQZ60QkiVyvIT30NjvpTj4LjeknVcDI98X3/u06SezhxOkGqjw1f1q5jHg303eiD3VijpHlttB5PTUUWrIW4teeJw98dNdVKrlv6qHY+ia4aLrIsZUs4PLLhqnr3CJElv59TV0R4KXQrH/dFpemJD+YuTIzKH+SO8oWLOmkkoSmo/HAqunBNh7lTGWrKfCwSVV0zXvQzrX7D8+U1Dazu6GA==; 31:Wj9jMww0+xhmoeuPnHxnP6N6fWhSGEVM/0q6iba89bV3dpwuOPCP7+q7n/yWihrgWOa9wkIsXn3N98lbyELWM1ZZUqWfAxoJTTNdXv9oD6q38HDiNB5PsEE895RrUJhADak52ZVccOGaiC/lj1S0kvAMXcAsrl2AkAyf2eUkyWUO880riuHl9SV6cpWjZ6frcgu5jWG0J8EPq+APSwjNLWLSpBiOqCKkKBYrjNWLh6E= X-MS-TrafficTypeDiagnostic: AM4PR07MB3425: X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 20:nGWGHiP+V4Rj6X8dJcyDvIPFX6lZcu6k6EQrpN/HoUGZ5Kl+1nJnFaf2pMlSys0XAelNF+bLtJQ0hjCo1l4Ysy4I4EivNNpQ1XAoQJMRNIM5pRy8YMkUCBWWcMdAvi8lbmNooZwNyUiGBy4KrMpPoryAGGs7NO72+ykUp5sGVuzjrjOpEloV6vn5dNy1ikBwvtAVuwFiq3YTxEMjoEbCdb8bn4HQmpC7aRyxr9cfZZVOSFrZvDDsG6C8T32J8R6nX0RTVq+CIjBm0GGQkdRi1EZ2OxpNTrkGedzguthKQ18Ul08Bv0mmkk5qKkiAU938bHkPw+9VurhXRPf1iKNCQ7q7YOVTHMv5VIqjhgQvkl9ygcOb2WXBxI7kBFP0dUtnvJL5z+fG9M0IxRIfBUzqNXBGqvM2wNbgvsxYB+/kA8ELs1f7Czl6uvOC9JfQ8wrauaQ8+vt16Ryz12mqvK9eSuqFnJWIHZQNd7rt0mzhB5zQpS6rItLbyntgCgpTZzX5; 4:EhfYGMCycO7xnHhtIBUeIP+0mON1Oh3Jgg2An9nF2Bkc8uWpiVfJbaIRHNmT53WrncVQF/Tz8h5s3XiuNOOYqflE30XeLstOGgddZB2mLr/3P28w8mn2RlpoJ+MAj9QC99OzimpRyz6AD9MXDrmdx24zJYVXY4WjTfxc3U2gwMApMBFXC/hbLYj+yP8xbgPEDlV3NcgcmiC8Ml0zM0OFm604AR/dlxORw96pPF8mw8vUa3mSNeNljUEuNCCnPhuwvJRR5dGKeD/mz4fK389ebK1XLgRZjz6eH/D6FD3RJm1HnlxJRux+TB2O58jNAkQ7S8Ky4kwfW7wY7h0U2zWrDsTjzCprL2MO1SDw0rZqKemrWRnypkzXBl867bsmQpjjFVvG4rj6bGtlqC/2OqELTOeJPC/hR+5cE5g2btTZ8fQ= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(120809045254105)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231101)(2400082)(944501161)(6041288)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:AM4PR07MB3425; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB3425; X-Forefront-PRVS: 0577AD41D6 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(39860400002)(39380400002)(376002)(396003)(346002)(366004)(377424004)(252514010)(189003)(199004)(186003)(606006)(16526019)(966005)(26005)(86362001)(76176011)(2906002)(36756003)(386003)(49976009)(7736002)(59450400001)(66066001)(65956001)(65806001)(6666003)(31686004)(8936002)(450100002)(65826007)(2870700001)(25786009)(2950100002)(81166006)(8676002)(23846002)(31696002)(81156014)(97736004)(316002)(15650500001)(16576012)(5660300001)(58126008)(110136005)(23676004)(2486003)(52146003)(2501003)(53936002)(52116002)(64126003)(54896002)(6306002)(236005)(83506002)(50466002)(6116002)(105586002)(106356001)(68736007)(3846002)(6486002)(478600001)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3425; H:[159.107.197.25]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3TUIzNDI1OzIzOjZTaUpEa2VSaDRzcEU4TG1SdkwxbzFpUkYv?= =?utf-8?B?L0JMUW0yWld2Qk02b21GUjQzeVUrVkluZHFuN2pXMFkrT3YrS0FHSjFUOGY2?= =?utf-8?B?b0hHRXN0SFlTUDhZTzgrL1pwUHl4V3lJaDI2R0ZQWDVEZ0pNQU54eWhpcHBn?= =?utf-8?B?b1VXM2FzUEZZaHVKZDlaeTJkMm9Kd05QQzRqWE5Kb3REYzE0bXQ4VWgyai94?= =?utf-8?B?bXlkUHVSWWNFWGJSbXlmM3JRL1FGN3BnNS9tVWZyS3hkdCtjTVpkTVpaYUVF?= =?utf-8?B?SnJoay9VTm5lVDYwNHJ5Ym1FTngrY1JjajBhQlVvcTB0aFF3aWxWbU5DL1Jz?= =?utf-8?B?Q3VVMTYvVWJUb1NJTXdYdEd1aUVqVTBxd1dlVXlXOHdBc1FIOU8xZVBnU3l1?= =?utf-8?B?bitDNVlubWtMekdOclRWNVQrbDBGZ2FONTlsbW4rVHNrTXBmd2p0UEM4c3lx?= =?utf-8?B?MzREKzVjbXB6UjlVVTMvYWR4dEhUYnZmSlNqbkJaVGtMY1U0SWdnR0k5QjFD?= =?utf-8?B?WTVCRitxWU1xRXBZZXU2WW4reUtGc29BRzQzMHNQNTEzSlA5ZlJoZkVkODNv?= =?utf-8?B?WmVPZTFRRDlQS2RVN1huYlZhYXRBNnAvUUFUckpqZHNUb3padDZaa3JPZjc2?= =?utf-8?B?M0xCdjN0OENkeUEwSkFjdm11Y2psSHZ1cG11bnFPdkFWRnFLcFJhZnlsM0lH?= =?utf-8?B?ZVNLa215YjMzYWRhMXNPenZ4Q3JXOUJVVEw2YU5UMzVJdFFIV09UWlBRbm5k?= =?utf-8?B?NlZnL1ZHdTZZOTNRZVVDOFRHNlp1UFNCeUdwa3J1Ti9WWWlRQTBkMGMzeDZr?= =?utf-8?B?V3dPN2R4Tldmb1FOOUhaSW02Y28xZUE1QUo0SFlSbGtZNzVZZmV1a3BCQ2gw?= =?utf-8?B?Qlhra3U0MERVbjFteW9SdWE2ZUJCaVM0MVNZK3cyOWhXUGJJeTZ2V01mVkVD?= =?utf-8?B?QlFlVVE5b0NqbmkyZ3A1WWNDL0pKNWtTVzh5ZmMrdWVDOUVleHk0SDE2cW9o?= =?utf-8?B?eVMyOHJObTVUSm91T0VjYlpNampEYk90Rk02MzZNT3h6N1J3NmxoUWM0T2ZJ?= =?utf-8?B?d3hqUEpKanF2MXEydEtBSjlrdkV6WjNGbUY1amdNMU1RbWlGTkNTeS9VZDFi?= =?utf-8?B?T2wvM2xwUThSZ1l3RmlYdTJySzV4SWNZYkc1YytpL0s2Tkx1SUJrL0Zyb05O?= =?utf-8?B?NDNHU2dPV3JKS0ZHQ1kveFZOWnkyV01xNTd2di9rM2JjREY2Tjd3RVZ6cHYv?= =?utf-8?B?RFNpT0ZrVDdvRWIyOE5rQTdmNVdmaFRBVkxXTENuR1JkQ1F3bXc4bHRiTkpy?= =?utf-8?B?UGZRck5CTGNzRzhvL01VMnVwSnJpZzZmUjVHWjFtZmt6TFM0TEJDRTRmNEZ2?= =?utf-8?B?blNkZkgwZ3dZUXE5cEdyNjNZazkyN1pxTnNRNDhQalJDd3V0dWtqTXBna3hx?= =?utf-8?B?S3FpcFViankyejVHbkg2REJzUG1qNlBhZDBHZnUxYVB6dFNSOVhTWFRlYjMy?= =?utf-8?B?TW1qYUQ0M2hZMllPNTlERzBrbnNKWmgyU1c5dkhzUko5WWc5YTJscWQxaVZr?= =?utf-8?B?Mkd0UzRMSmpncmQvN2FLVHFMdHZMeUNMUVN5T0ZXVldhcEFQakMxNm91Z2tG?= =?utf-8?B?eXhqZmtna2JEQnNSUmxIelVGUFZxOEh1SjcySUIrTk1YNDEwN1Y4d0FOQnRT?= =?utf-8?B?M3JvbDI3ZnovYTg3NExUbU9BbGFoYlBuS0FNSEp5cDRhQmZvbThRTEVSZlNS?= =?utf-8?B?R1E3U2JQMVpzL3diSWxJcHh4TFU2SlVnb2YvSWpnclBmbVpWYzVKWHpBMTBU?= =?utf-8?B?WnBwcVVIL3dDKzN1RFRUUWVzZUd6aldVUkk0bWhPUUQzdmRhTXhvRW5YeTBO?= =?utf-8?B?TkhNQmZ0MG9ScTV5N25FQ3RZcjNDTXR3ajhxQUh5T2NBQXNWSVJqQjRFSVNX?= =?utf-8?B?ZHhnb3VHV2lvTWJWb1hoZ05kMXkxRDFDMkFuQkZuM1k2aUE3L2l6aUlhTFAz?= =?utf-8?B?Y083L1R2UGRpSWw0ZjhVdzFnajZoUHoyOElGampkdmp2Zkh5d0hXQmwzemh1?= =?utf-8?Q?qDEY=3D?= X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3425; 6:r33Cup8F6fL9i+CwK+Ya7nnQn12f28farMOtoEvv3oiZz0HtZJMdbYCrcSf7GY/TKNugMUEIKoQ95Ve7YPYP3NH5FK3tgJ5uQtVtVCdwUtSOsLs+5RKRu8Kd1aKb/hu/m730jWYAua1XUkU/psX66VI2uSOJTf63Tg2khL7NXjPjIQPaSnvzaAOfYlj8HDbRvex2oQ76ALUG0fBSLmbRIz4/boREOCpyfN1owzGO1Sh0H7qPizPikgFXXXv3iVvlfUBdSjUz+JHQBzSG61pE/mnEL8mrNRJwzqIftMWMxNfIIhD1rUzeltKlionEN3u6Kr/Wqyu9oy3A9ealgJeQQN0nwwOJTZEs2jr7VXrSDcc=; 5:qDgLghVWzdeo8A8KiLkZmxVEP31kzelQiswchhbCUhPlf2jz3pnbZNnDPyzv3UF1W7HwlpvrWRawnpb+SGXCQZRmX1EjUGFUc0g77jhwLdP7LbAAr5zeGW+Fv4kuFIGWxpl6Ly0oRvRQnmllBv3/4ENsnijYRs0tB/96217ITCc=; 24:1qLDUpY4to7KvzXN7e5UD8GVkwjW/OuY8AE0tgYL41K5ejuC67oifW2DXAi0rc6mrQ9X5rxF5dKYB6eSQolyIcKy+niUGhwM10uUD9Ye/8Y=; 7:bDSZ1Yh+lkJayClmBk20I8tUgYuTVfo8YIYzsoc9mHeDg/8bE+eOv/8klLAJW09EloupWGnGk7Ji1taqKGzZQoe6SBy/NrwOCDSCgVscc6hGAXW9AUFzAyHIW91PAvAV7eqksQr7+dxHrqbJEl3t5Yc0YkHea3CvsCsxiYdgzvpJddEcEkyeszWXZEQxDlzNDRU2CJvntW3Mv87N0mFyymTcJ3x6dGQh9B7hISzFZorv3nmBE7COkfJ1HGhXlT+a SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2018 09:17:31.9029 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 63b72971-0935-409f-616d-08d56ed4c8b6 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3425 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpileLIzCtJLcpLzFFi42KZGbFdRXetaE2UwevlJhZTN91mtZh/sZHV gcljyZKfTAGMUVw2Kak5mWWpRfp2CVwZMydMYy64JF/x4uV+lgbGsxJdjJwcEgImEn93fWbr YuTiEBI4zCjxZvlcZgjnOKPEkWPTwDIsAp+YJCbd2ssC0sIoECexc81CVoiqBiaJf1Na2UES wgJhEv8a9rKC2EICvhJP7t4Gs0UE/CROn5zGDGKzCRhJTO0/zwKxO1Ki6fsXNhCbV8Be4umt brB6FgEVifeTn4PViwrESEz9uJEVokZQ4uTMJ2C9nEAzbyxdABZnFtCQaJ0zlx3CFpe49WQ+ E4QtL9G8dTYzxC4liUtfprGAHC0hMJFR4u2XCSwQh2pIPLzwlxWiSFbi6Nk5UMf5Slxpms4M 0bCfUWLXrC9QkxrYJeZOsYWwtSRmHFnGBlH0hF1i4rOdjBCJbImpK06zQdg5Ete7jzNCFM1g lvjachVqnYzEnZsz2Scw6sxC8t4sJC/NQvLSLCQvLWBkWcUoWpxaXJybbmSsl1qUmVxcnJ+n l5dasokRmDIObvmtu4Nx9WvHQ4wCHIxKPLxb7lRHCbEmlhVX5h5ilOBgVhLh9fQBCvGmJFZW pRblxxeV5qQWH2KU5mBREuc96ckbJSSQnliSmp2aWpBaBJNl4uCUamAMDOv8w1Zqc+8E+1zJ Muf41X+OHV7y9JHPjHtHvRlUV8zeIOabK7nNuq60sXfGLdnH/y041BedzHL6nX/RPNfwuPpr K+96lon3beWCJ7/zm9jsfMRwi8KnMzvSPnw/ZMz3/9Vvl+Iq1e2Meaeel3TfZJn3+3OTW+cG /ppLhx/OeOv52lj7taOSEktxRqKhFnNRcSIA3Y/vQhUDAAA= Archived-At: Subject: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 09:17:39 -0000

Hello,

With Benoit I prepared a draft about how to document and use YANG defined instance data. It could be useful for documenting  server capabilities or preloading data defined in implementation time and probably for other purposes as well.

regards Balazs


-------- Forwarded Message --------
Subject: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
Date: Wed, 7 Feb 2018 09:28:50 -0800
From: internet-drafts@ietf.org
To: Benoit Claise <bclaise@cisco.com>, Balazs Lengyel <balazs.lengyel@ericsson.com> 


A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt
has been successfully submitted by Balazs Lengyel and posted to the
IETF repository.

Name:		draft-lengyel-netmod-yang-instance-data
Revision:	00
Title:		YANG Instance Data Files and their use for Documenting Server Capabilities
Document date:	2018-02-06
Group:		Individual Submission
Pages:		10
URL:            https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt
Status:         https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/
Htmlized:       https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00
Htmlized:       https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00


Abstract:
   This document specifies a standard file format for YANG instance
   data, that is data that could be stored in a datastore and whose
   syntax and semantics is defined by YANG models.  Instance data files
   can be used to provide information that is defined in design time.
   There is a need to document Server capabilities (which are often
   specified in design time), which should be done using instance data
   files.

                                                                                  


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

The IETF Secretariat


-- 
Balazs Lengyel                       Ericsson Hungary Ltd.
Senior Specialist
Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
From nobody Thu Feb 8 01:24:16 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EAED12D874 for ; Thu, 8 Feb 2018 01:24:14 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6AyAcZucNjGu for ; Thu, 8 Feb 2018 01:24:12 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 15FEF12D86D for ; Thu, 8 Feb 2018 01:24:12 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DCD96FBA; Thu, 8 Feb 2018 10:24:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Nq9R_VBPpU4k; Thu, 8 Feb 2018 10:24:10 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 8 Feb 2018 10:24:10 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id B8D152014E; Thu, 8 Feb 2018 10:24:10 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id ZihkWhFrwrk1; Thu, 8 Feb 2018 10:24:09 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 08C3E2014B; Thu, 8 Feb 2018 10:24:09 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id AE288423DA11; Thu, 8 Feb 2018 10:24:08 +0100 (CET) Date: Thu, 8 Feb 2018 10:24:08 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Cc: "netmod@ietf.org" Message-ID: <20180208092408.ir25jwkorxozq6gr@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 09:24:14 -0000 [Removing NETCONF since the I-D says -netmod-.] I flipped through the I-D yesterday and I think a common format for instance data trees should be NMDA aware these days. /js On Thu, Feb 08, 2018 at 10:17:25AM +0100, Balazs Lengyel wrote: > Hello, > > With Benoit I prepared a draft about how to document and use YANG defined > instance data. It could be useful for documenting server capabilities or > preloading data defined in implementation time and probably for other > purposes as well. > > regards Balazs > > -------- Forwarded Message -------- > > Subject: New Version Notification for > draft-lengyel-netmod-yang-instance-data-00.txt > Date: Wed, 7 Feb 2018 09:28:50 -0800 > From: [1]internet-drafts@ietf.org > To: Benoit Claise [2], Balazs Lengyel > [3] > > A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt > has been successfully submitted by Balazs Lengyel and posted to the > IETF repository. > > Name: draft-lengyel-netmod-yang-instance-data > Revision: 00 > Title: YANG Instance Data Files and their use for Documenting Server Capabilities > Document date: 2018-02-06 > Group: Individual Submission > Pages: 10 > URL: [4]https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt > Status: [5]https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ > Htmlized: [6]https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 > Htmlized: [7]https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 > > > Abstract: > This document specifies a standard file format for YANG instance > data, that is data that could be stored in a datastore and whose > syntax and semantics is defined by YANG models. Instance data files > can be used to provide information that is defined in design time. > There is a need to document Server capabilities (which are often > specified in design time), which should be done using instance data > files. > > > > > Please note that it may take a couple of minutes from the time of submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > -- > Balazs Lengyel Ericsson Hungary Ltd. > Senior Specialist > Mobile: +36-70-330-7909 email: [8]Balazs.Lengyel@ericsson.com > > References > > Visible links > 1. mailto:internet-drafts@ietf.org > 2. mailto:bclaise@cisco.com > 3. mailto:balazs.lengyel@ericsson.com > 4. https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt > 5. https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ > 6. https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 > 7. https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 > 8. mailto:Balazs.Lengyel@ericsson.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 Thu Feb 8 05:32:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 47A8012D95A for ; Thu, 8 Feb 2018 05:32:39 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EN7ScXvUmt0u for ; Thu, 8 Feb 2018 05:32:37 -0800 (PST) Received: from zinfandel.tools.ietf.org (zinfandel.tools.ietf.org [IPv6:2001:1890:126c::1:2a]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 34D5112D943 for ; Thu, 8 Feb 2018 05:32:37 -0800 (PST) Received: from h-99-61.a357.priv.bahnhof.se ([82.196.99.61]:49635 helo=[192.168.1.120]) by zinfandel.tools.ietf.org with esmtpsa (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128) (Exim 4.80) (envelope-from ) id 1ejmJV-0001cc-7h; Thu, 08 Feb 2018 05:32:34 -0800 To: Benoit Claise , "t.petch" , NETMOD Working Group References: <26131545-049c-9a1a-eb2b-cdad6fce3190@cisco.com> <036201d39c25$7bb5a060$4001a8c0@gateway.2wire.net> From: Henrik Levkowetz Message-ID: Date: Thu, 8 Feb 2018 14:32:25 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="RItjovtWlW0opwCreDQK39s3jJU6L6AbV" X-SA-Exim-Connect-IP: 82.196.99.61 X-SA-Exim-Rcpt-To: netmod@ietf.org, ietfc@btconnect.com, bclaise@cisco.com X-SA-Exim-Mail-From: henrik@levkowetz.com X-SA-Exim-Version: 4.2.1 (built Mon, 26 Dec 2011 16:24:06 +0000) X-SA-Exim-Scanned: Yes (on zinfandel.tools.ietf.org) X-Clacks-Overhead: GNU Terry Pratchett Archived-At: Subject: Re: [netmod] Missing references X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 13:32:39 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --RItjovtWlW0opwCreDQK39s3jJU6L6AbV Content-Type: multipart/mixed; boundary="mIt1dMA1JI6gmtjT2b7O22fwA8073kT7F"; protected-headers="v1" From: Henrik Levkowetz To: Benoit Claise , "t.petch" , NETMOD Working Group Message-ID: Subject: Re: Missing references References: <26131545-049c-9a1a-eb2b-cdad6fce3190@cisco.com> <036201d39c25$7bb5a060$4001a8c0@gateway.2wire.net> In-Reply-To: --mIt1dMA1JI6gmtjT2b7O22fwA8073kT7F Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Hi Benoit, On 2018-02-07 12:56, Benoit Claise wrote: > Hi Henrik, >=20 > Could this check be added to idnits? Yes. I thought I had something like this already, but it was specificall= y to look out for mentions of RFC2119. As you may know, I'm due to begin a complete rewrite of idnits, from the current implementation (idnits started as a 10-line AWK program to check draft line lengths, in 2000 or 2001) to Python, this March. I'd like to defer this till then; adding code to the now close to 4000 lines of mixed= AWK and bash isn't always straightforward. Best regards, Henrik > Regards, Benoit >> I just came across (yet) another example of a reference to an RFC in a= >> description clause of a YANG module that appears nowhere else in the >> I-D. >> >> This seems to be a systematic error that some YANG module authors make= ; >> can the tools be modified to pick it up? The logic is simple enough. >> >> The latest example is in draft-ietf-rtgwg-yang-rip-09 which fails to >> reference RFC5952; I think that the I-D is in the RFC Editor queue. >> >> Tom Petch >> >> . >> >=20 >=20 --mIt1dMA1JI6gmtjT2b7O22fwA8073kT7F-- --RItjovtWlW0opwCreDQK39s3jJU6L6AbV Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEifjc5+rnL1MJBcZSTptXS4+7FxoFAlp8UWkACgkQTptXS4+7 Fxrxnw/9E6Y86qebSxQDKPwG4JRVeDQoc9r+bq/eiSMF+ProS/4tRFUUlurJOoG2 vUvbLRqtMr6CIQRvaZUVK63Jh4kj8/klJDko+Q9Jn6cS1sbBSnI8F1FFYTJI6fbs T5U9Vs2HogrLQ/TE2WhMvnKgn3N21LtcuubVYNuaK3WABswhe0/5Gcc+kWLFg87W zcjuXcgM3YAMoHw1EGZxpSXgjunyoBxknq1RyQcwYs5PoOkQzQyoF6LIJWO0zIgy y3irR2aWr5RgCZG6TBH7HfRLLwgIuDusRXYckqLuouj4KnSMkCMbJHSf2howK2Fu +NiDZoW7WWAD+pxq7JrkCAfJ12sC5E0HTvY8wZW/61n//QtluCbzeJmjpFzQRQpg Bi65cCZ9Jgi0bc7KpaRSfBrClJwepIEsdlTnHSHZasTelPnQGZjzFHG+cBxqjNdH JG5PT0nvIL+vSsaptgQaf264TjS9+H/m/zXNHHP1X4LLCDJXUwQMZOvP5oVwr2sg kOkCfPDs0w3ydOace59AoyDrYffdrHXr6BdNdRIQv+Yg9owrkFl1yL0X9ggSaEJY wuZ+PEaI1WCglhlOlwvMGNQKFA28GhoP0uQF5qEUT1OIA6AOOMgZNKjtqKj2LNM8 mFk8NMlKMy5qTfs7EQQjFL6LoORpz5fw2BdT6EFWNJ30uQc5KUY= =EHBh -----END PGP SIGNATURE----- --RItjovtWlW0opwCreDQK39s3jJU6L6AbV-- From nobody Thu Feb 8 05:41:00 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDC2812D963 for ; Thu, 8 Feb 2018 05:40:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id W64yBgptfaps for ; Thu, 8 Feb 2018 05:40:57 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1199512D957 for ; Thu, 8 Feb 2018 05:40:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1219; q=dns/txt; s=iport; t=1518097257; x=1519306857; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=Fz0sXQ+2hj0evO9dho3h/ihGqA9Zo8g75H2othmsFXE=; b=G3yTvpefC0YQ8NXrzt/aMVsVk1QGnx7L1OpUGA8GV4jLvVON3e2vaqU+ 2MECxMd2G3XMkhtmtrzYmiAjwgOmLQM2FU/vzKX5S8A8r0yNDCOI/mhcZ Yaezj2JGTeQ/Ig9a0lMggo+IXcwxOItyzjtIZARR8r/sTNXQZUZQ8lHKu I=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQDVUnxa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUnhA2LGI80mW0KhTsCgwIUAQIBAQEBAQECayiFJAEFIxVRCxg?= =?us-ascii?q?CAiYCAlcGAQwIAQGKMa88gieFAIN3ggoBAQEBAQEEAQEBAQEjgQ+DaoNsghGDB?= =?us-ascii?q?Yg5gmUFpCsJlXyMOIgGj3WIF4E8NiKBUDMaCBsVgwSEd0COCAEBAQ?= X-IronPort-AV: E=Sophos;i="5.46,478,1511827200"; d="scan'208";a="1942938" Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2018 13:40:54 +0000 Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w18DesUY016076; Thu, 8 Feb 2018 13:40:54 GMT To: Henrik Levkowetz , "t.petch" , NETMOD Working Group References: <26131545-049c-9a1a-eb2b-cdad6fce3190@cisco.com> <036201d39c25$7bb5a060$4001a8c0@gateway.2wire.net> From: Benoit Claise Message-ID: <6ea61665-d90d-5ac8-41a2-e3df36ff130b@cisco.com> Date: Thu, 8 Feb 2018 14:40:54 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US Archived-At: Subject: Re: [netmod] Missing references X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 13:40:59 -0000 Hi Henrik, It makes sense. Thanks. Regards, B. > Hi Benoit, > > On 2018-02-07 12:56, Benoit Claise wrote: >> Hi Henrik, >> >> Could this check be added to idnits? > Yes. I thought I had something like this already, but it was specifically > to look out for mentions of RFC2119. > > As you may know, I'm due to begin a complete rewrite of idnits, from the > current implementation (idnits started as a 10-line AWK program to check > draft line lengths, in 2000 or 2001) to Python, this March. I'd like to > defer this till then; adding code to the now close to 4000 lines of mixed > AWK and bash isn't always straightforward. > > > Best regards, > > Henrik > >> Regards, Benoit >>> I just came across (yet) another example of a reference to an RFC in a >>> description clause of a YANG module that appears nowhere else in the >>> I-D. >>> >>> This seems to be a systematic error that some YANG module authors make; >>> can the tools be modified to pick it up? The logic is simple enough. >>> >>> The latest example is in draft-ietf-rtgwg-yang-rip-09 which fails to >>> reference RFC5952; I think that the I-D is in the RFC Editor queue. >>> >>> Tom Petch >>> >>> . >>> >> From nobody Thu Feb 8 06:11:26 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E5012D969 for ; Thu, 8 Feb 2018 06:11:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.211 X-Spam-Level: X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K2OTdH96sXfl for ; Thu, 8 Feb 2018 06:11:23 -0800 (PST) Received: from rfc-editor.org (rfc-editor.org [4.31.198.49]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 29D5012D957 for ; Thu, 8 Feb 2018 06:11:23 -0800 (PST) Received: by rfc-editor.org (Postfix, from userid 6000) id C5E82B80FB0; Thu, 8 Feb 2018 06:11:13 -0800 (PST) Date: Thu, 8 Feb 2018 06:11:13 -0800 From: RFC Editor To: "t.petch" Cc: NETMOD Working Group , RFC Editor Message-ID: <20180208141113.GA24140@rfc-editor.org> References: <017b01d3a039$1d4c5c40$4001a8c0@gateway.2wire.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <017b01d3a039$1d4c5c40$4001a8c0@gateway.2wire.net> User-Agent: Mutt/1.5.24 (2015-08-30) Archived-At: Subject: Re: [netmod] Draft Normative references in a YANG module X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 14:11:25 -0000 Hi Tom, On Wed, Feb 07, 2018 at 05:28:30PM -0000, t.petch wrote: > Will the RFC Editor know that > > reference "draft-ietf-netmod-rfc7223bis: A YANG Data Model > for Interface Management"; > in > > draft-ietf-rtgwg-ni-model-09 > > needs replacing by RFCxxxx when that I-D becomes an RFC? > > Normally, such a reference would be [draft-ietf-netmod-rfc7223bis] with > the underlying HTML/XML anchor and automated tools can pick this up (I > assume that the RFC Editor is well automated:-) > > But when the Normative Reference is in the text of a YANG module and > there is no underlying anchor, will this get noticed and actioned? > > Or should there be a > > Note to RFC Editor > > attached to such references? We should notice this as we read through the document (including the description and reference text in the YANG module). However, placing a note within the document somewhere that acts as a reminder to update the I-D string with the appropriate RFC number is never a bad thing. Thanks, RFC Editor/sg > > Tom Petch From nobody Thu Feb 8 06:42:28 2018 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 E2EE4127058; Thu, 8 Feb 2018 06:42:26 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151810094687.17204.16895299331910915324@ietfa.amsl.com> Date: Thu, 08 Feb 2018 06:42:26 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-yang-tree-diagrams-06.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 14:42:27 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : YANG Tree Diagrams Authors : Martin Bjorklund Lou Berger Filename : draft-ietf-netmod-yang-tree-diagrams-06.txt Pages : 13 Date : 2018-02-08 Abstract: This document captures the current syntax used in YANG module Tree Diagrams. The purpose of this document is to provide a single location for this definition. This syntax may be updated from time to time based on the evolution of the YANG language. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-yang-tree-diagrams-06 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-tree-diagrams-06 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-yang-tree-diagrams-06 Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Thu Feb 8 08:34:19 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5924412D7EF for ; Thu, 8 Feb 2018 08:34:18 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2NVbavA3dPr2 for ; Thu, 8 Feb 2018 08:34:15 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0688D12426E for ; Thu, 8 Feb 2018 08:34:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22315; q=dns/txt; s=iport; t=1518107655; x=1519317255; h=references:subject:to:from:message-id:date:mime-version: in-reply-to; bh=q2jMbycl2Pfwbqk9RIKTdUSYYHPlrFYBVvss4V5zBak=; b=Ar5lPrtWUnpbaSU+/43Sh9Exco0hTn14i6v40JDd6kM7Ag+VFrg8/75D u3dwcOlHaJ7nlwDBnayhQOEH2MTg8HdNGsS6WlRrie7aL7rq+JvnkjU8V vL/SIz0CxNfpIidbUlDa+BJ8c/90OCuauZh4+WVGjIqFsqPZpJ7vbFCcA 0=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CBAQC6enxa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ3cCiDZYsYjw2SIodyBwMYAQqESU8CgwYVAQIBAQEBAQECayi?= =?us-ascii?q?FJAIEAQEhSxsPAT0CAicmCgYNBgIBAYoxEK8lgieFAYN3gXoBAQEBAQEBAwEBA?= =?us-ascii?q?QEBAQEBEQoFhHyFfQyCeYFJgWYBAQKFBoJlBYgDikmHWIoHCYRmgjKFC4N9hVy?= =?us-ascii?q?MOIgGmAyBPDUjgVAzGggbFT2CRoJhghdAN41NAQEB?= X-IronPort-AV: E=Sophos;i="5.46,479,1511827200"; d="asc'?eml'208?scan'208,208,217";a="1946193" Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2018 16:34:13 +0000 Received: from [10.61.225.27] ([10.61.225.27]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w18GYCGf014769 for ; Thu, 8 Feb 2018 16:34:12 GMT References: To: netmod WG From: Eliot Lear X-Forwarded-Message-Id: Message-ID: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> Date: Thu, 8 Feb 2018 17:34:09 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="gMidIJBmtaW1cKlk2rsi4FlMWamjskSC9" Archived-At: Subject: [netmod] Fwd: [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 16:34:18 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --gMidIJBmtaW1cKlk2rsi4FlMWamjskSC9 Content-Type: multipart/mixed; boundary="IaOTFCBscT8Qp7FSpX4vd04BjbBW0KQJ1"; protected-headers="v1" From: Eliot Lear To: netmod WG Message-ID: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> Subject: Fwd: [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang References: In-Reply-To: --IaOTFCBscT8Qp7FSpX4vd04BjbBW0KQJ1 Content-Type: multipart/mixed; boundary="------------CD648F72278884C5B5782626" Content-Language: en-US This is a multi-part message in MIME format. --------------CD648F72278884C5B5782626 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable --------------CD648F72278884C5B5782626 Content-Type: message/rfc822; name="[OPSAWG] Minor change in ietf-access-control-list@2018-02-02_yang.eml" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename*0="[OPSAWG] Minor change in ietf-access-control-list@2018-02-02"; filename*1="_yang.eml" X-Mozilla-Keys: Received: from xch-rtp-001.cisco.com (64.101.220.141) by xch-aln-005.cisco.com (173.36.7.15) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Mailbox Transport; Thu, 8 Feb 2018 10:30:51 -0600 Received: from xch-rtp-002.cisco.com (64.101.220.142) by XCH-RTP-001.cisco.com (64.101.220.141) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Thu, 8 Feb 2018 11:30:50 -0500 Received: from rcdn-iport-9.cisco.com (173.37.86.80) by mail.cisco.com (64.101.220.142) with Microsoft SMTP Server (TLS) id 15.0.1320.4 via Frontend Transport; Thu, 8 Feb 2018 11:30:48 -0500 Received: from alln-core-1.cisco.com ([173.36.13.131]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2018 16:30:41 +0000 Received: from alln-inbound-m.cisco.com (alln-inbound-m.cisco.com [173.37.147.243]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w18GQFjS013312 (version=TLSv1/SSLv3 cipher=DHE-RSA-SEED-SHA bits=128 verify=OK); Thu, 8 Feb 2018 16:26:15 GMT Received-SPF: Pass (alln-inbound-m.cisco.com: domain of opsawg-bounces@ietf.org designates 2001:1900:3001:11::2c as permitted sender) identity=mailfrom; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-m.cisco.com; envelope-from="opsawg-bounces@ietf.org"; x-sender="opsawg-bounces@ietf.org"; x-conformance=spf_only; x-record-type="v=spf1"; x-record-text="v=spf1 ip4:12.22.58.0/24 ip4:64.170.98.0/24 ip4:4.31.198.32/27 ip4:209.208.19.192/27 ip4:72.167.123.204 ip6:2001:1890:123a::/56 ip6:2001:1890:126c::/56 ip6:2001:1900:3001:0011::0/64 ip6:2607:f170:8000:1500::0/64 -all" Received-SPF: None (alln-inbound-m.cisco.com: no sender authenticity information available from domain of postmaster@mail.ietf.org) identity=helo; client-ip=2001:1900:3001:11::2c; receiver=alln-inbound-m.cisco.com; envelope-from="opsawg-bounces@ietf.org"; x-sender="postmaster@mail.ietf.org"; x-conformance=spf_only Authentication-Results: alln-inbound-m.cisco.com; spf=Pass smtp.mailfrom=opsawg-bounces@ietf.org; spf=None smtp.helo=postmaster@mail.ietf.org; dkim=pass (signature verified) header.i=@ietf.org; dkim=hardfail (body hash did not verify [final]) header.i=@gmail.com; dmarc=fail (p=none dis=none) d=gmail.com X-from-outside-Cisco: 2001:1900:3001:11::2c IronPort-PHdr: =?us-ascii?q?9a23=3AnuCrmhzK35FznFzXCy+O+j09IxM/srCxBDY+r6?= =?us-ascii?q?Qd0e4TLvad9pjvdHbS+e9qxAeQG9mDsrQc06L/iOPJYSQ4+5GPsXQPItRndi?= =?us-ascii?q?QuroEopTEmG9OPEkbhLfTnPGQQFcVGU0J5rTngaRAGUMnxaEfPrXKs8DUcBg?= =?us-ascii?q?vwNRZvJuTyB4Xek9m72/q99pHPfglEniaxba9vJxiqsAvdsdUbj5F/Iagr0B?= =?us-ascii?q?vJpXVIe+VSxWx2IF+Yggjx6MSt8pN96ipco/0u+dJOXqX8ZKQ4UKdXDC86PG?= =?us-ascii?q?Av5c3krgfMQA2S7XYBSGoWkx5IAw/Y7BHmW5r6ryX3uvZh1CScIMb7S60/Vz?= =?us-ascii?q?a/4KdxUBLmiCkJOT0n/m/Kksx9jqBVrR28qxFx34LbfJ+aNOFlc6PYYd8XX3?= =?us-ascii?q?BMUtpNWyFDBI63cosBD/AGPeZdt4TxqVwAoQGjDgewHuzvzDBIiWXw3aIgz+?= =?us-ascii?q?QhERvJ3AouE9kTt3nUqc/1O70UUeC61qbF1jrDb/ZM1jf87IjEaAwuofaJXb?= =?us-ascii?q?9pd8fa1EohFxvdg1mOtYDpIy6Z2+EQv2Wf8+ZsSeeihmA7pw1tvzSiw9oghp?= =?us-ascii?q?TMi48Q1FzL6T11zJg0KNGkSkN2ZNCkHZhLuC2GMoZ7Td8uT31mtSs/1rIKpZ?= =?us-ascii?q?+2cS0PxZg5yRPTd/qKeJWS7B35TuaeOzJ4iWpleL2hgxay9lCtyujmWcm11F?= =?us-ascii?q?ZGtCtFncfQtnADzRDT7dKHSvRl8keg3zaAyRzT5/laLUwoiabXNpsszqM0m5?= =?us-ascii?q?YPrUjOGyH7lFnqgKOLc0go5/Wk5uHib7n4upCQL4p0hRv/MqQqlMy/G+M4Mg?= =?us-ascii?q?0WUmic4eS8z6fs/EP2QLlTlfI2lbTZsJbGKssFva60GA5V3Zg/6xaxFTum18?= =?us-ascii?q?4YnXYfIFJfZB2Hl5TpO03JIP3gF/iwnkmjkDBkx/DcJLLsGYnCLnnYkLj9er?= =?us-ascii?q?Zx8VJTyA02zdpH/ZJbFqkBIO7vWk/2rNHXFQM2MwiuzObmE9VyyJgTVn6OAq?= =?us-ascii?q?+CLKzStkWE6f4oI+mJfIUVoiryK+A55/7yin80gUQScren3JYMdH+4H+9mLF?= =?us-ascii?q?meYXb2ntgBFmIKtBIkTOP2kF2CTSJTZ3GqUq0n4jE0E5ipDYPZSYCvgbyMxz?= =?us-ascii?q?u0HpxNZm9aDVCAC2vnd4KBW/0UciKdPtdhkiAYVbimU4IuzhGvtA3ny7p/Ie?= =?us-ascii?q?rZ4TEXtZP41Ndp4O3fjw099TtxD86FyWGCU3l0nn8URz8xxK1wvVR9ylaM0a?= =?us-ascii?q?h+mfNYCcZc6uhVXQc7Lp7T0+t6B8ruVQLGe9eDUEymTcm+ATEtUtIxxMcDbF?= =?us-ascii?q?tnFNW8jxDMxDClA7sRl7GQGJM087nc0GT2J8pn13nG06whhUE8QsRTLW2mmr?= =?us-ascii?q?J/9w/LCoHUnUSZl6eqdbgC0y7P7meO1naBvEBDUAFsVqXJR2wQZkzTrd7h/E?= =?us-ascii?q?PNU6euCag7MgtG0cONN6VLatzvjVVJX/rsJNXeY3mtlGe3HxqH2rSMbI/ycW?= =?us-ascii?q?UHwCrdEFQEkxwU/XueKwc+ByGhrHjEDDxoE1LieF/j8ehlqHynSU841R2Fb0?= =?us-ascii?q?pk17Ct4B4ameScS+8P3rIDoCoutSt0HVa7393KCNqPuRFsc7ldYdMm/FhH0n?= =?us-ascii?q?jVuBB6PpylN6pinEIRcxxrv0Py0BV6EotAntMwrHMt0AVyKqSY301aejyE3J?= =?us-ascii?q?DwIaHYKm7o8B+zbK7W30nU0MyK9acX9PQ4t1LjsRmnFkU+6Xpn18Na3GCG5p?= =?us-ascii?q?XLFwcdTZPxUl0r+Bh9vb3Vfi4954bM3312Laa0qiPC284uBOY9xBagZclQP7?= =?us-ascii?q?6fGQDuEs0aHNShKOswl1e1aRIEOfhY9LQoMMO+a/uGxKmrMf5vnDK9l2tH5o?= =?us-ascii?q?N93ViW9yVmUePHw5cFw+qE0QuATTvzkFChssXvk4BeeT4SBna/yTTjBINJZK?= =?us-ascii?q?19YYILBn20I8202NpznILiW39D9FG/AFMKwtOmeR2Xb1blxw1fyVwXoWC7mS?= =?us-ascii?q?u/1zF0ly8mobCF3CHV3+vidQEHNXJMRGV4kVjsJo20hcgAXEe0dwgpiAel5U?= =?us-ascii?q?Hiyqhevqt/NHTTQUJTcifqLmFiSbe/tr2Yb8FT75MotD1dUP6gblCCVr79vx?= =?us-ascii?q?wa3jvmH2tbwzA7bSuqupL3nhFhlG2dLW1zo2beec1q2Rjf49ncT+ZL3jUaXC?= =?us-ascii?q?l4lSXXBl+kMtms+tWUipPDvfy+V227UJ1eajXkzYKbtCSn4m1mGwGwn/e2mt?= =?us-ascii?q?f/Cwg1zTf718V2VSXPtBv8ZJPk16W5MeJ6e0lnHkX85tFmFYF/iYs/mJYQ1W?= =?us-ascii?q?IGiZWS+HoNiX3zPslD2aLicHoNQiYGw8bP7wf4xU1jIHyJxoLiW3qBw8thfM?= =?us-ascii?q?W1YmQM1i0h6MBKDb+e7KZYkittvlq4sQXRbOBlnjcH0/Qu9n8ag+MTtwst1S?= =?us-ascii?q?iSHrESHVJEMizrjRiH89e+rKBPbma1bbewzFZ+ncymDLyauAFcX232epItHS?= =?us-ascii?q?909chwLFPM0Gbv5YHjYtXfcdUTthiMmRfak+dVMI4xluYNhSd/I2L9pWcqyu?= =?us-ascii?q?87jR1ux566upOKJHls/KKiHhFYMSf5aN8U+jHolaxehNqZ35izHpV9HTUGRI?= =?us-ascii?q?HoTem1EDIItPTqLBqBEDwnqniHHrrTBxOQ6EBjr3jXCZCkK2mXJGUFzdVlXB?= =?us-ascii?q?SdP1dQgAIOUzUgmJ42DBuqydf9f0d4/TAe+ln4pgFQxeJvMhn1Sn3fqxuwaj?= =?us-ascii?q?coVJifKwJb7hpf6EjPN8yR8/h8EjpE8Z2gtwyCNmubax5UAmEOX0yOH0rjMa?= =?us-ascii?q?W25dnc7+iYAfKzL+DBYbWTr+xRSu2HxYyx3YZ94zmMN96PMWVlD/EhxkVDWn?= =?us-ascii?q?V5EdzDmzoTUywXiz7Nb8mDqRen+i13stu/8On3VwLv5IuCEKddMdR0+x+qhq?= =?us-ascii?q?ePLfKfhCF8KTxAzJMD2WfIyKQD3F4VkyxubCOtEbUcui7NV6/fhq5XDwUHZC?= =?us-ascii?q?N0LsdH86U83gxVM87Bltz1zqJ4juIyC1pdTlzhgd+mZcoWI2G9NVPHAF2GO6?= =?us-ascii?q?iHJT3Q3873ZrmwRqFXjOVRrxewoyqUE1f/PjSfkDnkTwyvMfpSgyGdIhNepo?= =?us-ascii?q?C9cgx2BGf/TdLmcQG0MNhtgTIqxr00gyCCCGgHLDIpc19RtqbCqmRHneo5Gm?= =?us-ascii?q?Fd4DxiN+bDni+Y6+zRLNERqedqBSJv0OVC+30lxOho6jpZTqlwkSrWstk8pE?= =?us-ascii?q?m9m/aAjyBqSQdDsSpjhY+XswNlI6qO7YRKW3vP4EcQ636NAQ8BvdpvB47TvP?= =?us-ascii?q?VX0sPGi63bKTpe/ZTT58RPKdLTLZfNFTxpCxPvFzfSBRcFRDjhfTXanUVbn/?= =?us-ascii?q?i6+Xicr5x8oZ/pzsldAoRHXUA4Q6tJQn9uG8YPdc8uA2EIsp++yeMW7H6jpQ?= =?us-ascii?q?XQQ8MG5c2VSKfLUr3mfSyChPxfZxJSnO2rZY9GLID/0lxvZh5hnYHSH0eDFd?= =?us-ascii?q?wYoyB9YEkzukoeuGMrT2Av1Ru2D2HM/CpKSKfkx0Zp01QkMqwn9GK1wngoP3?= =?us-ascii?q?vlrnEQylgRntDUm2iAXTKrK4GPUNl8JXLf9EMND8zUXCkkXwqxyB8BVlbEEp?= =?us-ascii?q?xLiL4yWWl3hV3gvsl0BPReQKZYMjsR3u3SRvl69VVHtmCaw1Ra7/DOE5pomV?= =?us-ascii?q?kOcIWw6lta0AJictNnQM6xbI5I1UQVvqWVon2M1/sthS8TI15f1GKJZGszpU?= =?us-ascii?q?YTPaMnLSf7m44N41mHiWVbJ0UiaLkOptRY5E4fAOmt9CL9ybxoGmqMON6gLP?= =?us-ascii?q?K9sFDbn8CpBUEB1WU5mnhnuuV56eQcLGuPTFFonJiXJ3FrVILuEwJrbNEDzm?= =?us-ascii?q?DZTwCInf7A8NFbGoewJLjWcc6TtP0Sp2mIHjsAE9Qg/+gmJriyiRHFLfq5a5?= =?us-ascii?q?UlzScWxA/PDw+7DqQsGnPDtQYopvmd7aR209ljPRZNGX5fIxySx6yLr1J2sa?= =?us-ascii?q?OYBopqY0cqc9QVOSdlEN3/mjReuWxHFiXyyO8C1Qyeuif1vT+DVWSuQ/lCQb?= =?us-ascii?q?K5expoFdiq+DI5rvfn20CCq8aWLjTgLt0nod/Gs75E9N6MXulZSbBtvkubgY?= =?us-ascii?q?RcTmynXz2HHYu6IpHxb88natmnQm3vCATm1WttFZqidLPPZqjdhADtSMNKvZ?= =?us-ascii?q?OA3TclZ8GnETRMFx5sqrMG6blnbAIOJps3MwX1vQYzPLDtPADLt7fmSWb4Bx?= =?us-ascii?q?dbQdNfweOdPJhv4XoSKb/m4msOR6AI9PaUw1QGdb1JlkDA6vqRQ4dfCX2gfx?= =?us-ascii?q?4VcVD+ojcDh21KO+ge2N5v8gLimEceIj6PXsc2NUAbp+kQIG+4PUtyJEwcaF?= =?us-ascii?q?2st6zCyAyDjusz7g1Mk/Fs3LdjgHr5jrK6AnqNZbaIi7KM7yYEafQ/hYRVMd?= =?us-ascii?q?DuAuC4jpSHrmTufsj74x/VUxOkUKNztcZNLCtpQfYUgVA0EpUnlaBjwhNyUs?= =?us-ascii?q?FvDbAIIsxO7uz1bAVEMykX9ik9cIGDhyMhjKSRy+rKiCy1f7owETwfjtZ+re?= =?us-ascii?q?Q+TDNtWzsmhLaOXdzGr0HVW2okP0Ahwg4L4SgEyNFvG4KtsI7rXc4S8AwLo9?= =?us-ascii?q?NkERHZRoRt52L+UGCwqgHyQtqeo/Tq4hpJ4fi9zuBDBSAkKEpdyd1xqkUvC5?= =?us-ascii?q?NIL4AOgonxqWCZVEGf3irtze+/D31j5OPSawOjBoHnm0vZQAIC6EI/ZYB9wk?= =?us-ascii?q?vHEq9LuThoaKMA9VVpGJD5Y2X7yzp+lp5YFaPmZeO0nHB9tCYWa0LIW9h9SN?= =?us-ascii?q?gz5QGfSHhkeZetsJL/J9BIT3RN/IHIrVpEjF9kN33x2d9dMcZL+jkWQH1Cuy?= =?us-ascii?q?+apo6UT8tOipIkI7olGPwm4imvQOdoPZGLqEc7sbv1xi2R42U6t1G3gH2rEL?= =?us-ascii?q?PtFroBuyUFAlAwOm2Eo08zDu0hti/b/lPMtwVuu69SHaCB2F816CxgF8V9Rn?= =?us-ascii?q?lM3HGhJklvTDxcvv1dMrjOW8NbRPY2aFmkPBlxUbZ/hxDZoB4qxTbMJyp1sA?= =?us-ascii?q?YAoXL0QhU0WC8Jg7zkhTwZrISdNCQHT45TN2V5PS7BLwTemCZduwtZZwRvHZ?= =?us-ascii?q?sYGd1Cvboc2Ngc5dLMHH6lMjpNRxl+LkQ92Ptbm1REtRCfYTvUEgXtf/HStB?= =?us-ascii?q?Z6Zu+QodKnavPj81QPkZvp5cY/8ahLXHi6gUutTNTZ+pf7rcGPv1CSeb3QNu?= =?us-ascii?q?S9ZTnAQSTCyxeqiuRsA5rL+n3LORFAY9lhyHUiaIT8E2ODIxlcJqwaKkYaHa?= =?us-ascii?q?B3YNlLuKZbMudldboHv6h3CUHPShDuHdmvpeNKIF/SQXyeJSKN46S/qJnTpb?= =?us-ascii?q?DcRaDmYdDE2XvdQqxmdqR06D/yH4KrmY9T80b7wLFso2t1TFHHN2aKq9Gybg?= =?us-ascii?q?8O7dOpI0Xrv5lhXSuDBpB2nTLhx1oVcc0RTmzi/MEXzZpY7DD7TuchiBrJve?= =?us-ascii?q?Zf9qdp5cwM2543kZ/mHa7JMrwauEtjBF2VAA9t65MhRW05TGFKaehXI/DUL+?= =?us-ascii?q?wVisXnqua/EKJyilXd/PRCYMTIYkvGh8+0Byq0SBFYkkEGszFSIgaH1vGDkr?= =?us-ascii?q?N5Uo7//bCgiBt8uwDsdUZeleI0vNXWoKHArfSyDVOZ1bUeX6n2Ws7/5q8hvU?= =?us-ascii?q?+f/7xslbIDfHB0fxzyFeEcUsAHwWKzqMJihSkoEs7FA/fh4KsZDypgzGuxw8?= =?us-ascii?q?gvRA1OQ6FNROjZp48N+wVw0/bUPdAXbK1Yz2+LERjhE7kIzmOt526SZmJkmR?= =?us-ascii?q?rJlRr3RDDWjhe+oClmTC/L19qmnFBSU+z9Al9JVjWmfEV/rTWEMRHAtdfrt+?= =?us-ascii?q?Iy9k58YQmG/Jqd0XCsPr9aBZi1I8SHKDY74VgQkZs6S8eH2I0HF5y6Othboz?= =?us-ascii?q?luK/DZ7W2siSpIpaxK0pHG7PaS/PHGThzCx+WK7q+AzzdCxj0krEkyv5q+Y+?= =?us-ascii?q?rW6YTAELy4knwcRCBlt07dUg6p//bF+ksMNxXusg+DmZRWbIgDmyNikBy2or?= =?us-ascii?q?BkGo579R0CRNicIapd/XaiaH2shgzDK9MvCnvClWAOWAukQR8jQu9mhweS9I?= =?us-ascii?q?rIjSuCoQV5ANMoJwq+1FouXt9/cx1l6UBLkHVZV1FTNlbCVuruXxy5SOlMHU?= =?us-ascii?q?kbN0bdhODjKP5njBUhm+n07b2BKrEiT6sVaKQH1lbXzgELS8pE6PdAS+AuPA?= =?us-ascii?q?IDkcyf7gn6Vdq9B6C/xyNhbaXnGZgCqJJB7yJ7sFTnAET8oZZbseRB1sjXJK?= =?us-ascii?q?AdPsCe7JgktxU+uGZXJH4Vx0Yj6nHxGaUVoOSpu4KJipej5+ewWapofN05rE?= =?us-ascii?q?FlVUJ5iZa4wFknpdeS1uFWTZDThcH6tgtMOHWN/o3d1ks0L+1GMI+tcLt6kh?= =?us-ascii?q?dPbyEDO3IDO8aXYPgg8mdsNjvU/VlLHsILY5sRIsPMnQlejkChVqtU84LXHV?= =?us-ascii?q?qRCoE7cM5NjSK/0Dcu7Z41Sfrt8hezLJHbqVBAI/0Fiz9j1ZrDqOUT3fvOGX?= =?us-ascii?q?0X7H2eOH0XimuJz5iADeq1/P3ZkomMDgFfT3ZuAdwFfGPQoFX1FLC+x/CLGk?= =?us-ascii?q?uO58T+gYwzbheZQni32aUDuKFRF+IFj2Pw3yNVEcb+gPfG1rjkoGZRqFBDF5?= =?us-ascii?q?5+qBPfH6AKdJJjIh3nmYyhQVV6DSbkUMDZahRov/CZjLRpga02Jw7laIkXLw?= =?us-ascii?q?hRgar98mZQRxByRaTeu1+YWaQQacdoDvTeoToGoZIlIKgJMl+HoZXspTods0?= =?us-ascii?q?g4NwgvbK5p/25qM3LWlQgQYJ7a/bsJiw8SS9l84BceGG+sNiQ5/TWVDP0I3p?= =?us-ascii?q?nUM+Qc93CodoJLU0hsNXojERa82ZEoera1k7ZAqGwUxi4=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A8HmAABdeXxafQAZASCDgISAEQAsXRo?= =?us-ascii?q?BAQEBAQIBAQEBCAEBAQGCe1NpYQQzCoNbiiR0jTKGA4YNjUeBVTkUGAEKhEm?= =?us-ascii?q?CeQcZBzQYAQEBAQEBAQEBAQEBAhABAQsUCFeCOAUCAxgICS8cKgMBAQEBAQE?= =?us-ascii?q?mAQEBAQEBAQEBAR8CKxMuAgQBASAdAQUKDBIMAgECAQIGAgUDBgEGMwQCAgM?= =?us-ascii?q?BHgEEDQEFATUFihcBAxYCAguRLpEdQIwXggUFARyDDAWDXwoZJw1ZWIF6AQE?= =?us-ascii?q?BBwEBAQEBGwIBBRKEaoIVgVeGX4FmAQECgjuCS4JlBYgDikmBFYZDigcJAow?= =?us-ascii?q?hg32FXJQ8Ao15iX8UBSCBFSE5gVFwFT0yghSCRhuCNFqLWoFzAQEB?= X-IPAS-Result: =?us-ascii?q?A8HmAABdeXxafQAZASCDgISAEQAsXRoBAQEBAQIBAQEBC?= =?us-ascii?q?AEBAQGCe1NpYQQzCoNbiiR0jTKGA4YNjUeBVTkUGAEKhEmCeQcZBzQYAQEBA?= =?us-ascii?q?QEBAQEBAQEBAhABAQsUCFeCOAUCAxgICS8cKgMBAQEBAQEmAQEBAQEBAQEBA?= =?us-ascii?q?R8CKxMuAgQBASAdAQUKDBIMAgECAQIGAgUDBgEGMwQCAgMBHgEEDQEFATUFi?= =?us-ascii?q?hcBAxYCAguRLpEdQIwXggUFARyDDAWDXwoZJw1ZWIF6AQEBBwEBAQEBGwIBB?= =?us-ascii?q?RKEaoIVgVeGX4FmAQECgjuCS4JlBYgDikmBFYZDigcJAowhg32FXJQ8Ao15i?= =?us-ascii?q?X8UBSCBFSE5gVFwFT0yghSCRhuCNFqLWoFzAQEB?= X-IronPort-AV: E=Sophos;i="5.46,479,1511827200"; d="scan'208,217";a="56743656" X-IronPort-Outbreak-Status: No, level 0, Unknown - Unknown Received: from mail.ietf.org ([IPv6:2001:1900:3001:11::2c]) by alln-inbound-m.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2018 16:26:13 +0000 Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 5348512D7E3; Thu, 8 Feb 2018 08:26:12 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ietf.org; s=ietf1; t=1518107172; bh=1IGwqIGb2H2yHomYr0yEd2oNWe0BF0C+cTU7GwG9Zok=; h=From:Date:To:Subject:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe; b=mz6p7EFW+LlNZzeJSeEShurjCXBUgZWk9LcPsbfI/zYkNYeYJ/5gPKW7Issy/8KnX DRkVks9RpbZNnDseY+FMjeZ0VTIuh3nMCDjUAd8DyDOPIv18uhU6/CHlZSHcLC2Vj8 MYGmPJISif8VsO8psJzQMIr4a54Y1s254iXXE7yg= X-Original-To: opsawg@ietfa.amsl.com Delivered-To: opsawg@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 80B7B126E3A for ; Thu, 8 Feb 2018 08:26:10 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.699 X-Spam-Level: X-Spam-Status: No, score=-2.699 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 07whIYVeqF6w for ; Thu, 8 Feb 2018 08:26:08 -0800 (PST) Received: from mail-oi0-x230.google.com (mail-oi0-x230.google.com [IPv6:2607:f8b0:4003:c06::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 9D662126B6E for ; Thu, 8 Feb 2018 08:26:08 -0800 (PST) Received: by mail-oi0-x230.google.com with SMTP id b3so3889763oib.11 for ; Thu, 08 Feb 2018 08:26:08 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=FDefBhdnO3LPF8V/84BxFaYZSwKZrcYD+p9vGdZLfi0=; b=YouRxmCefDrQ8ZyBAvjyflBC75D7pPDMTBtVlFNLGjXRNiBjG93IyNydOPe2NXjoXE IUrKJO14dLlDqNALh4eHCVRo1X0YZ9C9z8kUv/1AGvudaYig4pYyC1IDBJC1+ln9Bd/B 47mWHVomSnLOjk3wKf+Ex9xvSMgFzIHsV+TGWKwusQpPHqEb1xPF9yjGw/ZGb/mBl66w 8lKy96SZ5hIx+Rz8umxQmriNC1bbGWXp+WpsEb9tQ05V3IjhfSOTfoKJWlAvToSs7yIj hmlqCLZEFnt63bcJFIMzGvyWCHgZbRpoS1BZyhmC9hMPx7qKmDn29rYbr6XKw3N0q8xD jT+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=FDefBhdnO3LPF8V/84BxFaYZSwKZrcYD+p9vGdZLfi0=; b=esD3Qyfm1Emc+3H7vYCzyvEX0O6HIHsnzwyzxGz8q7WhZJ5tzkoQ7QE9I9oMvk9F+i 7xXtc7tHoDiB1ZTkZRnzN6zF0ISHCEf7MiaclCKj9RdFBtgHApi0j+hfmSGNNIm+/0IR yb/JRXkO80qyIbWQpngn3RqRIeHWFv4x0fKfWYooDOGVM43dn/xbWjTd2NmdqQ/XYssB nq2gIqtcoPFU0TBLGJbv8B9NK1TDQ9eQpyjxpYqzLC29DfvW+NRNcZ2A3gn7oEmTrJT9 V6+LEsDqOmtE8kinYOLwTCMlkJq9CPEdwouY/LfhKwbERPSjqwVIttu1sQlTcSiI6lVY RHPA== X-Gm-Message-State: APf1xPBnlRrIlfdMiqVuiunVfMes+bpCw88Mi4W99PhblaI1YCJTQnF6 y2thhez/bEH0ZPzeAnEcmrV7KXpLULFpclBiDGX/hg== X-Google-Smtp-Source: AH8x224apuPL9w/rPcQsCAytkhXdrePk/Nn+9f/GWREelpj6yG7eArqm0Xd3wddr0IE0do5YIp7jNlBalHo9qslr7DE= X-Received: by 10.202.59.197 with SMTP id i188mr822303oia.177.1518107167553; Thu, 08 Feb 2018 08:26:07 -0800 (PST) Received: by 10.157.36.201 with HTTP; Thu, 8 Feb 2018 08:25:26 -0800 (PST) From: "M. Ranganathan" Date: Thu, 8 Feb 2018 11:25:26 -0500 Message-ID: To: opsawg@ietf.org Archived-At: Subject: [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang X-BeenThere: opsawg@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: OPSA Working Group Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============8400993352781092970==" Errors-To: opsawg-bounces@ietf.org Sender: OPSAWG Return-Path: opsawg-bounces@ietf.org X-MS-Exchange-Organization-AuthSource: XCH-RTP-002.cisco.com X-MS-Exchange-Organization-AuthAs: Internal X-MS-Exchange-Organization-AuthMechanism: 10 X-MS-Exchange-Organization-Network-Message-Id: 1ee66636-39c3-4b4f-28a5-08d56f1150e0 X-MS-Exchange-Organization-AVStamp-Enterprise: 1.0 MIME-Version: 1.0 --===============8400993352781092970== Content-Type: multipart/alternative; boundary="001a113ccad873ff840564b5de9a" --001a113ccad873ff840564b5de9a Content-Type: text/plain; charset="UTF-8" In order to compile the published YANG model with OpenDaylight Yangtools I had to make the following change ( diff published file vs. changed file is below ): 583c583 < path "../../../../../../acl/name"; --- > path "/access-lists/acl/name"; 597c597 < path "../../../../../../../acl/aces/ace/name"; --- > path "/access-lists/acl/aces/ace/name"; I am not sure (don't have enough YANG experience) to know if the error is with Yangtools or with the published YANG model but I thought I'd send this information to the list just in case. Thank you for your attention. Regards, Ranga -- M. Ranganathan --001a113ccad873ff840564b5de9a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable In order to compile the published YANG model with OpenDaylig= ht Yangtools I had to make the following change ( diff published file vs. c= hanged file is below ):

583c583
<    =              pa= th "../../../../../../acl/name";
---
>   =             &nb= sp; path "/access-lists/acl/name";
597c597
<  =             &nb= sp;    path "../../../../../../../acl/aces/ace/name&quo= t;;
---
>         &nb= sp;         path "/access-list= s/acl/aces/ace/name";


I am not sure (don't have = enough YANG experience) to know if the error is with Yangtools or with the = published YANG model but I thought I'd send this information to the list ju= st in case.

Thank you for your attention.

Regards,

Ranga


-- =
<= div>
M. Ranganathan
--001a113ccad873ff840564b5de9a-- --===============8400993352781092970== Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ OPSAWG mailing list OPSAWG@ietf.org https://www.ietf.org/mailman/listinfo/opsawg --===============8400993352781092970==-- --------------CD648F72278884C5B5782626-- --IaOTFCBscT8Qp7FSpX4vd04BjbBW0KQJ1-- --gMidIJBmtaW1cKlk2rsi4FlMWamjskSC9 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlp8fAEACgkQh7ZrRtnS ejO8xAf/RCAyhvgJSmH3XswIOEA8gqb94aoUIgil/1dM9UwIItmdgTqVauFt5PYF 16YjXVXQvh5yxPnFZkcD7bjvSSSUF9TFRWv3CynydKPLAd6b6+62AHo5r6WK0sv7 xEFNk8RLRTU0HcxV4XQDZ09H85iTWC++n9RXy5fSlLl6lHURAY9An8N5Ib98ukU0 YFu2MEHNbqaK+tN8cCihT3dH+ZovKjd/3jFBphX+An2wD94dAkDDhaihLvupHsF8 L/bXzalZKTvC4ge3GUgqiDvAhn5OEmMZoZSqX8a5dnmVPt19xMSnKUso32VrsNDD sfKWDSyh/G7LJaMm3UW4HIWuaQjMrA== =4o5u -----END PGP SIGNATURE----- --gMidIJBmtaW1cKlk2rsi4FlMWamjskSC9-- From nobody Thu Feb 8 09:12:05 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9A420126E64 for ; Thu, 8 Feb 2018 09:12:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id euBbzcFas8Kl for ; Thu, 8 Feb 2018 09:12:02 -0800 (PST) Received: from mail-lf0-x22f.google.com (mail-lf0-x22f.google.com [IPv6:2a00:1450:4010:c07::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 92D0412D7FC for ; Thu, 8 Feb 2018 09:12:01 -0800 (PST) Received: by mail-lf0-x22f.google.com with SMTP id g72so7441729lfg.5 for ; Thu, 08 Feb 2018 09:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3IE5hBhBDLTEQNcMTByWxMtFj470Q1PWKEyN5uf4jfA=; b=m9NZ1jZpN680Fr2iSEVSce5nR1nd826tWSOu1gytqu8K3cjvSLMzZQmrfTGOPQkiKb yiF6U2RuotKrtFBZhoi5OD7QZIDK1WDqR4miVjTwRjidaRQ5MzDHMCWoplSmqnlnt3Xa uCiPcd0HHlxOr6Ir2FArCwRoN1fsFVBpKc1aPFNvZp3D1OqzkfvHa2j2iFSWW3G1Z3MF rRhHxERHD0aUNrgR0/F0I12UtTpfSh9BBA7FDApfqENV6mZ1oMgk861Bbc9b7wcMd9lA AfhsT6SO7CA454c2KGqZHY6hhdRUG3kxNsRPyjyDEVWXTad6ueMUp9G8Ac1iU3tIZosN AyFg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3IE5hBhBDLTEQNcMTByWxMtFj470Q1PWKEyN5uf4jfA=; b=eMA0z/TA8o2XPW0QTWyNdrTtcDCvTjdh+HgVaBjXejfg08yEzNu39G4BuAVBVWbfbF gp1FYDV70wj+DXbCqXDFV2/0LY72Q9c5sMfnHnTny7CLlDfnx6lL0JOFEaiP/0kM2qbz CBJNaKW1k0UyyjDdHKi1xc7aSZ+y9WKt3ZxWZXLHRnj0OWsS0+4Vyfuy+e93XiBipHLi moag1yNMVUTyMjxlOdPc/Rkv0bxkrNSE+4PaUB5Htw0WPGVfJ7rqx/vyQaeBmA1cNKzT oAMPCC9lA8PLVfeOrHmqsr9urKO8yQEzfhPjTyqi53cukVFrdjKSg6pZp+tQSD50ULy4 TVeA== X-Gm-Message-State: APf1xPCpkIWqJFlR7KCyZxAlorWYlAuG7CgsckgC1z5pFq51De7YcJ5x vS+ozQYIQK76sExWO8Vv+FG6yrSne/wceFRR/xRcUg== X-Google-Smtp-Source: AH8x225WRDWPohHpIfDdl4mmWtf4zYmmdF4+pA/ebgJBq8/krYAj2mdanvnMjStMwl3gSckro5/rPlEaj/cUL9hVI8Q= X-Received: by 10.46.23.84 with SMTP id l81mr937790lje.146.1518109919748; Thu, 08 Feb 2018 09:11:59 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.225.18 with HTTP; Thu, 8 Feb 2018 09:11:58 -0800 (PST) In-Reply-To: <20180208073617.yico4gvfrl6xdusw@elstar.local> References: <20180207.192803.834988416883038576.mbj@tail-f.com> <20180208073617.yico4gvfrl6xdusw@elstar.local> From: Andy Bierman Date: Thu, 8 Feb 2018 09:11:58 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf , NetMod WG Content-Type: multipart/alternative; boundary="94eb2c1a635e7f38da0564b68240" Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 17:12:04 -0000 --94eb2c1a635e7f38da0564b68240 Content-Type: text/plain; charset="UTF-8" On Wed, Feb 7, 2018 at 11:36 PM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Wed, Feb 07, 2018 at 03:03:49PM -0800, Andy Bierman wrote: > > > > > > > 2) The operation returns all values in use. > > > > The only way to suppress defaults is to use > > > > (e.g., request all origins except 'default') > > > > > > Or use with-defaults = trim. > > > > Yes -- because the definition in RFC 6243 is worded to exclude nodes. > > > > It should be clear in some draft how basic-mode applies to origin=default > > within . > > Frankly, carrying the different basic modes over to > sounds like a mistake. Complexity for no real value. > > API consistency is never a mistake. Special case treatment of 1 datastore sounds like a mistake. > > Applying sec 2 of 6243... > > > > config=true: > > > > If basic-mode=report-all then origin=default will never be present > > > > If basic-mode=trim then origin=default is only possible if the > value-in-use > > is the YANG default > > > > If basic-mode=explicit then origin=default is only possible if the > > configured value was not > > explicitly set by a client. Sec 2.3.1 is not clear if the YANG default > > value is relevant or not. > > It could be that if the configured value not explicitly set, then any > > value-in-use (not just the > > YANG default) could be tagged origin=default. > > > > > > config=false: > > > > report-all: default ignored, no nodes treated as default > > trim: node removed if value=YANG default > > explicit: all config=false nodes are set by the server, so no nodes > treated > > as default > > Who needs all this to manage a network? > > > This draft makes with-defaults mandatory-to-implement. > > It is a SHOULD implement now. (I approve!). > > > > The with-defaults capability MUST be advertised by the NMDA server, > > including > > the basic-mode parameter. The also-supported parameter MAY be included. > > > > Is it possible for report-all-tagged to apply to nodes that are learned > > (i.e., not origin=default)? > > So here is an alternate proposal: The NMDA documents are silent about > with-defaults and if someone wants to use with-defaults with > datastores then an update of RFC 6243 needs to be written. This way, > implementations can choose to not do any of the with-defaults magic. > > What we may consider, though, is to have a way to negate origin-filter > so that we can exclude specific origins - right now to emulate this > one has to (a) know all possible origins and then (b) list all origins > except the one not wanted. > > Then remove the text that says an error is sent if with-defaults attempted on . None of this new text needs to go into NMDA. It can be a vendor-specific mystery what gets set as origin=default. Implementors can read RFC 6243 and figure it out on their own. Sometimes default leafs might take up 50% or more of the retrieval response. Insisting that all clients always want this extra data seems overly simplistic. Assuming all networks are fast enough to ignore a 2X increase in data size for no benefit is not a good idea either. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --94eb2c1a635e7f38da0564b68240 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Wed, Feb 7, 2018 at 11:36 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Wed, Feb 07, 2018 at 03:03:49PM -0800, Andy Bierm= an wrote:
> >
> > > 2) The <get-data> operation returns all values in use.=
> > >=C2=A0 =C2=A0 =C2=A0The only way to suppress defaults is to u= se <origin-filter>
> > >=C2=A0 =C2=A0 =C2=A0(e.g., request all origins except 'de= fault')
> >
> > Or use with-defaults =3D trim.
>
> Yes -- because the definition in RFC 6243 is worded to exclude nodes.<= br> >
> It should be clear in some draft how basic-mode applies to origin=3Dde= fault
> within <operational>.

Frankly, carrying the different basic modes over to <operational>
sounds like a mistake. Complexity for no real value.



API consistency is neve= r a mistake.
Special case treatment of 1 datastore sounds like a = mistake.
=C2=A0
> Applying sec 2 of 6243...
>
> config=3Dtrue:
>
> If basic-mode=3Dreport-all then origin=3Ddefault will never be present=
>
> If basic-mode=3Dtrim then origin=3Ddefault is only possible if the val= ue-in-use
> is the YANG default
>
> If basic-mode=3Dexplicit then origin=3Ddefault is only possible if the=
> configured value was not
> explicitly set by a client.=C2=A0 Sec 2.3.1 is not clear if the YANG d= efault
> value is relevant or not.
> It could be that if the configured value not explicitly set, then any<= br> > value-in-use (not just the
> YANG default) could be tagged origin=3Ddefault.
>
>
> config=3Dfalse:
>
> report-all: default ignored, no nodes treated as default
> trim: node removed if value=3DYANG default
> explicit: all config=3Dfalse nodes are set by the server, so no nodes = treated
> as default

Who needs all this to manage a network?
=C2=A0
=C2=A0
> This draft makes with-defaults mandatory-to-implement.
> It is a SHOULD implement now.=C2=A0 (I approve!).
>
> The with-defaults capability MUST be advertised by the NMDA server, > including
> the basic-mode parameter. The also-supported parameter MAY be included= .
>
> Is it possible for report-all-tagged to apply to nodes that are learne= d
> (i.e., not origin=3Ddefault)?

So here is an alternate proposal: The NMDA documents are silent about
with-defaults and if someone wants to use with-defaults with
datastores then an update of RFC 6243 needs to be written. This way,
implementations can choose to not do any of the with-defaults magic.

What we may consider, though, is to have a way to negate origin-filter
so that we can exclude specific origins - right now to emulate this
one has to (a) know all possible origins and then (b) list all origins
except the one not wanted.


Then remove the text that says an error is sent if w= ith-defaults attempted on <operational>.
None of this new t= ext needs to go into NMDA. It can be a vendor-specific
mystery wh= at gets set as origin=3Ddefault.=C2=A0 Implementors can read RFC 6243
=
and figure it out on their own.

Sometimes def= ault leafs might take up 50% or more of the retrieval response.
I= nsisting that all clients always want this extra data seems overly simplist= ic.
Assuming all networks are fast enough to ignore a 2X increase= in data size for no benefit
is not a good idea either.



=C2=A0
/js


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

--94eb2c1a635e7f38da0564b68240-- From nobody Thu Feb 8 09:55:58 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF894126E64 for ; Thu, 8 Feb 2018 09:55:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lM6NfREDLS65 for ; Thu, 8 Feb 2018 09:55:51 -0800 (PST) Received: from mail-lf0-x230.google.com (mail-lf0-x230.google.com [IPv6:2a00:1450:4010:c07::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 6FCC5126C2F for ; Thu, 8 Feb 2018 09:55:50 -0800 (PST) Received: by mail-lf0-x230.google.com with SMTP id g72so7625298lfg.5 for ; Thu, 08 Feb 2018 09:55:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=eYxBUaZtKNVkVIBZ2PwT/O9mc4V4uQhRi6U4FJYNQBI=; b=yRXGU1CF0UUCrv1mqmx+nZM99PkCVoQnBBZjthPmkYIEaDK0xy0wRwjcZ2Pe6op8xA 31mgVlmMBKjQcwi+wN0fGkyAiEa+7z/HgwKX61kIBH0Zq89I78KUNp3UePwnCNzlQ3Wr nJfOdZDc96aei1s5tcyAyjujRFgUizacwbqvUkLhTqathDAGkOfRA0paHf5Tc6D0Qrg3 I2R3WgaoMZaigi7bMc9o8AwxGn/jfQMfM+HN6FG+B7lQFnzl1OFCtZBjjA25WTqsad04 eCCQI4HL2YZ+eL+4MHUekJTKfHk2NcXU1x7LIWF7PGqxbA/9KXVq6uW27mr/EKmKBLZp qXBQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=eYxBUaZtKNVkVIBZ2PwT/O9mc4V4uQhRi6U4FJYNQBI=; b=ju2P/6JijrULctFINRcc7hIAKsxNEXD0PJWuVUHSvIWXhaf7BNIUWhd9WWM/D0USML JECLHcYkNixuoZYSIie5a2n1MPhy9YGQw9q4JSsRNzaXPIG7IGCW4iUplqeE4Vocmx3o qmtPfiFfLWQGcOeZtg2iGq9aHWFw3EveW2Ke62MXcJYItmD7s5qE6P2CHd4pOLplSfEJ L3NpWIKhrlWdjX0hacYqWOf6STW9Em8x1UwePaQZSQVCl9lbr36iz1Vp7B/1wWmtJBS0 NuJWPqOrreo0T7tZfObUaMGaVD/O36sgJyB83ENX4BeYuurbmrf57Iwk53mBvwSMyOLw 1dow== X-Gm-Message-State: APf1xPDSDB6CR5LXs/OCtxEvTsyHbaoSUt7vH2ZhWJUDBgA7LxO1gEWS 2qMB3Jb5dkO5FLfpffy18+grGUxJbEURt/DqCSnL0Q== X-Google-Smtp-Source: AH8x2243eGxtEGo4tDbY6TV2h1qDuRRxHwdbA1+M8spdrHfBUfrLiQQyZBslvrtJfx2mwvBgjg+qYNQdxOsfQ0EHApE= X-Received: by 10.25.20.168 with SMTP id 40mr4964lfu.23.1518112548674; Thu, 08 Feb 2018 09:55:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.225.18 with HTTP; Thu, 8 Feb 2018 09:55:47 -0800 (PST) In-Reply-To: <20180208073617.yico4gvfrl6xdusw@elstar.local> References: <20180207.192803.834988416883038576.mbj@tail-f.com> <20180208073617.yico4gvfrl6xdusw@elstar.local> From: Andy Bierman Date: Thu, 8 Feb 2018 09:55:47 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf , NetMod WG Content-Type: multipart/alternative; boundary="001a113fb11831b2a60564b71f17" Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 17:55:54 -0000 --001a113fb11831b2a60564b71f17 Content-Type: text/plain; charset="UTF-8" > .... > Who needs all this to manage a network? > > I sometimes get comments from people about NETCONF defaults, like "You think this is a standard? Why does a vendor get to decide what is a default leaf?" CoMI has taken a different approach. Every server MUST implement "trim" mode and nothing else. NETCONF should do the same (but won't) Andy > > This draft makes with-defaults mandatory-to-implement. > > It is a SHOULD implement now. (I approve!). > > > > The with-defaults capability MUST be advertised by the NMDA server, > > including > > the basic-mode parameter. The also-supported parameter MAY be included. > > > > Is it possible for report-all-tagged to apply to nodes that are learned > > (i.e., not origin=default)? > > So here is an alternate proposal: The NMDA documents are silent about > with-defaults and if someone wants to use with-defaults with > datastores then an update of RFC 6243 needs to be written. This way, > implementations can choose to not do any of the with-defaults magic. > > What we may consider, though, is to have a way to negate origin-filter > so that we can exclude specific origins - right now to emulate this > one has to (a) know all possible origins and then (b) list all origins > except the one not wanted. > > /js > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a113fb11831b2a60564b71f17 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

=
....
Who needs all this to manage a network?



I sometimes get comment= s from people about NETCONF defaults, like
"You think this i= s a standard? Why does a vendor get to decide what
is a default l= eaf?"

CoMI has taken a different approach.
Every server MUST implement "trim" mode and nothing else.=
NETCONF should do the same (but won't)

<= div>
Andy

=C2=A0
> This draft makes with-defaults mandatory-to-implement.
> It is a SHOULD implement now.=C2=A0 (I approve!).
>
> The with-defaults capability MUST be advertised by the NMDA server, > including
> the basic-mode parameter. The also-supported parameter MAY be included= .
>
> Is it possible for report-all-tagged to apply to nodes that are learne= d
> (i.e., not origin=3Ddefault)?

So here is an alternate proposal: The NMDA documents are silent about
with-defaults and if someone wants to use with-defaults with
datastores then an update of RFC 6243 needs to be written. This way,
implementations can choose to not do any of the with-defaults magic.

What we may consider, though, is to have a way to negate origin-filter
so that we can exclude specific origins - right now to emulate this
one has to (a) know all possible origins and then (b) list all origins
except the one not wanted.

/js

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

--001a113fb11831b2a60564b71f17-- From nobody Thu Feb 8 10:02:11 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B2EF112D7E9; Thu, 8 Feb 2018 10:02:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2dIpOPPvRNR4; Thu, 8 Feb 2018 10:02:08 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 1EBE51242F7; Thu, 8 Feb 2018 10:02:08 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w18I0fQK003391; Thu, 8 Feb 2018 10:02:06 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=message-id : from : to : cc : subject : in-reply-to : mime-version : content-type : content-id : date; s=PPS1017; bh=DH/l7qgrZhqYx1PYGQlbVz36gjYibAyLh88dW2L58IE=; b=y32i4lEEGDcNk1bMHXxrd9FmH3tEwABydtAaZN4sLFtIZQBON5NPtmvEDojANqA9ubif tp0suAjchcu1El0vVQFdwTW76CJ0QYgqUakKd/cko7CGniTCvtiYlWX2GWhUTN6btiaX 82F8rhXgLhkjGYRCskIuYOy29dwT9rYa9ExmK82SwuWd4+mDFLLjSkd5H+/uzzFuXXoy ORNZ1NsSqgTNKj5sLZ0k8qjj3QCJHbCRw2DWvwSNqNJMUTSmFR2qPP6Tt+z4MbsQdgid DNTs7F+9skWUIJ4FnRM6MOi5aZaalvKvQ2vObairs75Esuy8AR2ArS0+RAjM0L3/t9zk LQ== Received: from nam03-co1-obe.outbound.protection.outlook.com (mail-co1nam03lp0018.outbound.protection.outlook.com [216.32.181.18]) by mx0a-00273201.pphosted.com with ESMTP id 2g0uevg06r-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Feb 2018 10:02:02 -0800 Received: from BLUPR05CA0054.namprd05.prod.outlook.com (10.141.20.24) by CY4PR05MB3016.namprd05.prod.outlook.com (10.169.184.137) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Thu, 8 Feb 2018 18:02:00 +0000 Received: from DM3NAM05FT005.eop-nam05.prod.protection.outlook.com (2a01:111:f400:7e51::208) by BLUPR05CA0054.outlook.office365.com (2a01:111:e400:855::24) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.506.7 via Frontend Transport; Thu, 8 Feb 2018 18:02:00 +0000 Received-SPF: SoftFail (protection.outlook.com: domain of transitioning juniper.net discourages use of 66.129.239.15 as permitted sender) Received: from P-EMFE01C-SAC.jnpr.net (66.129.239.15) by DM3NAM05FT005.mail.protection.outlook.com (10.152.98.110) with Microsoft SMTP Server (version=TLS1_0, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA_P384) id 15.20.506.9 via Frontend Transport; Thu, 8 Feb 2018 18:01:59 +0000 Received: from p-mailhub01.juniper.net (10.47.226.20) by P-EMFE01C-SAC.jnpr.net (172.24.192.21) with Microsoft SMTP Server (TLS) id 14.3.123.3; Thu, 8 Feb 2018 10:01:31 -0800 Received: from idle.juniper.net (idleski.juniper.net [172.25.4.26]) by p-mailhub01.juniper.net (8.14.4/8.11.3) with ESMTP id w18I1Ua9014087; Thu, 8 Feb 2018 10:01:30 -0800 (envelope-from phil@juniper.net) Received: from idle.juniper.net (localhost [127.0.0.1]) by idle.juniper.net (8.15.2/8.15.2) with ESMTP id w18I1ZQg082394; Thu, 8 Feb 2018 13:01:36 -0500 (EST) (envelope-from phil@juniper.net) Message-ID: <201802081801.w18I1ZQg082394@idle.juniper.net> From: Phil Shafer To: Juergen Schoenwaelder CC: Andy Bierman , Netconf , NetMod WG In-Reply-To: <20180208073617.yico4gvfrl6xdusw@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <82392.1518112895.1@idle.juniper.net> Date: Thu, 8 Feb 2018 13:01:35 -0500 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-HT: Tenant X-Forefront-Antispam-Report: CIP:66.129.239.15; IPV:NLI; CTRY:US; EFV:NLI; SFV:NSPM; SFS:(10019020)(376002)(346002)(39860400002)(396003)(39380400002)(2980300002)(189003)(199004)(16586007)(26005)(5660300001)(478600001)(54906003)(47776003)(7696005)(81166006)(336011)(46406003)(81156014)(53936002)(229853002)(186003)(8676002)(8936002)(69596002)(316002)(77096007)(105596002)(23726003)(68736007)(1076002)(2950100002)(106466001)(6916009)(356003)(2906002)(2810700001)(86362001)(97736004)(53416004)(7126002)(76506005)(6246003)(97756001)(4326008)(558084003)(50466002)(8276002)(305945005); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR05MB3016; H:P-EMFE01C-SAC.jnpr.net; FPR:; SPF:SoftFail; PTR:InfoDomainNonexistent; MX:1; A:1; LANG:en; X-Microsoft-Exchange-Diagnostics: 1; DM3NAM05FT005; 1:FtavbXklDEQLOibSVVbzNRgQaP9hX87LFqcXZuWWIaEZ0ssXTELX/xQ3YfmLKtJMlrp3g7kdxqa0Sr2fbBZxNZ5ZVUWSEUdH9X6BHGlYw4A6wdZQS43G1POzeNVPuaVH X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: d3089760-30c7-4933-8b26-08d56f1e0cf8 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(2017052603307)(7153060); SRVR:CY4PR05MB3016; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3016; 3:eIC99zfbIn3+VWHc+IHiqDyVBzUt8NNj62KqYglPanYox8+pI0P5HB6JFfLku+if6XYQgSyoXFf7vUp5VmxXX5nXBAhcZzBCzaVA/C09jI1M1lxCke6NqRDzZfPPNAQJe/v1wHAAoy//vRvuOBiBOCBfiX5/O5UzYnbLgSNV4h182fTr/VCb956vPzVIF0hRq695QQFNAn8b3HXxmP0z2M6XhcDWQmHyzYSdQqwKMuoMyg8QhuQtg6HZHMs8EohjJeTzNcbvnY386WD5bUzKFV5OX5ViOkCqtghldkWqbJ/v0wE5v0ryFRUjp83rk9dwQ6CToIzo8m26W1GLwvARzXfMcEO4+d7+J1zFZ6nUEc8=; 25:mTO2/saoqj5IdavjXmgK4azim7WMX6z/BKbM35n6VwOFd3IUTfWudTXcEUI85ATX4OjGfMpt8muCMDjl5nAUPcHLELtJlL3VeFbaiedh55bgBGN7Z3OJIWZa3AY7d4oT9rf6b07R1Z9zg95QG3yzNMdhoHff2OYzZ7gh1mqj533Z6nHqrtue5ctiYXQK91HLRapvAd+XdXpvI49jOBM0cwrhk9693aa/VoW3pNLbw7JNXDSIrZeeHw+Z2YtPsAkyl+x+FMr0OQ0Q9euaB9enxle8ppzLjT7x1DD5lv+Dnl2Bz2AUIg/FL9Ay6jkTHLtXuVxzlElxBXymR2X3/6JQIg== X-MS-TrafficTypeDiagnostic: CY4PR05MB3016: X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3016; 31:b/BhuI4kpoK3II+JvkvBY6L2fQXttXLLPuVh5KyLBgavhujlsuM6N/a1SH6L2dmv07NMCwaLYex5A1jz4ierjWruA9TFHOGubm0mBuDiBxzD5epYhkUOYpsPR88E7GuPk3KVaJ822nLSRItbkmjbjLRfhkgP7EVVaADenbQKWT7TGKHTHj3Tc2VBwFQjctqTN8qaMJ2Pt/a3BHBXilduKjq1C/3djlOx2aICYYcwzlQ=; 20:GtZZG2xyOUfd6lLB8l6ujFupqBrzikG1BLlCon/UB9WRX55MubL8HKEGGFu6wywERBP5WftXBkaQp2poZV80TOd9qScvCDutDVxu7Wwkwq9rSCrC3Qsz6g+9U0omVSWM8H/oJEaQGMn27TzcM0xUI80ktqZefCkOzMYX9FDZSe4McHDRomm/iKQUrM9ZWC/Vm/9ylp0mVZGcDO/aYP3VdlrNjaiI8zay9zo9lvD6hfHezWc7Ik/Za35vyLKN32id9LZrMBRMdQsvjovfj3vIN/ll90Bq1mmuTjSI/NQ1yKPLjQI2kn/lEfa+lImsM3uS3zbCnGK6NnQ9OFWdZDyzQB7sqwz1lyamfwEYuwZYhEp8pJ47j2Bu1qhy+NNOHcweQD7scOe4EZ0C8k9Eu+iX+jWwNDlGF1UQaVBLl0BGVvXFJDQFE9fNdFJuOBkq3sqLNE7y0aXGG8o9ETiMeONcc4RPywC6l7Vm8chjIauLglDXJgT8+U1E15j1pOdsXCul X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123564045)(20161123562045)(20161123560045)(6072148)(201708071742011); SRVR:CY4PR05MB3016; BCL:0; PCL:0; RULEID:; SRVR:CY4PR05MB3016; X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3016; 4:MqI1ZPspZDFrfFcUuCgtCmpPRH+hrQabPDvPXlNROTO9Im3ysdACKw8v3BwiO18DrO+EBBSaapIWTgSPoFIEWGyhLILN2cvON7sfzGSrgrBn03SZ3JhVc8rNeiQE1IHc42Hi/6++5vvg4G81TTJULhdSS2kMSgUUIZTnOquoTRMYRFr+Aw9ZMRdvL/0Ycm5nQ9emWruHJ08ZqpbCjZbDcMJcKPIWoHklur0AJj3JHBTfcmP2foG8fTA91ti8cg5Rv9SV2fBEfQWRORg2HbNxCg== X-Forefront-PRVS: 0577AD41D6 X-Microsoft-Exchange-Diagnostics: =?us-ascii?Q?1; CY4PR05MB3016; 23:4SCVITzCULMDS5EyI1KlozFwNptGYKv9CjPkKdE4E?= =?us-ascii?Q?kPbO/hYlJaRNWzu1C4HrFGtrgqN8xktpKXIqcYj5SuP9gVffT6SJmZKyC4vb?= =?us-ascii?Q?NIcvTrXS1GD4oC/wzt1OPWWaI6GGDOJS04U0tAWopd6FnNsZTdLB+F3Hs/Wf?= =?us-ascii?Q?uriW3l+i8B2NnK3vqCsLZyDbNkHUiui8R8pXNP8SwW98LAXfflYM5LnKwQWc?= =?us-ascii?Q?AotDY+EGIXSlcZvgn29POVU59zlFppvhOluSNs+nvmKBKAqzSH4hxn3j5OA5?= =?us-ascii?Q?kjyQSHgdGaZ6VOu0EtBpYWBBZByu0zF0b7XuKEO8ZuUg/hA8zoUO8C/diRH3?= =?us-ascii?Q?88CI6PhD1dJLU3k8f6SMhvRfkzuBlatDx+TsaenAOduCUN+qfptwZiUjPv4p?= =?us-ascii?Q?eldT/dJbaK4wqGIBoTTjR8TryH0Yv3ecveABNV3AyIfX21KG1cZXJr0bLOEU?= =?us-ascii?Q?f/2VB+RVeszyvpzb74NlPCNKO391EujXrqH2M5cMlILbZ9GH57vKrw0OwJAD?= =?us-ascii?Q?VtCjpNQTYqCt/2G3ya3Nb110SvcYgQM4Db1Iy6sz3wd/5V3cpukjIXMYeg1m?= =?us-ascii?Q?DLinxeE0NjXVoT0urnNcnByY+bPf70M4UOnnrtVNg9xD3zKbcJ8tyTr6K8n/?= =?us-ascii?Q?5ew97g/OUqs92SMoB3vE4rHIPhqSV3HrAOWLWNZ0rLTIGUjInc99gFzh5eS7?= =?us-ascii?Q?lwwt5AdM7jn+jsP5yqsecquxIwm2gM4MF6Fg3J0MfanHgfcD94Z/HCoS8LkA?= =?us-ascii?Q?TXJvqvulwdbQy8lrURNV2HPZKY57IndRs3ZtWMhbx5CGNCC74BIIq3CtwaRN?= =?us-ascii?Q?pT3X4pKO+vRcWwfdIwlAGmY9E7s3B9uJ7VRhETpM2r1psaD5IGGT8aDMMUBT?= =?us-ascii?Q?Ugtv5i5oId31aFXu9r7VjJt7jsjH6IOccBQlyqki5ru2Eft1MmlXYOruVH+m?= =?us-ascii?Q?NyzE7P+bV8je1ZZwWmgyr6myJSkEFL2/c0Y3t70GhXbSdZi66oz7hM0+6j1b?= =?us-ascii?Q?BFOe0l2ihbE/Df1elWC45M8hSnXztlF9K5vakfPM8jUDh1ok+gSmZpuR2UHB?= =?us-ascii?Q?xw442mMFt0WFiqkEEuXFg8ewB9hNRYf1CW1A0cKICcuEQs3VDtyvTA+NDnOT?= =?us-ascii?Q?pcnufCwBE6sKwDBqcDHRNKajH+FhIZs?= X-Microsoft-Exchange-Diagnostics: 1; CY4PR05MB3016; 6:Az3zQYB61i4swE+SZFJrOs0jAFPOTU6Pp/u/gMeD/lUhQPWKqfjfkyp6AX8Sr/CXcM8MQeviFfcdqSCkIqCegpitL8ODG0kLRHJtOMZ1lm5GDb5yYpoCmgMIHzWlj0Ie7Ay5KMbehsz3tw+GUoHYC4L5jaPlmm762fcc55XbP0DeIsfzCI3lKx0Af5p0S+bHi9JwgIHDLMX+EW6U1coeEYj12YFUtEvqT+3CqnSOza9/0cIfR2/ebSF1PDrJoaIt2wb1+AvT3IMtoLrq1Yl2zouv8jMf/TNEyrpRF1bfanmXAAri6RcghpbpTWjiMRRWaSNEt33sxQw8Dc0kvcVHadOpWqo2Bx9TXhSpqru+/1w=; 5:XdQdCdeyAJbT0SBgEcyQjpwpGY3oNBi5g4dvc80KogS91VFvy5jXrnwWk0DrN4khvuOdRF+WszTQFzI2tWKLDvoln7aAU618CnXES0EKiYK+VcpQtLTr2Z99Lar1AWrBsf2DMH5qXy8ZFfFm75QkI8oUdeQg8Ba1V4qWRWD5ssc=; 24:xHBjFkTwVrmCp4wL41q1U/gzTJGJNWBpcy1QjrxSNQxhIyKWD9qs9L5Q5S3dg6OIyKsil0l7qNbu3tFjwNDCyF+ur7d9UOScoKK4AkfSWS8=; 7:4QQUQF538pI7J7jzuz0eXbRjEh4FrTrfA9Bsog/WcmlgVz3bNxscCxKyTh0uVgqiZRS8AjvooweioE8iFEaUks2ltBbm3IKfSI/DQaWvUskWGW66RXw4kWhvvkjsqjD4066tcmIY/CDx2OHGnRvOmLj9hoFWjK/yAsXwFg4+ypGS+pXsDgVhZcEM7njqr34pMdkfKYJ8f+tMaoZwQX+5jkxjhKxiDAuEhvMS/s2JxOrp69BuDmgrDlEVLX26YPay SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-OriginalArrivalTime: 08 Feb 2018 18:01:59.6047 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: d3089760-30c7-4933-8b26-08d56f1e0cf8 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.15]; Helo=[P-EMFE01C-SAC.jnpr.net] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR05MB3016 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-08_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=1 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=601 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802080208 Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:02:10 -0000 Juergen Schoenwaelder writes: >Frankly, carrying the different basic modes over to >sounds like a mistake. Complexity for no real value. +1 Thanks, Phil From nobody Thu Feb 8 10:40:40 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51B0312D7EB; Thu, 8 Feb 2018 10:40:34 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id APyLC4XmCMYn; Thu, 8 Feb 2018 10:40:32 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8E9ED1242F7; Thu, 8 Feb 2018 10:40:32 -0800 (PST) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 4E62A1AE046C; Thu, 8 Feb 2018 19:40:31 +0100 (CET) Date: Thu, 08 Feb 2018 19:40:31 +0100 (CET) Message-Id: <20180208.194031.269741945590474706.mbj@tail-f.com> To: andy@yumaworks.com Cc: rwilton@cisco.com, netconf@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180207.192803.834988416883038576.mbj@tail-f.com> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:40:34 -0000 Andy Bierman wrote: > It should be clear in some draft how basic-mode applies to origin=default > within . > > Applying sec 2 of 6243... > > config=true: > > If basic-mode=report-all then origin=default will never be present Note that origin=default can be used for more than just static YANG "default" statement defaults. But then RFC 6243 talks about "schema defaults", and presumably this includes dynamic defaults, even if they are defined in prose in a description statement. So I think your statement above is correct, since the default value is present even in and . > If basic-mode=trim then origin=default is only possible if the value-in-use > is the YANG default Yes, for the same reason as above. > If basic-mode=explicit then origin=default is only possible if the > configured value was not > explicitly set by a client. Yes. > Sec 2.3.1 is not clear if the YANG default > value is relevant or not. > It could be that if the configured value not explicitly set, then any > value-in-use (not just the > YANG default) could be tagged origin=default. Yes I think so, as per above. > config=false: Note that the origin annotation is not present on config false nodes. > report-all: default ignored, no nodes treated as default Yes. > trim: node removed if value=YANG default Yes. > explicit: all config=false nodes are set by the server, so no nodes treated > as default Yes. > This draft makes with-defaults mandatory-to-implement. > It is a SHOULD implement now. (I approve!). But is this what the WG wants? (side note; it would be good with a "if-module-implemented" statement, similar to if-feature. as it is today, if we want with-defaults to be optional we'd have to define an additional feature, which really is unnecessary) > The with-defaults capability MUST be advertised by the NMDA server, > including > the basic-mode parameter. The also-supported parameter MAY be included. > > Is it possible for report-all-tagged to apply to nodes that are learned > (i.e., not origin=default)? No, I think that if report-all-tagged is requested, you'd get both the "default" attribute and origin=default together. /martin From nobody Thu Feb 8 10:44:55 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9F4212D853; Thu, 8 Feb 2018 10:44:52 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Vkfgd0--08Qv; Thu, 8 Feb 2018 10:44:51 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 9CCE212D7EB; Thu, 8 Feb 2018 10:44:51 -0800 (PST) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id E0BD11AE046C; Thu, 8 Feb 2018 19:44:50 +0100 (CET) Date: Thu, 08 Feb 2018 19:44:50 +0100 (CET) Message-Id: <20180208.194450.2134836545832699765.mbj@tail-f.com> To: j.schoenwaelder@jacobs-university.de Cc: andy@yumaworks.com, netconf@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: <20180208073617.yico4gvfrl6xdusw@elstar.local> References: <20180207.192803.834988416883038576.mbj@tail-f.com> <20180208073617.yico4gvfrl6xdusw@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:44:53 -0000 Hi, Juergen Schoenwaelder wrote: > What we may consider, though, is to have a way to negate origin-filter > so that we can exclude specific origins - right now to emulate this > one has to (a) know all possible origins and then (b) list all origins > except the one not wanted. leaf-list include-origin-filter { ... } leaf-list exclude-origin-filter { ... } Or we have a single leaf origin-filter which is a boolean expression with origin values. Just like if-feature. (not default) and (not learned) but maybe this is overkill... /martin From nobody Thu Feb 8 10:45:09 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB0E712DA18; Thu, 8 Feb 2018 10:44:58 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K1DQ3w6kzKYu; Thu, 8 Feb 2018 10:44:56 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2C62D12DA0D; Thu, 8 Feb 2018 10:44:56 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id F06F2A24; Thu, 8 Feb 2018 19:44:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id YiIs4gK2V-jr; Thu, 8 Feb 2018 19:44:54 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 8 Feb 2018 19:44:54 +0100 (CET) Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id D71602014E; Thu, 8 Feb 2018 19:44:54 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id bUsJtrrttB-S; Thu, 8 Feb 2018 19:44:54 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CA152014B; Thu, 8 Feb 2018 19:44:54 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id F0BFE423E949; Thu, 8 Feb 2018 19:44:53 +0100 (CET) Date: Thu, 8 Feb 2018 19:44:53 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Martin Bjorklund , Netconf , NetMod WG Message-ID: <20180208184453.m4j7scytf3lmqkvd@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , NetMod WG References: <20180207.192803.834988416883038576.mbj@tail-f.com> <20180208073617.yico4gvfrl6xdusw@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:44:59 -0000 On Thu, Feb 08, 2018 at 09:11:58AM -0800, Andy Bierman wrote: > > > Then remove the text that says an error is sent if with-defaults attempted > on . > None of this new text needs to go into NMDA. It can be a vendor-specific > mystery what gets set as origin=default. Implementors can read RFC 6243 > and figure it out on their own. As I said, I am absolutely fine with the option of being silent about with-defaults and if needed someone can spin an update of RFC 6243. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 8 10:56:00 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35E1E12D810 for ; Thu, 8 Feb 2018 10:55:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nl-wblCTGJRq for ; Thu, 8 Feb 2018 10:55:56 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 243B9126E3A for ; Thu, 8 Feb 2018 10:55:56 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id f137so7854232lfe.4 for ; Thu, 08 Feb 2018 10:55:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3UzjH1ceDokXRfxn0lX0Z0Gz2cQdhoceGA1vS5kGyXM=; b=J2uGrayIwO4jvB+larBW7TPpKgHheEJZuYSGmc2byjKM3YOeCtUq2pO1I90yIIrV85 boKXvtmPY8H2JvRx8fAuPoNGmgMS3r/xAdx/uj/LB2QTkDVH6uHVmXZWZonr+wa69S4L L79rwq90FttAgqwh/OEP8OdIzYDWvcQzdjocYUdBq9DWsOR0RAiciCCOp2GRp/qDEVRG keTt06LfH25Nv5wALoIJplYa7XQhLrme3giuSZ043GRBn+0hJ5o5b5hdviEETOnkhN0K aFuFJiLpVKAZYpCmt+SKOYNT5yP5nPBCn4q2DQPPUmeRczphxC7aluicevBZ/SdG7GC6 +QjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3UzjH1ceDokXRfxn0lX0Z0Gz2cQdhoceGA1vS5kGyXM=; b=F+9EuiHZCfDIpHNzTbgoBZARN6TGvegrlcrCOKji302sI4XDik9K1GMbryrGbnaio/ YDngwQOAF7P5ycA1MnYPEJv7D1Ap9q5A0RDCKhO9lJN9qzxRrvunOl0Hzyhh0wmUYkNM UGGBDhfzM1kMOSACDKC4xcLlw4uHwc/j311MwHu7oPIVBtMVv8+B7KiDwIDbiODvk+7G ebFt3uIz2h8uPcju25O7C8c4pIavLT62i2CPHjuEHUvbPKOaaN0U5F1t9YGRjKQGsLSr pQ+M5lD6HchvU6+tMwa9xOI6dQMBqOWYmj1vcqwFU9MumZAGOaKPI/S1DgRm86NrpOm9 oohg== X-Gm-Message-State: APf1xPAQ1WbZUvI02+JojX7l1cUE7LIIdSP0QfPKOHrD2yPm9COZnovE TCkeleTORQLHn6PtaqMPFxMR1MqRnEJuUSSQAWgJeA== X-Google-Smtp-Source: AH8x2269LIBeBuIRVWOBcJ7ldcGQ0yeTOUKN/zb8/tRMgkHwMlzt+fVqau4kMwrbpC07Ti3ho3E4rObJDdJDhcOowMI= X-Received: by 10.25.26.200 with SMTP id a191mr102027lfa.35.1518116154304; Thu, 08 Feb 2018 10:55:54 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.225.18 with HTTP; Thu, 8 Feb 2018 10:55:53 -0800 (PST) In-Reply-To: <20180208184453.m4j7scytf3lmqkvd@elstar.local> References: <20180207.192803.834988416883038576.mbj@tail-f.com> <20180208073617.yico4gvfrl6xdusw@elstar.local> <20180208184453.m4j7scytf3lmqkvd@elstar.local> From: Andy Bierman Date: Thu, 8 Feb 2018 10:55:53 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf , NetMod WG Content-Type: multipart/alternative; boundary="001a11401eda1b06680564b7f671" Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 18:55:59 -0000 --001a11401eda1b06680564b7f671 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 8, 2018 at 10:44 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Feb 08, 2018 at 09:11:58AM -0800, Andy Bierman wrote: > > > > > Then remove the text that says an error is sent if with-defaults > attempted > > on . > > None of this new text needs to go into NMDA. It can be a vendor-specific > > mystery what gets set as origin=default. Implementors can read RFC 6243 > > and figure it out on their own. > > As I said, I am absolutely fine with the option of being silent about > with-defaults and if needed someone can spin an update of RFC 6243. > > This is not needed. If the "with-defaults" parameter is present in a request to such a datastore, then the server MUST return an error, as specified in "ietf-netconf-nmda" (see Section 4 ). The 'with-defaults' parameter does not apply to operational datastores. If the 'with-defaults' parameter is present in a request to an operational datastore, then the server MUST return an element with an value of 'invalid-value'."; There are 2 places in the draft that say MUST send an error. You need to add detailed text explaining what "harm to the Internet" is caused if this parameter is accepted. You cannot use MUST unless interoperability is harmed by allowing a server to omit response data containing the YANG default value. Please explain all the problems solved by this MUST constraint. Please explain in detail in the draft WHY The 'with-defaults' parameter does not apply to operational datastores. This assertion is false. > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a11401eda1b06680564b7f671 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 8, 2018 at 10:44 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Feb 08, 2018 at 09:11:58A= M -0800, Andy Bierman wrote:
> >
> Then remove the text that says an error is sent if with-defaults attem= pted
> on <operational>.
> None of this new text needs to go into NMDA. It can be a vendor-specif= ic
> mystery what gets set as origin=3Ddefault.=C2=A0 Implementors can read= RFC 6243
> and figure it out on their own.

As I said, I am absolutely fine with the option of being silent about
with-defaults and if needed someone can spin an update of RFC 6243.



This is not needed.
<= br>

   If the "w=
ith-defaults" parameter
   is present in a request to such a datastore, then the server MUST=C2=A0<=
/pre>
=C2=A0 =C2=
=A0 =C2=A0 return an error, as specified in "ietf-netconf-nmda" (=
see Section 4).


         The 'with-d=
efaults' parameter does not apply to operational
         datastores. If the 'with-defaults' parameter is present in=
 a
         request to an operational datastore, then the server MUST
         return an <rpc-error> element with an <error-tag> valu=
e of
         'invalid-value'.";


There are 2 places in the draft that say MUST send an er= ror.
You need to add detailed text explaining what "harm to the Int= ernet"
is caused if this parameter is accepted. You cannot use MUST=
unless interoperability is harmed by allowing a server to
omit respo= nse data containing the YANG default value.
Please explain all the probl= ems solved by this MUST constraint.

Please explain in detail in the draft=
 WHY 


         The 'with-defaults' parameter does no=
t apply to operational
         datastores.

=

This assertion is false.

<=
pre class=3D"gmail-newpage" style=3D"font-size:13.3333px;margin-top:0px;mar=
gin-bottom:0px;color:rgb(0,0,0)">

=C2=A0
/js

Andy

=C2=A0

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

--001a11401eda1b06680564b7f671-- From nobody Thu Feb 8 11:00:20 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9447412D810; Thu, 8 Feb 2018 11:00:12 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.909 X-Spam-Level: X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n2ETgmavTY2f; Thu, 8 Feb 2018 11:00:11 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A4C42126E3A; Thu, 8 Feb 2018 11:00:10 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6CE2AA24; Thu, 8 Feb 2018 20:00:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id s7gjWhdj_H8h; Thu, 8 Feb 2018 20:00:08 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 8 Feb 2018 20:00:09 +0100 (CET) Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 48A4C2014E; Thu, 8 Feb 2018 20:00:09 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RekJTNGvzsaR; Thu, 8 Feb 2018 20:00:08 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id C98522014B; Thu, 8 Feb 2018 20:00:08 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id B12DB423EADC; Thu, 8 Feb 2018 20:00:08 +0100 (CET) Date: Thu, 8 Feb 2018 20:00:08 +0100 From: Juergen Schoenwaelder To: Andy Bierman Cc: Martin Bjorklund , Netconf , NetMod WG Message-ID: <20180208190008.qrmavfup43mxsrq4@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Andy Bierman , Martin Bjorklund , Netconf , NetMod WG References: <20180207.192803.834988416883038576.mbj@tail-f.com> <20180208073617.yico4gvfrl6xdusw@elstar.local> <20180208184453.m4j7scytf3lmqkvd@elstar.local> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 19:00:12 -0000 On Thu, Feb 08, 2018 at 10:55:53AM -0800, Andy Bierman wrote: > On Thu, Feb 8, 2018 at 10:44 AM, Juergen Schoenwaelder < > j.schoenwaelder@jacobs-university.de> wrote: > > > On Thu, Feb 08, 2018 at 09:11:58AM -0800, Andy Bierman wrote: > > > > > > > Then remove the text that says an error is sent if with-defaults > > attempted > > > on . > > > None of this new text needs to go into NMDA. It can be a vendor-specific > > > mystery what gets set as origin=default. Implementors can read RFC 6243 > > > and figure it out on their own. > > > > As I said, I am absolutely fine with the option of being silent about > > with-defaults and if needed someone can spin an update of RFC 6243. > > This is not needed. > > > If the "with-defaults" parameter > is present in a request to such a datastore, then the server MUST > > return an error, as specified in "ietf-netconf-nmda" (see Section 4 > ). > > > The 'with-defaults' parameter does not apply to operational > datastores. If the 'with-defaults' parameter is present in a > request to an operational datastore, then the server MUST > return an element with an value of > 'invalid-value'."; > > > > There are 2 places in the draft that say MUST send an error. > You need to add detailed text explaining what "harm to the Internet" > is caused if this parameter is accepted. You cannot use MUST > unless interoperability is harmed by allowing a server to > omit response data containing the YANG default value. > Please explain all the problems solved by this MUST constraint. > > > Please explain in detail in the draft WHY > > The 'with-defaults' parameter does not apply to operational > datastores. > > This assertion is false. I don't get your message. Trying again: I am fine to remove all text that talks about with-default and if needed someone can spin an update of RFC 6243 to use with-default. /js -- Juergen Schoenwaelder Jacobs University Bremen gGmbH Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany Fax: +49 421 200 3103 From nobody Thu Feb 8 11:27:41 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4F85E127286; Thu, 8 Feb 2018 11:27:35 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hzen3uYBpCQv; Thu, 8 Feb 2018 11:27:34 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id C9816124BE8; Thu, 8 Feb 2018 11:27:33 -0800 (PST) Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id ED4271AE046C; Thu, 8 Feb 2018 20:27:32 +0100 (CET) Date: Thu, 08 Feb 2018 20:27:32 +0100 (CET) Message-Id: <20180208.202732.195106484925473126.mbj@tail-f.com> To: andy@yumaworks.com Cc: j.schoenwaelder@jacobs-university.de, netconf@ietf.org, netmod@ietf.org From: Martin Bjorklund In-Reply-To: References: <20180208073617.yico4gvfrl6xdusw@elstar.local> X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 19:27:35 -0000 Andy Bierman wrote: > > .... > > Who needs all this to manage a network? > > > > > > I sometimes get comments from people about NETCONF defaults, like > "You think this is a standard? Why does a vendor get to decide what > is a default leaf?" > > CoMI has taken a different approach. > Every server MUST implement "trim" mode and nothing else. > NETCONF should do the same (but won't) Since we're now defining a new datastore, , we have the opportunity to define one single behavour that all servers MUST implement. That's why the draft says that defaults are injected as data flows into , and that all values that are in use (including defaults), are present in and always returned. /martin From nobody Thu Feb 8 11:56:38 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCEDE126CF6 for ; Thu, 8 Feb 2018 11:56:37 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.698 X-Spam-Level: X-Spam-Status: No, score=-2.698 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RwUSpc-yi_Cb for ; Thu, 8 Feb 2018 11:56:35 -0800 (PST) Received: from mail-io0-x22e.google.com (mail-io0-x22e.google.com [IPv6:2607:f8b0:4001:c06::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 777E3126C25 for ; Thu, 8 Feb 2018 11:56:35 -0800 (PST) Received: by mail-io0-x22e.google.com with SMTP id p188so7054831ioe.12 for ; Thu, 08 Feb 2018 11:56:35 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=0+eghHhib6XfjX33/Z9VTbGElweFZJVVkIsUXx9Cl2g=; b=inxaTs+7+1K3AfnM7rPbp7ZUoYMhEar3r6GJSUjJ9YuDJ1oOmvTSMtPBoFLoMr2JUU k8Z42hl0gmJ5KMygCNmvMYAGTN1iGxV/C0plkH6AwIwqxJI52mnFsWrHcsKttR3+0jNG cEvjMbQNfAMJ8fVpXg9zGrMvZO8Ik5coMux59FTgMHUuLno4RsZeOdr59v325ZCHe4hm FmsrmYN6rZl/exihcnaf96XEMLbZ8J185h774GVP2lAmMUS6SaitQrJUvFQhkaH4txUJ CgTOPYGy4Vp0oMcVhoiRx3+Cy1Wq/a+8gvHsKuUQik6eYbfjtwKcT5t5CSGXFjOovmt9 1MYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=0+eghHhib6XfjX33/Z9VTbGElweFZJVVkIsUXx9Cl2g=; b=HU4z+tX52ezYtqk/dSA2NDgVx1dKZe9N3FH/HjsmF6PqB4rjiQS5jA1p5KhYWD2qlN 5mRXQR2CRHmdR7pB393p/x7VgSQ+1RsBE0C+b3m0WMICwZvebOKHK0huS/EXiMrV+HSN FMIbep8qjhqBFy78AeBQy6ob32yFMOZZlLWRIMcXp+Sy1GUyfyTeA2v7CJ1/ZmK5fI3P lzy58eS3qDIIs+wDO93c8DKYEai/90D/m/Guq3qpSf3pZrJ9PVPgv6iix+M6u1nrOsFQ D5b9+HtbZnKZ1gkQ7mUWK4DSrGol2yoSqDlwy3kukZdUZ+OaWGTzbzy+OcdTG0YcqPPT /wmQ== X-Gm-Message-State: APf1xPABo9o/UnERfp7uXfR4kT3ihRwkWYkHz5iRDYxmPM61Hfd1hryv 6Ne8dbbSY3L2Khwv2VoeQ+LtcnFS X-Google-Smtp-Source: AH8x224W/xqqsKXt8boqK5370mA7yqqTlIg8r1gI+sU3WeF0wpnK9j7dEo5eHG0h7PrLZsnNLtUfRg== X-Received: by 10.107.187.4 with SMTP id l4mr290443iof.2.1518119794695; Thu, 08 Feb 2018 11:56:34 -0800 (PST) Received: from mahesh-m-m8d1.attlocal.net ([2600:1700:edb0:8fd0:883a:1494:c4f9:cf9d]) by smtp.gmail.com with ESMTPSA id 34sm510377iot.48.2018.02.08.11.56.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Feb 2018 11:56:33 -0800 (PST) From: Mahesh Jethanandani Message-Id: Content-Type: multipart/alternative; boundary="Apple-Mail=_55872080-6C32-4A3A-A858-A8E5645BF840" Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) Date: Thu, 8 Feb 2018 11:56:30 -0800 In-Reply-To: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> Cc: netmod WG To: Eliot Lear References: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] Fwd: [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 19:56:38 -0000 --Apple-Mail=_55872080-6C32-4A3A-A858-A8E5645BF840 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Feb 8, 2018, at 8:34 AM, Eliot Lear wrote: >=20 >=20 >=20 > From: "M. Ranganathan" > Subject: [OPSAWG] Minor change in = ietf-access-control-list@2018-02-02.yang > Date: February 8, 2018 at 8:25:26 AM PST > To: opsawg@ietf.org >=20 >=20 > In order to compile the published YANG model with OpenDaylight = Yangtools I had to make the following change ( diff published file vs. = changed file is below ): >=20 > 583c583 > < path "../../../../../../acl/name"; > --- > > path "/access-lists/acl/name"; > 597c597 > < path "../../../../../../../acl/aces/ace/name"; > --- > > path "/access-lists/acl/aces/ace/name=E2=80=9D; That path is correct. And I have four tools (pyang, yanglint, = yangdump-pro and confdc) compile the model. Nobody complained about it. >=20 >=20 > I am not sure (don't have enough YANG experience) to know if the error = is with Yangtools or with the published YANG model but I thought I'd = send this information to the list just in case. >=20 > Thank you for your attention. >=20 > Regards, >=20 > Ranga >=20 >=20 > --=20 > M. Ranganathan > _______________________________________________ > OPSAWG mailing list > OPSAWG@ietf.org > https://www.ietf.org/mailman/listinfo/opsawg >=20 >=20 > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod Mahesh Jethanandani mjethanandani@gmail.com --Apple-Mail=_55872080-6C32-4A3A-A858-A8E5645BF840 Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Feb 8, 2018, at 8:34 AM, Eliot Lear <lear@cisco.com> = wrote:



From: "M. Ranganathan" <mranga@gmail.com>
Subject: = [OPSAWG] Minor = change in ietf-access-control-list@2018-02-02.yang
Date: February 8, 2018 at 8:25:26 AM PST
To: = opsawg@ietf.org


In order to compile the published = YANG model with OpenDaylight Yangtools I had to make the following = change ( diff published file vs. changed file is below ):

583c583
<          = ;       path = "../../../../../../acl/name";
---
>          = ;       path "/access-lists/acl/name";
597c597
<          = ;         path = "../../../../../../../acl/aces/ace/name";
---
>          = ;         path = "/access-lists/acl/aces/ace/name=E2=80=9D;

That = path is correct. And I have four tools (pyang, yanglint, yangdump-pro = and confdc) compile the model. Nobody complained about it.



I am not sure (don't have enough YANG = experience) to know if the error is with Yangtools or with the published = YANG model but I thought I'd send this information to the list just in = case.

Thank you for = your attention.

Regards,

Ranga


--
M. Ranganathan
_______________________________________________
OPSAWG = mailing list
OPSAWG@ietf.org
https://www.ietf.org/mailman/listinfo/opsawg


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

Mahesh Jethanandani
mjethanandani@gmail.com

= --Apple-Mail=_55872080-6C32-4A3A-A858-A8E5645BF840-- From nobody Thu Feb 8 11:58:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3315F126C25 for ; Thu, 8 Feb 2018 11:58:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.509 X-Spam-Level: X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FGShbCMLoJVH for ; Thu, 8 Feb 2018 11:58:05 -0800 (PST) Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id ACC9A1267BB for ; Thu, 8 Feb 2018 11:58:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12507; q=dns/txt; s=iport; t=1518119884; x=1519329484; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=z0VUXheLkRckIR6et6PJhHizQWwsDJ/kK1+DLWZeYXs=; b=Oci3GbFEn/kXwJVtCx/VLxFgA7EiFaK8bjpsRaQ4sbaezrvC5CAMw1Ji H9SLVUy8+A6gTaaT0NywNGsXncvdTHxk/SngLHlVO7EVyT1+nB2eDBzg0 QeRYoTkfK8exq5JQzMs12ObEm2FQbjRiDk/cJS8zQouxGhKtA8Rel14et c=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CCAQABq3xa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ3cCiDZYsYjzOJFohlh3IHAxgBCoRJTwKDBhUBAgEBAQEBAQJ?= =?us-ascii?q?rKIUjAQEBBAEBIUsLEAkCDgMDAQIBJwMCAiEGHwkIBg0GAgEBihkDFRCRa510g?= =?us-ascii?q?icmhFuCOw2BMYIKAQEBAQEBAQEBAQEBAQEBAQEBAQEBDgoFhHyFfYMFgUmBIkQ?= =?us-ascii?q?BAQKCDxaCYYJlBYgDikmHWIlSNQmEZoIyhQuDfVWFB4w4iAaORIlIgTw1I4FQM?= =?us-ascii?q?xoIGxU9gkaCYSmBbkA3jU0BAQE?= X-IronPort-AV: E=Sophos;i="5.46,480,1511827200"; d="asc'?scan'208,217";a="1895489" Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 08 Feb 2018 19:58:02 +0000 Received: from [10.61.225.27] ([10.61.225.27]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w18Jw1LA003036; Thu, 8 Feb 2018 19:58:02 GMT To: Mahesh Jethanandani Cc: netmod WG References: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> From: Eliot Lear Message-ID: Date: Thu, 8 Feb 2018 20:58:01 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uFFW0pXFc8NdDh7LWpH7cTR5FiN4VPTIX" Archived-At: Subject: Re: [netmod] Fwd: [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 19:58:08 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --uFFW0pXFc8NdDh7LWpH7cTR5FiN4VPTIX Content-Type: multipart/mixed; boundary="jhfgmPALFQjAUe2UVT0R3mksUuawJSxAK"; protected-headers="v1" From: Eliot Lear To: Mahesh Jethanandani Cc: netmod WG Message-ID: Subject: Re: [netmod] Fwd: [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang References: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> In-Reply-To: --jhfgmPALFQjAUe2UVT0R3mksUuawJSxAK Content-Type: multipart/alternative; boundary="------------23634BF47CDE068DDDB8646D" Content-Language: en-US This is a multi-part message in MIME format. --------------23634BF47CDE068DDDB8646D Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Ok. On 08.02.18 20:56, Mahesh Jethanandani wrote: > > >> On Feb 8, 2018, at 8:34 AM, Eliot Lear > > wrote: >> >> >> >> *From: *"M. Ranganathan" > >> *Subject: **[OPSAWG] Minor change in >> ietf-access-control-list@2018-02-02.yang >> * >> *Date: *February 8, 2018 at 8:25:26 AM PST >> *To: *opsawg@ietf.org >> >> >> In order to compile the published YANG model with OpenDaylight >> Yangtools I had to make the following change ( diff published file >> vs. changed file is below ): >> >> 583c583 >> <=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 path "../../../../../../acl/name"; >> --- >> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0 path "/access-lists/acl/name"; >> 597c597 >> <=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 path "../../../../../../../acl/ac= es/ace/name"; >> --- >> >=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 path "/access-lists/acl/aces/ace/= name=E2=80=9D; > > That path is correct. And I have four tools (pyang, yanglint, > yangdump-pro and confdc) compile the model. Nobody complained about it.= > >> >> >> I am not sure (don't have enough YANG experience) to know if the >> error is with Yangtools or with the published YANG model but I >> thought I'd send this information to the list just in case. >> >> Thank you for your attention. >> >> Regards, >> >> Ranga >> >> >> --=20 >> M. Ranganathan >> _______________________________________________ >> OPSAWG mailing list >> OPSAWG@ietf.org >> https://www.ietf.org/mailman/listinfo/opsawg >> >> >> _______________________________________________ >> netmod mailing list >> netmod@ietf.org >> https://www.ietf.org/mailman/listinfo/netmod > > Mahesh Jethanandani > mjethanandani@gmail.com > --------------23634BF47CDE068DDDB8646D Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable

Ok.


On 08.02.18 20:56, Mahesh Jethanandani= wrote:


On Feb 8, 2018, at 8:34 AM, Eliot Lear <lear@cisco.com> wrote:


From: "M. Ranganathan" <<= a href=3D"mailto:mranga@gmail.com" class=3D"" moz-do-not-send=3D"true">mranga@gmail.com>
Subject: [OPSAWG]= Minor change in ietf-access-contr= ol-list@2018-02-02.yang
Date: February 8, 2018 at 8:25:26 AM PST
To: opsawg@ietf.org


In order to compile the published= YANG model with OpenDaylight Yangtools I had to make the following change ( diff published file vs. changed file is below ):

583c583
<=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 path "../../../../../../acl/na= me";
---
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 path "/access-lists/acl/name";=
597c597
<=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 path "../../../../../../../acl/aces/ace/name";
---
>=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 path "/access-lists/acl/aces/ace/name=E2=80=9D;
=

That path is correct. And I have four tools (pyang, yanglint, yangdump-pro and confdc) compile the model. Nobody complained about it.



I am not sure (don't have enough YANG experience) to know if the error is with Yangtools or with the published YANG model but I thought I'd send this information to the list just in case.
=
Thank you for your attention.

Regards,

Ranga


--
M. Ranganathan
= =
_______________________________________________
OPSAWG mailing list
OPSAWG@ietf.org
= https://www.ietf.org/mailman/listinfo/opsawg<= /a>


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

Mahesh Jethanandani
mjethanandani@gmail.com


--------------23634BF47CDE068DDDB8646D-- --jhfgmPALFQjAUe2UVT0R3mksUuawJSxAK-- --uFFW0pXFc8NdDh7LWpH7cTR5FiN4VPTIX Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlp8q8kACgkQh7ZrRtnS ejMTtQf/ZBa+gFsyjCJkDdYYwqtISprwcSG68TKGY+YazeQz2NgrQ/1Kppxv8CU9 V9/m2vGZvhy7AIq7goSfuQyycgVTe7RCyqCYVZ6QljxBIVcIVbPY37tUapkzgs2m sz2V/xqwcfX3OfwIGafy3e8/5peFrOoimVPg83jKMK32UvA4FUWUXVWn8/v3Ynud XYF7a5UmrmM0GcOOOzuUbA5QFpicYmiiUlxO2odG6WUnhWrrCE022tjiJ3E3tnBt ACU/R+kjY2zh148xlc9rB1upizNQboPZBWR0IH/Xbt0SWKBP4LPoFP4aPWd/mjeh r+iOFGK92xco0NeeosD1VOCU+YKLJQ== =v78v -----END PGP SIGNATURE----- --uFFW0pXFc8NdDh7LWpH7cTR5FiN4VPTIX-- From nobody Thu Feb 8 14:34:27 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BA1D6127876 for ; Thu, 8 Feb 2018 14:34:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.599 X-Spam-Level: X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B8xnX9-fikeG for ; Thu, 8 Feb 2018 14:34:23 -0800 (PST) Received: from mail-lf0-x22a.google.com (mail-lf0-x22a.google.com [IPv6:2a00:1450:4010:c07::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D110812785F for ; Thu, 8 Feb 2018 14:34:22 -0800 (PST) Received: by mail-lf0-x22a.google.com with SMTP id f136so8603647lff.8 for ; Thu, 08 Feb 2018 14:34:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=v1ZCSDh/IZddtR7AQSaO2vJN5P0stMt2qQW/MTE80OM=; b=dCNl6kk3z/yqlc6dgRKa7gWeHDpR52P0h1MeGWN03/qZkms9RAmRKNLleW1PH63L5N EcssPPHnDEXxFg4x8yzA99NVy9EcOfesUTq/HBJ3xHvMVoCoXgOX/b0YCruXpnb89Jad Ekc+i0TXa4cSMS9t1hrLsxjFO+r5Ap0y+WMJ2O3mR2jqFApAk+I0tXd6WkUh/h98fh9F yr0E1ZViqUbi8qtAX5spo5FwieY6A4QtX94eBuiqJ/uCJT2oVVwGruAPYsagelN0LvI5 0vXDlA3UbAY21BUiyN6OmeIIlKn/YVjvxUBddzsG1+4vP2J8JO+HP6GVmIdpb70L23Oi fG8Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=v1ZCSDh/IZddtR7AQSaO2vJN5P0stMt2qQW/MTE80OM=; b=X8gXomytdwxYr/lUV68zLtvjifpszXDGatcbFt1PJTfGLBSBw4cKL1RqHEPic734Ou QH2A8zHenN4TM6FjNY+VqlGnUSUENOSiKVClZwqTvBZU8oA1twucDYApj4IrnCjALhQR k7AoKYMrT9uZUgqM7WtxLAp/1h49sWN4nLeHbiyN9lkaPs7V495Vv5KV5brro7vUA8FX RK93JSIyZyne34V81cofy/Bt5rzNH6Z6bNXp+SSMnd6WtQ2VSNgWU0TyIUDpOSHB7y9z fKtuGWDWBOQaPwAicf3PlCirXsUZrHc6waPiid8FGZfORrRTjMHoDJVXLpui+/7+Tm0I UUug== X-Gm-Message-State: APf1xPAbV+8nYHUVifQLHAqYLEmJUcYNZ/+rOMfd0t4Qb54r0SbJACZk xYGTOEphWi2mdowZr/ovuyxW3AElqb9aR+xlECDlAw== X-Google-Smtp-Source: AH8x225dXGFASeFLADbBOqHxQrjZqonf7Lf1fF8VLsVnU4eSkHRJskvBiC5CEKujYjiOhtIYCY8CUBIawSGzCFVyHLs= X-Received: by 10.25.20.168 with SMTP id 40mr484318lfu.23.1518129261026; Thu, 08 Feb 2018 14:34:21 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.225.18 with HTTP; Thu, 8 Feb 2018 14:34:19 -0800 (PST) In-Reply-To: <20180208190008.qrmavfup43mxsrq4@elstar.local> References: <20180207.192803.834988416883038576.mbj@tail-f.com> <20180208073617.yico4gvfrl6xdusw@elstar.local> <20180208184453.m4j7scytf3lmqkvd@elstar.local> <20180208190008.qrmavfup43mxsrq4@elstar.local> From: Andy Bierman Date: Thu, 8 Feb 2018 14:34:19 -0800 Message-ID: To: Juergen Schoenwaelder , Andy Bierman , Martin Bjorklund , Netconf , NetMod WG Content-Type: multipart/alternative; boundary="001a113fb11853b6780564bb03c1" Archived-At: Subject: Re: [netmod] [Netconf] LC of NDMA NETCONF/RESTCONF drafts X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 08 Feb 2018 22:34:26 -0000 --001a113fb11853b6780564bb03c1 Content-Type: text/plain; charset="UTF-8" On Thu, Feb 8, 2018 at 11:00 AM, Juergen Schoenwaelder < j.schoenwaelder@jacobs-university.de> wrote: > On Thu, Feb 08, 2018 at 10:55:53AM -0800, Andy Bierman wrote: > > On Thu, Feb 8, 2018 at 10:44 AM, Juergen Schoenwaelder < > > j.schoenwaelder@jacobs-university.de> wrote: > > > > > On Thu, Feb 08, 2018 at 09:11:58AM -0800, Andy Bierman wrote: > > > > > > > > > Then remove the text that says an error is sent if with-defaults > > > attempted > > > > on . > > > > None of this new text needs to go into NMDA. It can be a > vendor-specific > > > > mystery what gets set as origin=default. Implementors can read RFC > 6243 > > > > and figure it out on their own. > > > > > > As I said, I am absolutely fine with the option of being silent about > > > with-defaults and if needed someone can spin an update of RFC 6243. > > > > This is not needed. > > > > > > If the "with-defaults" parameter > > is present in a request to such a datastore, then the server MUST > > > > return an error, as specified in "ietf-netconf-nmda" (see Section 4 > > netconf-03#section-4>). > > > > > > The 'with-defaults' parameter does not apply to operational > > datastores. If the 'with-defaults' parameter is present in a > > request to an operational datastore, then the server MUST > > return an element with an value of > > 'invalid-value'."; > > > > > > > > There are 2 places in the draft that say MUST send an error. > > You need to add detailed text explaining what "harm to the Internet" > > is caused if this parameter is accepted. You cannot use MUST > > unless interoperability is harmed by allowing a server to > > omit response data containing the YANG default value. > > Please explain all the problems solved by this MUST constraint. > > > > > > Please explain in detail in the draft WHY > > > > The 'with-defaults' parameter does not apply to operational > > datastores. > > > > This assertion is false. > > I don't get your message. Trying again: I am fine to remove all text > that talks about with-default and if needed someone can spin an update > of RFC 6243 to use with-default. > It is now clear that the current "trim" and "report-all-tagged" enums apply to . These retrieval options apply to config=false nodes for . It is not clear why is removing this functionality for config=false nodes. > > /js > Andy > > -- > Juergen Schoenwaelder Jacobs University Bremen gGmbH > Phone: +49 421 200 3587 Campus Ring 1 | 28759 Bremen | Germany > Fax: +49 421 200 3103 > --001a113fb11853b6780564bb03c1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Thu, Feb 8, 2018 at 11:00 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Feb 08, 2018 at 10:55:53AM -0800, Andy Bierm= an wrote:
> On Thu, Feb 8, 2018 at 10:44 AM, Juergen Schoenwaelder <
> j.schoenwaelde= r@jacobs-university.de> wrote:
>
> > On Thu, Feb 08, 2018 at 09:11:58AM -0800, Andy Bierman wrote:
> > > >
> > > Then remove the text that says an error is sent if with-defa= ults
> > attempted
> > > on <operational>.
> > > None of this new text needs to go into NMDA. It can be a ven= dor-specific
> > > mystery what gets set as origin=3Ddefault.=C2=A0 Implementor= s can read RFC 6243
> > > and figure it out on their own.
> >
> > As I said, I am absolutely fine with the option of being silent a= bout
> > with-defaults and if needed someone can spin an update of RFC 624= 3.
>
> This is not needed.
>
>
>=C2=A0 =C2=A0 If the "with-defaults" parameter
>=C2=A0 =C2=A0 is present in a request to such a datastore, then the ser= ver MUST
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0return an error, as specified in "ietf-= netconf-nmda" (see Section 4
> <https://tools.ietf.= org/html/draft-ietf-netconf-nmda-netconf-03#section-4>). >
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The 'with-defaults' paramete= r does not apply to operational
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datastores. If the 'with-default= s' parameter is present in a
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 request to an operational datastore,= then the server MUST
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 return an <rpc-error> element = with an <error-tag> value of
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'invalid-value'.";
>
>
>
> There are 2 places in the draft that say MUST send an error.
> You need to add detailed text explaining what "harm to the Intern= et"
> is caused if this parameter is accepted. You cannot use MUST
> unless interoperability is harmed by allowing a server to
> omit response data containing the YANG default value.
> Please explain all the problems solved by this MUST constraint.
>
>
> Please explain in detail in the draft WHY
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 The 'with-defaults' paramete= r does not apply to operational
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 datastores.
>
> This assertion is false.

I don't get your message. Trying again: I am fine to remove all text that talks about with-default and if needed someone can spin an update
of RFC 6243 to use with-default.


It is now clear that the current "trim" and "report= -all-tagged" enums apply to <operational>.
These retri= eval options apply to config=3Dfalse nodes for <get>.
It is= not clear why <get-data> is removing this functionality for config= =3Dfalse nodes.

=C2=A0

/js


Andy

=C2=A0

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

--001a113fb11853b6780564bb03c1-- From nobody Thu Feb 8 20:01:53 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EEB881242EA for ; Thu, 8 Feb 2018 20:01:51 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id N7BIBxgzU3Rj for ; Thu, 8 Feb 2018 20:01:49 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 8EDF1127137 for ; Thu, 8 Feb 2018 20:01:49 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w193xckb014903; Thu, 8 Feb 2018 20:01:48 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=UO9tFGA42NbmIpvfCK0B2bMAu3rskifhrUPCfEUtAwA=; b=CgsNA1m9O1swNYq6tYsKM9j/Ckj7G4X+UgfgWnKLkeVwcJHDQUXZEbabxTnJI/ZkpXwf 8/uOBcNhlp65I1bxu4+d4l9AAN5iqoSbvgGY/5Vf0Q0QIWv2tIv9PuHgv/yHmoUKfbgP u+HtKDba0Fcr1kBN5x2oDtWb6JasHshFi5P8gAxEvOp7tTSc9AI2iKERjOCe0YHm5X+j tg1XOx2obdYRXy1o9CBG1ZMqTdh5qu3KSQGS6y2Ed1js9DEY2uvDJFwbZKQDLf7C3dXi lw+ZU+6UYoTRG5a58oulEslrRGoCAIf2HUYnzsOYsbpnI/kGEPLLTfsRPD+DQLz8nyB8 pg== Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0181.outbound.protection.outlook.com [216.32.181.181]) by mx0a-00273201.pphosted.com with ESMTP id 2g13mug1mg-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 08 Feb 2018 20:01:48 -0800 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2906.namprd05.prod.outlook.com (10.168.176.18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Fri, 9 Feb 2018 04:01:47 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747%13]) with mapi id 15.20.0506.007; Fri, 9 Feb 2018 04:01:47 +0000 From: Kent Watsen To: "Clyde Wildes (cwildes)" , "netmod@ietf.org" Thread-Topic: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt Thread-Index: AQHTi/jgm64n1kE5c0S5iq2VpQaBSqN2at0AgAznHmeAFJ1egIABnPeAgAG9VAA= Date: Fri, 9 Feb 2018 04:01:47 +0000 Message-ID: References: <151579789446.21777.985631371557420470@ietfa.amsl.com> <045f01d39534$c02ba480$4001a8c0@gateway.2wire.net> <5C6AA747-4459-408C-B5CA-12E2210D36EA@cisco.com> In-Reply-To: <5C6AA747-4459-408C-B5CA-12E2210D36EA@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB2906; 7:/qu4IFK/ObF+6GH1NPhlieVeaT4z6u0Zmt+A6ns0qKE52Pbg8kglUVPMnKzik5MjWS+W0MM1QZujGARLcDLeqUkrwOn4qxiZAq+PWshSomMhjG+S6w8LiGYzzJB2aE4GwOVS9BD8f7nXels/EdLNYPbtS9uZNhwvHUzBMmwblKJF/G9WuTkqolr4BklOdjjy8n8/Y+0Wbeb78e7ss9ysRrrTHZU3BbNG5seiX2VwjIW/sfpj3dkfuReKhJgera8n x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: db09c53f-4edb-4fe8-d5f8-08d56f71d6f1 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB2906; x-ms-traffictypediagnostic: DM5PR05MB2906: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(10436049006162)(209352067349851)(192374486261705)(138986009662008); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(10201501046)(6055026)(6041288)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB2906; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2906; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(366004)(396003)(39860400002)(39380400002)(199004)(189003)(13464003)(51444003)(52314003)(2950100002)(316002)(966005)(3280700002)(81156014)(8676002)(81166006)(2906002)(36756003)(3660700001)(8936002)(229853002)(14454004)(93886005)(97736004)(2900100001)(33656002)(2501003)(106356001)(5250100002)(102836004)(53936002)(76176011)(86362001)(25786009)(478600001)(82746002)(6436002)(6486002)(66066001)(83716003)(6246003)(6512007)(6306002)(68736007)(99286004)(575784001)(26005)(59450400001)(305945005)(58126008)(7736002)(110136005)(6116002)(3846002)(83506002)(6506007)(53546011)(186003)(105586002)(5660300001)(6346003); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2906; H:DM5PR05MB3484.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) x-microsoft-antispam-message-info: B22jWE5Vp+BCouEs22oHH49mhnmq0pla3c1tkAYQ98M+6dmnI3gb4tL6zecXLAhUriLFE1ELE077w70Y9K0thA== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <2321328F935CB541B60075FC259540D5@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: db09c53f-4edb-4fe8-d5f8-08d56f71d6f1 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 04:01:47.0485 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2906 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_02:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 lowpriorityscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090049 Archived-At: Subject: Re: [netmod] I-D Action: draft-ietf-netmod-syslog-model-19.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 04:01:52 -0000 SGkgQ2x5ZGUuDQoNCg0KPiBJIHdpbGwgcmVtb3ZlIFRMUyBpZiB0aGF0IGlzIHRoZSBwcmVmZXJl bmNlIG9mIHRoZSBjaGFpciBhbmQgdGhlIHdvcmtpbmcgZ3JvdXAuDQoNCldlJ2QgaGF2ZSB0byBh c2sgdGhlIFdHLCBzaW5jZSBpdCdzIG5vdCBhIGNoYWlyIG9yIHNoZXBoZXJkIGRlY2lzaW9uLiAg SWYgeW91J3JlIG9rYXkgbGVhdmluZyBpdCBpbiwgYW5kIGRlYWxpbmcgd2l0aCB0aGUgZmFsbG91 dCBsYXRlciwgYW5kIG5vIG9uZSBvYmplY3RzLCB0aGVuIEknbSBmaW5lIGxlYXZpbmcgVExTIGlu Lg0KDQoNCj4gUkZDIDY1ODcgY2FuIGJlIG1hZGUgSW5mb3JtYXRpb25hbC4NCg0KT2theSwgYnV0 IHlvdSBoYXZlIG5ldmVyIG1lbnRpb25lZCBpZiB5b3Uga25vdyBpZiBhbnlvbmUgKENpc2NvPykg aXMgdXNpbmcgaXQ/ICBKdW5pcGVyIGRvZXNuJ3QuICAgTXkgZmlyc3QgcHJlZmVyZW5jZSBpcyB0 byByZW1vdmUgVENQIHN1cHBvcnQgYWx0b2dldGhlci4NCg0KDQo+IFdvcmtpbmcgd2l0aCBhbiBl ZGl0b3IgbWlnaHQgaGVscCB0byBhdm9pZCBhZGRpdGlvbmFsIHJldmlzaW9ucy4NCg0KQWN0dWFs bHksIGl0IHdvdWxkIGJlIG1vcmUgbGlrZSByZXBsYWNpbmcgeW91IGFzIHRoZSBFZGl0b3IuICBZ b3UgY291bGQgc3RheSBvbiBhcyBhbiBBdXRob3IuICBUaGUgcG9pbnQgaXMsIHdlIG5lZWQgdG8g aGF2ZSBtb3JlIHRpbWVseSByZXNwb25zZXMuLi4NCg0KDQo+IFVubGVzcyBJIGhlYXIgb3RoZXJ3 aXNlIEkgd2lsbCBwb3N0IGFub3RoZXIgdXBkYXRlIG9uIEZyaWRheSB3aXRoIFRMUywgYW5kIGl0 cyByZWZlcmVuY2VzLCByZW1vdmVkIGFzIHdlbGwgYXMgdGhlIGNoYW5nZSB0byBtYWtlIFJGQyA2 NTg3IGluZm9ybWF0aW9uYWwuDQoNCllvdSBjYW4gbWFrZSB0aG9zZSBjaGFuZ2VzLCBidXQgbW9z dCBpbXBvcnRhbnRseSwgeW91IG5lZWQgdG8gbWFrZSBzdXJlIGl0IHBhc3NlcyBpZG5pdHMuICBC VFcsIEkgd2FzIHdyb25nIGJlZm9yZSwgdGhlcmUgaXMgYW4gZXJyb3IgaW4gdGhlIDIxMTkgYm9p bGVycGxhdGUgKGlkbml0cyB2ZXJib3NlIG91dHB1dCBzaG93cyBpdCkNCg0KDQo+IFRoYW5rcywN Cj4gQ2x5ZGUNCg0KS2VudA0KDQo9PT09PT0gb3JpZ2luYWwgbWVzc2FnZSA9PT09PQ0KDQpPbiAy LzYvMTgsIDQ6NDkgUE0sICJLZW50IFdhdHNlbiIgPGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3Rl Og0KDQogICAgSGkgQ2x5ZGUsDQogICAgDQogICAgVGhlIGNoYWlycyB3ZXJlIGRpc2N1c3Npbmcg dGhlIEhJU1RPUklDIHJlZmVyZW5jZSB0byBSRkMgNjU4Ny4gICBBcyB3ZSB1bmRlcnN0YW5kIGl0 LCBSRkMgNjU4NyB3YXMgYWN0dWFsbHkgb3JpZ2luYWxseSBwdWJsaXNoZWQgYXMgYSBISVNUT1JJ QyBkb2N1bWVudCB0byBhY2NvbW1vZGF0ZSBTZWN1cml0eSBhcmVhIGNvbmNlcm5zLiAgQXBwYXJl bnRseSwgQmVub2l0IHdhcyBBRCBhdCB0aGUgdGltZSwgc28gaGUgbWF5IHJlY2FsbC4gIFRoZSBJ RVRGIHRvb2sgc3BlY2lhbCBlZmZvcnQgdG8gcHVibGlzaCBSRkMgNjU4NyBhbnl3YXksIGxpa2Vs eSBkdWUgdG8gVENQIGJlaW5nIGluIGNvbW1vbiB1c2UuICBBbnl3YXksIHdlJ3JlIHdvbmRlcmlu ZywgbXVzdCB0aGlzIGRvY3VtZW50IGhhdmUgYSBub3JtYXRpdmUgcmVmZXJlbmNlIHRvIFJGQyA2 NTg3PyAgLSBjb3VsZCBpdCBiZSBtYWRlIEluZm9ybWF0aW9uYWwgaW5zdGVhZD8gIElzIHVuZGVy c3RhbmRpbmcgUkZDIDY1ODcgbmVjZXNzYXJ5IHRvIGltcGxlbWVudCB0aGUgc3lzbG9nIGRyYWZ0 Pw0KICAgIA0KICAgIFdlIGFsc28gZGlzY3Vzc2VkIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlcyB0 byB0aGUga2V5c3RvcmUtYW5kLWZyaWVuZHMgZHJhZnRzLiAgIEFzIGl0IHN0YW5kcywgbXkgc2hl cGhlcmQgd3JpdGUtdXAgaXMgZ29pbmcgdG8gaGF2ZSB0byBjYWxsIHRoZXNlIG91dCBhcyB1bnN0 YWJsZSBkZXBlbmRlbmNpZXMuICAgSSBrbm93IHRoYXQgaXQgd2FzIGRpc2N1c3NlZCBiZWZvcmUs IGJ1dCB3b3VsZCB5b3UgaGF2ZSBhbnkgYXBwZXRpdGUgdG8gcmV2aXNpdCBoYXZpbmcgVExTIGlu IHRoZSBmaXJzdCB2ZXJzaW9uIG9mIHRoaXMgbW9kdWxlPyAgUGVyaGFwcyBpdCBjb3VsZCBiZSBw aWNrZWQgaXQgdXAgaW4gYSBiaXM/DQogICAgDQogICAgV2hlbiBjYW4geW91IHBvc3QgYW4gdXBk YXRlPyAgV291bGQgeW91IHJhdGhlciB1cyBhcHBvaW50IGFuIEVkaXRvciB0byBoZWxwIGdldCBp dCBkb25lIHNvb25lcj8gIEkgdGhpbmsgdGhhdCB3ZSd2ZSBiZWVuIGluIHRoaXMgcG9zdC1MQyBw aGFzZSBmb3IgbmVhcmx5IGZvdXIgbW9udGhzIG5vdy4uLg0KICAgIA0KICAgIEtlbnQgLy8gc2hl cGhlcmQNCiAgICANCiAgICANCiAgICA9PT09PSBvcmlnaW5hbCBtZXNzYWdlID09PT09DQogICAg DQogICAgS2VudA0KICAgIA0KICAgIE15IHJlcXVlc3QgZm9yIGEgcmVmZXJlbmNlIGZvciBQb3Np eCBocyBiZWVuIGZpeGVkIGluIC0xOS4NCiAgICANCiAgICBUb20gUGV0Y2gNCiAgICANCiAgICAt LS0tLSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQogICAgRnJvbTogIktlbnQgV2F0c2VuIiA8a3dh dHNlbkBqdW5pcGVyLm5ldD4NCiAgICBUbzogPG5ldG1vZEBpZXRmLm9yZz4NCiAgICBTZW50OiBU dWVzZGF5LCBKYW51YXJ5IDE2LCAyMDE4IDQ6NTkgUE0NCiAgICANCiAgICA+IENseWRlLA0KICAg ID4NCiAgICA+IFRoaXMgZHJhZnQgc3RpbGwgaXNuJ3QgcGFzc2luZyBpZG5pdHMuICBJIHByb3Zp ZGVkIHRoZSBsaW5rIHRvIGlkbml0cw0KICAgIHByZXZpb3VzbHksIGJ1dCBoZXJlIGl0IGlzIGFn YWluOiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff X3d3dy5pZXRmLm9yZ190b29sc19pZG5pdHMmZD1Ed0lDQXcmYz1IQWtZdWg2M3JzdWhyNlNjYmZo MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllh R1R2aklTbGFKZGNabyZtPXZCOEdlbnU0STduT3U5QjdsS3o1bVdXWUNCdXVId21nbjBISXplUEFr NlEmcz1ISGE0S2c3Wm9YT3o2dUM5VmtpVF8tak1lR2RXOUtiZm8xQ3lkaVQ0Yk04JmU9Lg0KICAg IEJlbG93IGlzIHRoZSBpZG5pdHMgb3V0cHV0IGZvciAtMTkgd2l0aCBpbmxpbmVkIGNvbW1lbnRz Lg0KICAgID4NCiAgICA+IFBTOiBJIGRpZG4ndCBhbHNvIGNoZWNrZWQgdGhlIG90aGVyIGlzc3Vl cyB3ZSdyZSB0cmFja2luZywgYnV0IHdpbGwNCiAgICB3aGVuIHdlIGdldCBwYXN0IHRoZXNlIGlk bml0cyBpc3N1ZXMuDQogICAgPg0KICAgID4gS2VudA0KICAgID4NCiAgICA+DQogICAgPiA9PT09 PSBTVEFSVCA9PT09PQ0KICAgID4gaWRuaXRzIDIuMTUuMDANCiAgICA+DQogICAgPiAvdG1wL2Ry YWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC0xOS50eHQ6DQogICAgPg0KICAgID4gICBDaGVj a2luZyBib2lsZXJwbGF0ZSByZXF1aXJlZCBieSBSRkMgNTM3OCBhbmQgdGhlIElFVEYgVHJ1c3Qg KHNlZQ0KICAgID4gICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9 aHR0cHMtM0FfX3RydXN0ZWUuaWV0Zi5vcmdfbGljZW5zZS0yRGluZm8mZD1Ed0lDQXcmYz1IQWtZ dWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlF UG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPXZCOEdlbnU0STduT3U5QjdsS3o1bVdXWUNC dXVId21nbjBISXplUEFrNlEmcz1MOTVrOHJEZU5LYVNaWGtDcHF4Mmh3em1HRHc4dHJtem1ZT1Qw U0xVLWZRJmU9KToNCiAgICA+ICAgLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCiAgICAtLS0tLS0tLQ0KICAgID4NCiAg ICA+ICAgICAgTm8gaXNzdWVzIGZvdW5kIGhlcmUuDQogICAgPg0KICAgID4gICBDaGVja2luZyBu aXRzIGFjY29yZGluZyB0bw0KICAgIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92 Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX2lkLTJEaW5mb18xaWQtMkRndWlkZWxpbmVz LnR4dCZkPUR3SUNBdyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pv Q0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09dkI4R2Vu dTRJN25PdTlCN2xLejVtV1dZQ0J1dUh3bWduMEhJemVQQWs2USZzPXdybW80alZjQmI3LV9MRkg3 dHktVE9wRzgwdGZlM3BXYmZDU0ZaYVQ2ZVkmZT06DQogICAgPiAgIC0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQogICAg LS0tLS0tLS0NCiAgICA+DQogICAgPiAgICAgIE5vIGlzc3VlcyBmb3VuZCBoZXJlLg0KICAgID4N CiAgICA+ICAgQ2hlY2tpbmcgbml0cyBhY2NvcmRpbmcgdG8gaHR0cHM6Ly91cmxkZWZlbnNlLnBy b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaWQtMkRpbmZvX2No ZWNrbGlzdCZkPUR3SUNBdyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhj V3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09dkI4 R2VudTRJN25PdTlCN2xLejVtV1dZQ0J1dUh3bWduMEhJemVQQWs2USZzPV9zZVNhQ0tmenhZZWIz YjF0ZlgyUnFVazdDS2JPc1JyM3BSVkpyUThsRWMmZT0gOg0KICAgID4gICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ICAgIC0tLS0tLS0tDQogICAgPg0KICAgID4gICAqKiBUaGVyZSBpcyAxIGluc3RhbmNlIG9mIHRv byBsb25nIGxpbmVzIGluIHRoZSBkb2N1bWVudCwgdGhlDQogICAgbG9uZ2VzdCBvbmUNCiAgICA+ ICAgICAgYmVpbmcgMSBjaGFyYWN0ZXIgaW4gZXhjZXNzIG9mIDcyLg0KICAgID4NCiAgICA+IEtl bnQ6IHRoaXMgaXNuJ3QgYSBiaWcgZGVhbCBJTU8sIGJ1dCBpZiBpdCdzIGVhc3kgdG8gZml4LCBp dCBzYXZlcyB0aGUNCiAgICBSRkMgZWRpdG9yIGEgc3RlcCBsYXRlciBvbi4NCiAgICA+DQogICAg Pg0KICAgID4gICBNaXNjZWxsYW5lb3VzIHdhcm5pbmdzOg0KICAgID4gICAtLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K ICAgIC0tLS0tLS0tDQogICAgPg0KICAgID4gICA9PSBMaW5lIDM1MiBoYXMgd2VpcmQgc3BhY2lu ZzogJy4uLmdvcml0aG0gICAgaWRlLi4uJw0KICAgID4NCiAgICA+IEtlbnQ6IHRoaXMgaXMgZmlu ZS4gIGl0IGlzIGluIGEgdHJlZSBkaWFncmFtLg0KICAgID4NCiAgICA+DQogICAgPiAgID09IFRo ZSBkb2N1bWVudCBzZWVtcyB0byBsYWNrIHRoZSByZWNvbW1lbmRlZCBSRkMgMjExOSBib2lsZXJw bGF0ZSwNCiAgICBldmVuIGlmDQogICAgPiAgICAgIGl0IGFwcGVhcnMgdG8gdXNlIFJGQyAyMTE5 IGtleXdvcmRzIC0tIGhvd2V2ZXIsIHRoZXJlJ3MgYQ0KICAgIHBhcmFncmFwaCB3aXRoDQogICAg PiAgICAgIGEgbWF0Y2hpbmcgYmVnaW5uaW5nLiBCb2lsZXJwbGF0ZSBlcnJvcj8NCiAgICA+DQog ICAgPiAgICAgIChUaGUgZG9jdW1lbnQgZG9lcyBzZWVtIHRvIGhhdmUgdGhlIHJlZmVyZW5jZSB0 byBSRkMgMjExOSB3aGljaA0KICAgIHRoZQ0KICAgID4gICAgICBJRC1DaGVja2xpc3QgcmVxdWly ZXMpLg0KICAgID4NCiAgICA+IEtlbnQ6IEkgY2FuJ3QgZmluZCB0aGUgZXJyb3IuICBMb29raW5n IGF0IHRoZSB4bWwsIGl0IGlzIHZlcmJhdGltIHdoYXQNCiAgICBJIGhhdmUgaW4gdGhlIHplcm90 b3VjaCBkcmFmdC4gIG15IGd1ZXNzIGlzIHRoYXQgdGhpcyBpcyBhIHRvb2xpbmcgZXJyb3INCiAg ICBhbmQgd2Ugc2hvdWxkIGlnbm9yZSBpdC4NCiAgICA+DQogICAgPg0KICAgID4gICAtLSBUaGUg ZG9jdW1lbnQgZGF0ZSAoSmFudWFyeSAxMiwgMjAxOCkgaXMgNCBkYXlzIGluIHRoZSBwYXN0LiAg SXMNCiAgICB0aGlzDQogICAgPiAgICAgIGludGVudGlvbmFsPw0KICAgID4NCiAgICA+IEtlbnQ6 IHRoaXMgaXMgZmluZSwgaXQgaXMgaW50ZW50aW9uYWwuDQogICAgPg0KICAgID4NCiAgICA+ICAg Q2hlY2tpbmcgcmVmZXJlbmNlcyBmb3IgaW50ZW5kZWQgc3RhdHVzOiBQcm9wb3NlZCBTdGFuZGFy ZA0KICAgID4gICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KICAgIC0tLS0tLS0tDQogICAgPg0KICAgID4gICAgICAo U2VlIFJGQ3MgMzk2NyBhbmQgNDg5NyBmb3IgaW5mb3JtYXRpb24gYWJvdXQgdXNpbmcgbm9ybWF0 aXZlDQogICAgcmVmZXJlbmNlcw0KICAgID4gICAgICB0byBsb3dlci1tYXR1cml0eSBkb2N1bWVu dHMgaW4gUkZDcykNCiAgICA+DQogICAgPiAgID09IFVudXNlZCBSZWZlcmVuY2U6ICdJLUQuaWV0 Zi1uZXRjb25mLWtleXN0b3JlJyBpcyBkZWZpbmVkIG9uIGxpbmUNCiAgICAxMzg2LA0KICAgID4g ICAgICBidXQgbm8gZXhwbGljaXQgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0aGUgdGV4dA0KICAg ID4NCiAgICA+IEtlbnQ6IGxvb2tpbmcgYXQgdGhlIFhNTCwgSSBzZWUgdGhhdCB0aGUgZW50aXJl IHBhcmFncmFwaCB1c2VzICdbJyBhbmQNCiAgICAnXScgYXMgb3Bwb3NlZCB0byA8eHJlZiAuLi4v Pi4gIFBsZWFzZSBmaXggdGhpcy4NCiAgICA+DQogICAgPg0KICAgID4gICA9PSBVbnVzZWQgUmVm ZXJlbmNlOiAnUkZDNzg5NScgaXMgZGVmaW5lZCBvbiBsaW5lIDE0NTYsIGJ1dCBubw0KICAgIGV4 cGxpY2l0DQogICAgPiAgICAgIHJlZmVyZW5jZSB3YXMgZm91bmQgaW4gdGhlIHRleHQNCiAgICA+ DQogICAgPiBLZW50OiBsb29raW5nIGF0IHRoZSBYTUwsIEkgc2VlIHR3byBpbnN0YW5jZXMgb2Yg YW4gdW53YW50ZWQgIi8mZ3Q7Ig0KICAgIHN0cmluZy4gIEZvciBpbnN0YW5jZTogPHhyZWYgdGFy Z2V0PSJSRkM3ODk1Ii8+LyZndDsgIFBsZWFzZSBmaXggdGhpcy4NCiAgICA+DQogICAgPg0KICAg ID4gICAqKiBEb3ducmVmOiBOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIEhpc3RvcmljIFJGQzog UkZDIDY1ODcNCiAgICA+DQogICAgPiBLZW50OiBobW1tLCB3aGF0J3MgZ29pbmcgb24gaGVyZT8g IFRoaXMgWUFORyBtb2R1bGUgaXMgcHJvdmlkaW5nIGFuDQogICAgYWJpbGl0eSB0byBjb25maWd1 cmUgdGhlICJ0Y3AiIHRyYW5zcG9ydCwgZXZlbiB0aG91Z2ggdGhlIElFU0cgbWFkZSB0aGF0DQog ICAgYWJpbGl0eSBoaXN0b3JpYyBpbiAyMDEyIChzZWUgSUVTRyBOb3RlIGJlbG93KS4gIFNlYXJj aGluZyBvbmxpbmUsIGl0DQogICAgbG9va3MgbGlrZSBDaXNjbyBzdXBwb3J0cyB0aGlzLCBidXQg SnVuaXBlciBkb2VzIG5vdC4gIFdoYXQgYWJvdXQgb3RoZXINCiAgICB2ZW5kb3JzLCBpcyBpdCB3 aWRlbHkgc3VwcG9ydGVkPyAgV2FzIHRoaXMgZGlzY3Vzc2VkIGluIHRoZSBXRz8NCiAgICBBbnN3 ZXJpbmcgbXkgb3duIHF1ZXN0aW9uLCBzZWFyY2hpbmcgbXkgbG9jYWwgbWFpbGJveCwgSSBkb24n dCBzZWUgdGhpcw0KICAgIGV2ZXIgYmVpbmcgZGlzY3Vzc2VkIGJlZm9yZSwgb3RoZXIgdGhhbiBN YXJ0aW4gcXVlc3Rpb25pbmcgaWYgaXQgd2FzIGENCiAgICBnb29kIGlkZWEgaW4gTWFyIDIwMTYg KG5vIHJlc3BvbnNlKS4gIFBsZWFzZSBzdGFydCBhIHRocmVhZCBvbiB0aGUgbGlzdA0KICAgIHRv IGdldCBXRyBvcGluaW9uIGlmIGl0J3Mgb2theSBmb3IgdGhlIGRyYWZ0IHRvIHByb2NlZWQgYXMg aXMgb3Igbm90Lg0KICAgIEhlcmUncyB0aGUgSUVTRyBOb3RlIGZyb20gUkZDIDY1ODc6DQogICAg Pg0KICAgID4gICAgSUVTRyBOb3RlDQogICAgPg0KICAgID4gICAgVGhlIElFU0cgZG9lcyBub3Qg cmVjb21tZW5kIGltcGxlbWVudGluZyBvciBkZXBsb3lpbmcgc3lzbG9nIG92ZXINCiAgICA+ICAg IHBsYWluIHRjcCwgd2hpY2ggaXMgZGVzY3JpYmVkIGluIHRoaXMgZG9jdW1lbnQsIGJlY2F1c2Ug aXQgbGFja3MNCiAgICB0aGUNCiAgICA+ICAgIGFiaWxpdHkgdG8gZW5hYmxlIHN0cm9uZyBzZWN1 cml0eSBbUkZDMzM2NV0uDQogICAgPg0KICAgID4gICAgSW1wbGVtZW50YXRpb24gb2YgdGhlIFRM UyB0cmFuc3BvcnQgW1JGQzU0MjVdIGlzIHJlY29tbWVuZGVkIHNvDQogICAgdGhhdA0KICAgID4g ICAgYXBwcm9wcmlhdGUgc2VjdXJpdHkgZmVhdHVyZXMgYXJlIGF2YWlsYWJsZSB0byBvcGVyYXRv cnMgd2hvIHdhbnQNCiAgICB0bw0KICAgID4gICAgZGVwbG95IHNlY3VyZSBzeXNsb2cuICBTaW1p bGFybHksIHRob3NlIHNlY3VyaXR5IGZlYXR1cmVzIGNhbiBiZQ0KICAgID4gICAgdHVybmVkIG9m ZiBmb3IgdGhvc2Ugd2hvIGRvIG5vdCB3YW50IHRoZW0uDQogICAgPg0KICAgID4NCiAgICA+DQog ICAgPg0KICAgID4NCiAgICA+ICAgICAgU3VtbWFyeTogMiBlcnJvcnMgKCoqKSwgMCBmbGF3cyAo fn4pLCA0IHdhcm5pbmdzICg9PSksIDEgY29tbWVudA0KICAgICgtLSkuDQogICAgPg0KICAgID4g ICAgICBSdW4gaWRuaXRzIHdpdGggdGhlIC0tdmVyYm9zZSBvcHRpb24gZm9yIG1vcmUgZGV0YWls ZWQNCiAgICBpbmZvcm1hdGlvbiBhYm91dA0KICAgID4gICAgICB0aGUgaXRlbXMgYWJvdmUuDQog ICAgPiA9PT09PSBFTkQgPT09PT0NCiAgICA+DQogICAgPiBUaGFua3MsDQogICAgPiBLZW50IC8v IHNoZXBoZXJkDQogICAgPg0KICAgID4NCiAgICA+DQogICAgPiBfX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gbmV0bW9kIG1haWxpbmcgbGlzdA0K ICAgID4gbmV0bW9kQGlldGYub3JnDQogICAgPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2lu dC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25l dG1vZCZkPUR3SUNBdyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pv Q0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09dkI4R2Vu dTRJN25PdTlCN2xLejVtV1dZQ0J1dUh3bWduMEhJemVQQWs2USZzPUNvSURjTnlMWWg2LU42Sm1M MnVTUjJNbTJVaDFrQU9PcFlQOFlEYjBtbWMmZT0NCiAgICANCiAgICANCiAgICANCiAgICANCg0K DQoNCg== From nobody Fri Feb 9 01:21:05 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6340B126D0C for ; Fri, 9 Feb 2018 01:21:04 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.911 X-Spam-Level: X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7Vjc4h5iwqYE for ; Fri, 9 Feb 2018 01:21:03 -0800 (PST) Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id F374412422F for ; Fri, 9 Feb 2018 01:21:02 -0800 (PST) Received: from [10.147.40.109] (unknown [173.38.220.33]) by mail.tail-f.com (Postfix) with ESMTPSA id 0DA4F1AE02C9; Fri, 9 Feb 2018 10:21:00 +0100 (CET) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Jan Lindblad In-Reply-To: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> Date: Fri, 9 Feb 2018 10:20:59 +0100 Cc: netmod WG Content-Transfer-Encoding: quoted-printable Message-Id: References: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> To: Eliot Lear X-Mailer: Apple Mail (2.3445.5.20) Archived-At: Subject: Re: [netmod] [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 09:21:04 -0000 Eliot, > In order to compile the published YANG model with OpenDaylight = Yangtools I had to make the following change ( diff published file vs. = changed file is below ): >=20 > 583c583 > < path "../../../../../../acl/name"; > --- > > path "/access-lists/acl/name"; > 597c597 > < path "../../../../../../../acl/aces/ace/name"; > --- > > path "/access-lists/acl/aces/ace/name"; >=20 >=20 > I am not sure (don't have enough YANG experience) to know if the error = is with Yangtools or with the published YANG model but I thought I'd = send this information to the list just in case. >=20 > Thank you for your attention. Both the old and the new path look valid to me. Even if you can always = replace a relative path with an absolute from a YANG validity = perspective, changing from relative to absolute paths often *changes the = semantics*, so that is not generally safe. In this case, however, they = do amount to the same thing (since they both end up going all the way up = to the top level container). /jan From nobody Fri Feb 9 01:29:01 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97043126D0C for ; Fri, 9 Feb 2018 01:29:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -14.511 X-Spam-Level: X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KXRdRClLpy1Q for ; Fri, 9 Feb 2018 01:28:59 -0800 (PST) Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F3FDB1200E5 for ; Fri, 9 Feb 2018 01:28:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2912; q=dns/txt; s=iport; t=1518168539; x=1519378139; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=1mk3rXo1nBoq2LRZ/QjceYxn66QRXwDiDGkpszzoAT4=; b=DFpwgZeRt2t0TKyKvVr3xNNlFq0ZXw0WV4+Q4NOpJoi0kbQ87weowO7M uJgzkydPqIBWuiJyp207SxMnyVASYfMgeQH8qYbl3HzXLuFMQdWrbP6PP uWYdPXtvnqSDzV+oQV/lc3OQlPcYXTxuCwSa/3bbXAMzSWZtH4flLYHGq s=; X-Files: signature.asc : 488 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQA+aX1a/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUnhA2LGI8zmW0HA4U7AoMLFAECAQEBAQEBAmsohSQBBSNWEAs?= =?us-ascii?q?YKgICVwYNCAEBijGvSIInhQGDeoIKAQEBAQEBAQEBAQEBAQEBAQEBEQ+EfIV9g?= =?us-ascii?q?wWBSYZwgmUFiAOKSZFgCYRngjKFDIN9hV+MOIgGmBCBPDYigVAzGggbFT2CR4J?= =?us-ascii?q?gghdAjSsBAQE?= X-IronPort-AV: E=Sophos; i="5.46,482,1511827200"; d="asc'?scan'208"; a="1959223" 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; 09 Feb 2018 09:28:41 +0000 Received: from [10.61.225.27] ([10.61.225.27]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w199SeCC018854; Fri, 9 Feb 2018 09:28:40 GMT To: Jan Lindblad Cc: netmod WG References: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> From: Eliot Lear Message-ID: <6ecf354c-42f2-7dc2-f858-7e46f1721be1@cisco.com> Date: Fri, 9 Feb 2018 10:28:39 +0100 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="8AsXGUJQemhGvI074KIEaCxvWLA3eoBW0" Archived-At: Subject: Re: [netmod] [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 09:29:00 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --8AsXGUJQemhGvI074KIEaCxvWLA3eoBW0 Content-Type: multipart/mixed; boundary="GAcUX5iEE3VorNgfd2iVBk6O1pNLJjTm8"; protected-headers="v1" From: Eliot Lear To: Jan Lindblad Cc: netmod WG Message-ID: <6ecf354c-42f2-7dc2-f858-7e46f1721be1@cisco.com> Subject: Re: [netmod] [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang References: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> In-Reply-To: --GAcUX5iEE3VorNgfd2iVBk6O1pNLJjTm8 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Content-Language: en-US This may be. bug in OpenDaylight that is being tickled.=C2=A0 Ranga is chasing it a bit. On 09.02.18 10:20, Jan Lindblad wrote: > Eliot, > >> In order to compile the published YANG model with OpenDaylight Yangtoo= ls I had to make the following change ( diff published file vs. changed f= ile is below ): >> >> 583c583 >> < path "../../../../../../acl/name"; >> --- >>> path "/access-lists/acl/name"; >> 597c597 >> < path "../../../../../../../acl/aces/ace/name"; >> --- >>> path "/access-lists/acl/aces/ace/name"; >> >> I am not sure (don't have enough YANG experience) to know if the error= is with Yangtools or with the published YANG model but I thought I'd sen= d this information to the list just in case. >> >> Thank you for your attention. > Both the old and the new path look valid to me. Even if you can always = replace a relative path with an absolute from a YANG validity perspective= , changing from relative to absolute paths often *changes the semantics*,= so that is not generally safe. In this case, however, they do amount to = the same thing (since they both end up going all the way up to the top le= vel container). > > /jan > > --GAcUX5iEE3VorNgfd2iVBk6O1pNLJjTm8-- --8AsXGUJQemhGvI074KIEaCxvWLA3eoBW0 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlp9acgACgkQh7ZrRtnS ejME1QgA1aotVgVjbrqBWJ81d+9/8Z/p/pVdt5RBZldrdsljxRJoM6zLkR9qk7Pq yvevX1OKZ4JIMiBGVDl/3/9tKixdIU2FMIj+y4Id3kekNzpRP7QNKTDl3SpMbM6j Kstuow6Kk8ZiGJfDxL/AGDX6LWci7nn+qAim5oRDcXX81Pi78chIqSF0ruTCv6v3 vOCgDwhy1KXb6ZxiRXDfj4xkuytMgp0JlxHs3msqzVmir2SceG9JxCiwQ9aiUP+S 3PQm20EIOsnEFKiLhRdgjKdcfD8HgnEcx7Ki5lOlUZ7Gge87shgqWUWe1eD+c9M9 Xj+G9csyTzy9M7JHzLnN1h47ZKZMuQ== =hXbb -----END PGP SIGNATURE----- --8AsXGUJQemhGvI074KIEaCxvWLA3eoBW0-- From nobody Fri Feb 9 04:10:31 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A3BD127775 for ; Fri, 9 Feb 2018 04:10:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7KTP5Mv99dIh for ; Fri, 9 Feb 2018 04:10:26 -0800 (PST) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (mail-he1eur01on0137.outbound.protection.outlook.com [104.47.0.137]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DC53C126BF0 for ; Fri, 9 Feb 2018 04:10:25 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=s8lxfXe+xppJ3bc57C+1S3kI0ZpRQicpykZ+nStdk+M=; b=CRXrBUcDw0AW1AVw4Q2hxzsOo+gq4f3Kf9DaWP9p/brgS4UWBrlDqw/lqxkxfUZHz25+Ka1sXKwxFB6M03lULQkwTVgjUUpxcDkFhvthBCWiKJ9R5I6owhVOHtJTJAOk4nfzU/2MDtbqMKNDCx33/mR05xoNwtQQdXy0IQ1aM20= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.176.21.219) by DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Fri, 9 Feb 2018 12:10:22 +0000 Message-ID: <02d601d3a19e$b73cdbc0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Henrik Levkowetz" , "NETMOD Working Group" , "Benoit Claise" References: <26131545-049c-9a1a-eb2b-cdad6fce3190@cisco.com> <036201d39c25$7bb5a060$4001a8c0@gateway.2wire.net> Date: Fri, 9 Feb 2018 11:33:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.176.21.219] X-ClientProxiedBy: CWLP265CA0064.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:12::28) To DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f3facf7e-8825-458e-1473-08d56fb61880 X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:DB6PR0701MB2997; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 3:MSFpJYwR6PrbioCv9B9faiJlZ4sDoGCPU2ByMgAVs1rDVN31v4FptSHzsohg8sCPnqNwsLPYT4+Q6OdB0OIYScINaxlkCkhLaWzS9zW04LxiqNPqeeIEYYkPRC27bdgaIfyMSFZA49be7YH4jJ8bKMfWEeXScUs89TgQixMghOsPPi8Vhyb6V66OskUPrROSLD+6Xu3lPWOv49f9xXhgn3SuaNH0O5TZHGQ/bnWdjXDvnU35oEJ/PDRynln+3gs+MJ8L95rFEKX4raFU/CxNBqOi17Ip4yn9QltWYs3ZXS0=; 25:Z3o8l7/BJFxBiVmU7XqxsMYrpUL9wA5SMwTsqoRlI5VqW8cgnASL9u/72sNVnu2U7YFmU90+TedbWF6Cusq/aFV7L68mMCiv/Sf3xbP+UuWkJvNee0EUFxGP5ChXGmtSXtmpK2Cc1tA5nDnhy4uUegCU4oetQpLWxKtq1xxp/0iIB+UfDQVIRbbhYUhA9lyggim76qofDQ4nnVwZvbBITTAHPn7XpELICsKzUYPTdV32bliwrbHHuLYJ1Dj1uD9xch5cw3R2NKyZyCMzDm+COwdd/tUZpo6kS01ARWiCnj9A97lbcWDuSj+iUu5rspQ4P7Hp5wtTx2/8fculYICz4Q==; 31:Ies1uk8rjUTyJw6WEYbpHGPEqrDq8TcOVM/4SBFXrb1K+sfr13LULf6qN9GxPDcytZQoKRzt2GekzKxarFQVHeAlf1os70Ofe8vWYRLyuO177Kebw/uevQG8wBLXzc4/EM78JT6lKMZ5FCXKMbkyLVZirx79t1RL2mZb4WCgOmGH6lxTpx/pg8G4lLZY67oZMkwIh+E0ptjoZZuBe1mrTz9SpQHSa0mhlnRDG75m2hA= X-MS-TrafficTypeDiagnostic: DB6PR0701MB2997: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3002001)(10201501046)(3231101)(2400082)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123564045)(20161123560045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:DB6PR0701MB2997; BCL:0; PCL:0; RULEID:; SRVR:DB6PR0701MB2997; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 4:Ir+d49gtKa0oefr1dfGUKgeEzykNdVRQyC5DG3nB67PvfHakaMX9Aclt1UZ88NxvGKK62vS9m06Kg4p3ZYqB7+xr7R0zuuNmnkddViQd2rDf7BQE+a6YtT0vHW10+Tyw7UDaX2xTuFMhHzPxQwW+frDy4RrV7pTLORd8DN9r/HA0gwbn5UfvcjSVySh/S9qn/YLDFiS3gnX1FaKsU2UoZc3eXmlKTLRrjo+oeCbFjlO20x+6eOWstTG9MXNOYT8cLQCTCIV1q7p0Me0k4Nc9t11TBvjqGP8FkRvqKW5PGJZlLXLCKusnV4YLbeOH2NhqSHBhtVhS/DUBxi9viVr4zwQ7KqpJhkLHlL17c8MSLzc= X-Forefront-PRVS: 057859F9C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(39860400002)(376002)(366004)(346002)(189003)(199004)(13464003)(51444003)(81816011)(76176011)(105586002)(33896004)(81686011)(3846002)(84392002)(6116002)(221733001)(230700001)(2906002)(478600001)(106356001)(68736007)(386003)(52116002)(2486003)(81166006)(81156014)(14496001)(229853002)(8676002)(23676004)(186003)(3480700004)(50226002)(16526019)(61296003)(6666003)(4720700003)(7736002)(26005)(305945005)(8936002)(5660300001)(6496006)(44736005)(59450400001)(6486002)(6246003)(1556002)(50466002)(25786009)(7116003)(86362001)(44716002)(110136005)(53936002)(9686003)(316002)(62236002)(47776003)(66066001)(97736004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:DB6PR0701MB2997; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3MDFNQjI5OTc7MjM6MmVHQ1MyTXpwNGFXMGtSQXNyNEFLNkxw?= =?utf-8?B?Y3BOMkkyRE9GQlFVRWZzNUJObXFnVkw5MDdkNmlxMFFiYWV3SWlIckl0aFgz?= =?utf-8?B?OCtKWDNyV2FNaWlHYXh4WHJ2YlNmcHdVVWJDL0RyZkxkZlliYndNRlBkZE00?= =?utf-8?B?YS9VeTk0WXgrVnZBSERidkJKYXFsc1pWTUdKUzZuYXhVMkRsUHZ6MzdGWkxk?= =?utf-8?B?eVdqeG50L2NkTldXM2ZuQVNtdFFMeGdjS0cwOHFveis3cTUwaTE1d1dreVJV?= =?utf-8?B?Rkd5aFJqVnhUUzlUSVB5UkN3Uk1RS1UvUU1XU3FBQk9DbnBQUFVVb0xDYnN4?= =?utf-8?B?eTZRMEtCekU1dmFlUktZUG5sNGRKdkNhSU9SL0VOVmI2d2pDanZXNkFwNnUz?= =?utf-8?B?R3NER1QrYnBObXdtV0puWjc4MmdHa1NQRmJTa3B2WTRLV01BSVRZV2dSOC9v?= =?utf-8?B?UURRYm4xeUxKdEU4SnJTY0c5TWJDTFdGMHJDNzdMK1k2b2FqRzhCVy9xQkZx?= =?utf-8?B?Wmo5WjFFZE94WVEvZndUdE9oMDE0Z2sybXo5d2x1aU1hN2ZWWDQxNnVHb3RM?= =?utf-8?B?WDlBR0FNZVBFemR2alBZMjZLQXhCMjk2aXh5SDhlQWRDY1h0cnJRMVlBRm1s?= =?utf-8?B?MVc2Q0syeWkxc3ZqejVNdVNGekIyNmJ0VHZZdTVQcEc0RDJ6WVZJUDJ3eVVs?= =?utf-8?B?amJQcHR4aW8vYzVEdHlqQUR2V21DY3RWZFNwZEFkWXpPaW9QOThxYkJUQU1L?= =?utf-8?B?SFo4SjRqR1hXdTRvSzF6RWVhZWRSaDFBaTAxMlZVL053a0RjYzFDQ1crWUVt?= =?utf-8?B?SHNyL1g4V2hWWnNpeTF0SjR0WFVoYkkxRHhwL09Pd0VVcHV4ZzlaWkpyTXkr?= =?utf-8?B?UHVVNHppajFiT2l4OXJBSnhYSWtDempxbUx5cmFPYnFFK2VaSFh0TlJxSnUy?= =?utf-8?B?aFZ2WXc3M3Bhek9OVHByU1FFR0t3dHRjVEEzVEkyKytmQmtlNUMwaGtPak1u?= =?utf-8?B?QWtXNUhjV3liU2IzMkU3WXA1SUN6VTNaYXNpZ3gxb1B2WTYreUR5Skx4enBj?= =?utf-8?B?RGoxN21VTVJUSXgwSzZuYW0vQUhGRjVqdUdPWlo5WGxDM1U0V1VldWRlcnhZ?= =?utf-8?B?SWVDZlUzY1VFTlZ3eHNRZEZybFFlQXFFM3ZhcGZIRVJZVXl0a0paRnc1NEJk?= =?utf-8?B?Q2ZsMFhHbjYxamhDdXU4R1RMcUpXQ1V6OCsyTVFSTHJBN04wTXhzVGdFbDNy?= =?utf-8?B?R3NDdkxObXhTTHZzNTNWUENkWkVERTlWTFFhNWhubmR2ZGlyYTR1bklJODU3?= =?utf-8?B?eE9tR0FvTCt5YnhyUjBJSmYvLy9nV25nclRPWkQ3bW16N3NyNXMzdGNkWXdy?= =?utf-8?B?UkM1SkMrTlJqdWl3YjNoUWhDOUMvQkEvaWlhSzRhT1kvNEtBMGZ1eEhPM2Iz?= =?utf-8?B?V1psZndlNkRHUmNBZEl0Z3FkMHNicWFmUnVQUjRjZWZ5RXRwK0QwbXJPQTZl?= =?utf-8?B?WmVTcksraVpQdHlxdVczRFpBZGJhc3F6eWx2UHFDOHkvSmpVN3Q2UGNlVitt?= =?utf-8?B?ckJmMnZJM05jbEs5V1huNmxxUSsvVGpWd1ExbnpQd2RqUUNHZEE5b0ppdlpR?= =?utf-8?B?MCtaT2EzRjJ1aHJEaVlnd1F6OHBRZ0MzeWlIKzNnb3FhSHh6S1ZZaWV4TXg1?= =?utf-8?B?U0hqL1pmSzRaUm5yTkN6YURWdU54VUV3QnNya2hkb3VQNVduSWxRSG4wV2Qw?= =?utf-8?B?emRXSFFNb0QyUm5QVlNqcmlOT1hxZ0VBTFBzN1VqcWNhcHJQVUpNN0ltL0pq?= =?utf-8?B?L3l6Zlk4Vk1JMGFZT25DK1dyZkxBL3BielBlQ2lJdklFdEdiTnRDRzhaMjRl?= =?utf-8?B?YWsyZ3J3bk9RNG1LYTFHTG9DS3ZXVGk5cmp3NUlrd0pUbEpvNjc2VDhXaDZO?= =?utf-8?B?VkEvTUFEd2pwbXVicmNQV3lkZTlBbGFWSzVtd0FkeklvcktMNGlwRnRFMmhm?= =?utf-8?B?SEcrTWhyMVJJY0svZmlkQmpQUkJEYmc3cG4xTEVBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 6:IJ+xsC+65C1QRwr4bBEFn2WTMIEvT7Ck3R2jK9eEops8lopQxc2BtmbilIHx40EX4qqBP3Qn5tGGcYRq3/FQ9ieUvq3ZsL+TK9CwSKRNo8vmYgyRl0zyHhiTsqfYMqpllOxwOF2A34AdB12AAGAhVSaU+ZPaqRnNZp10GYTFmo916S+PG0fv6NC2pySye2/WvbatcN91mmTu6pFrFIIx3Pgos7lwB7gMinq4cAFJUxEqDrxrNP8jzlIaGdgWZR0wIm3Lsl2BwpjN8KMtXh9B5By8jtbIiTzaQ6eCNgDRhsAJ4s8kGp6yWbegfXFxk48rZPd3kkPfDWW1cL6c6JL7bTalWiF83Y1BYfQhxNg8DJE=; 5:60jzRIQU32m9e2Mum/Hp3T4GOc8tpjDVYixQ5wpMVWQShaR1CYLUtAY2lx98tT5htQ6loPY+JStnHDDQmo4nkZ5UvgFWsrsf90UVDDb2JnrJ/l8F7vE0TNx6jekc74zBXuU3wbiVU8DKlFbTyHCkNK8hrFqXSPaQR8RQ8Nqu0Ww=; 24:8jHSaLGj166Z2DdBod+REmYBhWx/7/1lEZ9qC5Io75HLrOqCfUaP4ngltajNTaPs0sziMTVAMP857VFqRCT2xXhq0A3VAWK21B6saEPhHJM=; 7:jy52wfYagRcHfI4JcFvpwVDnAu7xXrBkSm2grcJnF2BBdd0u12hd8h1JGxqAj3xGao6a+O+9hCJaTB4jiYZqG8x6jsxeoQvVlJY6toTl+stnwFLNaPCELprLfIEnh+J/X6r+E0JM2SErUMZFOlw0PqdhK86Qg2qMDTe3CMBw59/qwr39nlIvRNzO9vOSHmeIBKW3NMGJShgHHz7Jajj3+HobtCj64qXh7fDdARzJYTT1WnmAKfCNpA7aY+NZYlSj SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2018 12:10:22.5602 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f3facf7e-8825-458e-1473-08d56fb61880 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR0701MB2997 Archived-At: Subject: Re: [netmod] Missing references X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 12:10:29 -0000 Henrik, Benoit My first e-mail was sloppily worded. What I meant was RFCxxxx in the Reference clause of a YANG module, since I think that those should be in the Reference section as well. I think that it should apply to the Description clause as well, but that might be more debatable i.e. missing when it appears in Reference I would see as an error, but missing when it appears in Description, um perhaps a warning? Tom Petch ----- Original Message ----- From: "Benoit Claise" To: "t.petch" ; "Henrik Levkowetz" ; "NETMOD Working Group" Sent: Wednesday, February 07, 2018 11:56 AM > Hi Henrik, > > Could this check be added to idnits? > > Regards, Benoit > > I just came across (yet) another example of a reference to an RFC in a > > description clause of a YANG module that appears nowhere else in the > > I-D. > > > > This seems to be a systematic error that some YANG module authors make; > > can the tools be modified to pick it up? The logic is simple enough. > > > > The latest example is in draft-ietf-rtgwg-yang-rip-09 which fails to > > reference RFC5952; I think that the I-D is in the RFC Editor queue. > > > > Tom Petch > > > > . > > > From nobody Fri Feb 9 05:52:56 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35F72120726 for ; Fri, 9 Feb 2018 05:52:54 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id srYu6QsQ4A4Z for ; Fri, 9 Feb 2018 05:52:43 -0800 (PST) Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 01080129BBF for ; Fri, 9 Feb 2018 05:52:42 -0800 (PST) Received: by trail.lhotka.name (Postfix, from userid 109) id A9E531820412; Fri, 9 Feb 2018 14:51:16 +0100 (CET) Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 39F5E18203DE for ; Fri, 9 Feb 2018 14:51:15 +0100 (CET) From: Ladislav Lhotka To: netmod@ietf.org Mail-Followup-To: netmod@ietf.org Date: Fri, 09 Feb 2018 14:52:39 +0100 Message-ID: <87fu6axobc.fsf@nic.cz> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 13:52:54 -0000 Hi, here is my review of the rfc7895bis document: *** General comments - This revision is a significant improvement necessary for supporting NMDA. However, it is also flexible enough in that it allows for implementing the NMDA rules in an effective way but doesn't preclude the use of other datastores and datastore architectures. - Another benefit is that the new YANG library schema can be easily integrated with schema mount information. *** Specific comments **** Sec. 1 - backward compatibility Given that the old YANG library schema is carried over as a deprecated subtree, how can a server implementor actually cater for backward compatibility of e.g. RESTCONF clients supporting only RFC 8040? Could the same YANG modules that comprise NMDA datastore schemas be advertized also via the old YANG library? Or is it necessary to also have pre-NMDA versions of all modules? Some more explanation might be useful here. **** Sec. 1 - YANG library stability The text basically says that the YANG library information can change at any time. This has been recently discussed but I haven't seen any conclusion yet. I understand it is difficult to enumerate all the situations when this information can change, but it should also be emphasized that YL info is not just another subtree of state data and that it should not change haphazardly. It is like with database schemas, REST APIs and the like. Of course, these can change as well, but everybody has to understand that doing so means transition problems, broken clients etc. For this reason, it might be useful to set YL and schema mount data aside and call them metadata or schema information - even if we continue modelling them with YANG. **** Sec. 3 - semantic versioning Some placeholders for future inclusion of semantic versions in YANG library information might be useful. To this end, I would suggest to introduce a new choice node and make "revision" (or, even better, "revision-date") its only case. This way, other versioning schemes such as semver could be easily added via augmentation. **** Sec. 4 - checksum I think it would be very useful (even if not immediately) to standardize the procedure for computing the checksum. What I envision are systems that construct and process YANG schemas (such as the YANG Catalog). They could benefit from having a universal hash string as a characteristic of any particular schema. Just consider how useful the universal hashes are e.g. in git. **** Nits - sec 1. paragraph 2: s/informaton/information/ Lada -- Ladislav Lhotka Head, CZ.NIC Labs PGP Key ID: 0xB8F92B08A9F76C67 From nobody Fri Feb 9 07:07:27 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA756126BF7 for ; Fri, 9 Feb 2018 07:07:25 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -4.321 X-Spam-Level: X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=f7CZTz1D; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.com header.b=ecjdXTBF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vyzMARTrElIL for ; Fri, 9 Feb 2018 07:07:23 -0800 (PST) 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 F277D1200B9 for ; Fri, 9 Feb 2018 07:07:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518188841; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=saN+3X7/L4CA0t1F+5Bo9a5EVgToWj+S92uUZomYz0o=; b=f7CZTz1D+uaGT9lG0qZ8wgyTGB9RBMRjFXIjDuK4Qr7DMRfCrQfffC+9UddyeUko 2Z9iIMOaXSZvRoSfXjnQR4T3xIh8hGaR2qOO1EQBDxyrPMo3qXEkh1jA5aenSpMX H8ncR4B8DnIooknpBTIW8msic67X3Yzh5CUUAZN7Ick=; X-AuditID: c1b4fb25-473ff7000000341b-14-5a7db9282c6a Received: from ESESSHC005.ericsson.se (Unknown_Domain [153.88.183.33]) by sesbmg23.ericsson.net (Symantec Mail Security) with SMTP id 67.68.13339.829BD7A5; Fri, 9 Feb 2018 16:07:21 +0100 (CET) Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.33) with Microsoft SMTP Server (TLS) id 14.3.352.0; Fri, 9 Feb 2018 16:07:20 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=6+PWEXWY4ZO2EAT7JQVixkmF6qvk69HrnzEK1sOCnWU=; b=ecjdXTBFHuYHMcDTTtix+aaLLxy4B/SOJJVvWMzbAl6eFUFMJrX/Ale5RZOZGHPFetEJIM1xfgvPLSdyGAYrx/uAhfpEMtjwYrTTvIl6/3GwlTGt+XDXn9GotilHMsbqLmyhvmfiQU8DaJF0clozTwpa5JkXB+tJHr+gEF5kFqg= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.197.25] (89.135.192.225) by DB6PR07MB3430.eurprd07.prod.outlook.com (2603:10a6:6:23::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Fri, 9 Feb 2018 15:07:17 +0000 To: "netmod@ietf.org" References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com> <20180208092408.ir25jwkorxozq6gr@elstar.local> From: Balazs Lengyel Message-ID: <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> Date: Fri, 9 Feb 2018 16:07:11 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180208092408.ir25jwkorxozq6gr@elstar.local> Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Originating-IP: [89.135.192.225] X-ClientProxiedBy: HE1PR0301CA0008.eurprd03.prod.outlook.com (2603:10a6:3:76::18) To DB6PR07MB3430.eurprd07.prod.outlook.com (2603:10a6:6:23::21) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 94a8c564-ee18-49c4-645b-08d56fced04b X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DB6PR07MB3430; X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3430; 3:b2OWwXaJgIkI/YKaSEcK9j/SWBzlo3ictbkx1LT6SsDkuHf9glNS5yu3QCqfxlejsKh3mbnNTaVNpdfWPgYeXihu+WmJZktb+ecWeNvBmOgN3IyNX2mt3S6fwzWp9awysmzAx5p1SibFKvSPWss2VR3STuGybCxhox6ChrRrPkbT3GJj/3/YnKakPHxSek7jny1fvj5ztppsb6FI4004jtHR2Mz0kD4rSuGLieEOmIzMuNbcsAdw6K2nfbOT3yRm; 25:kZKd69sjCg6Gq2GswqhCjHLiPnpEIssNGAzWllR4Ow/8lkhImIbwC72Vk9odT95qWQnaXFOIBMjIDsoEIUt/7Goc//qZEUyuSvQX8tksU3xJON2l2A6euhPYjy5wNcBwc1N6YrB06t3ZrXiPcn7nt+RndFqocl5w4Kd/hepCxlFPpqdYgFsbw0a4GoMo38b+nUVHmmJsD2fSNk/KIhNW3QsUQta0v94zoUBISq3funuzY8kNrOt0slxszeuGEiV0h5GXalSfoMcoI8/qRLG8KuVEDGGydc0MxTAoogWArBe7af4CRAu4NjxoSdjLN2P6a1LCxCtOMpgeXldbCs4tPg==; 31:q/0lkG1lDC9BBHyBhO3DQrBW/L5rYhjxgCiwBRH4JR0WlDRP5IiMiBVBd++FCnCFMU3gGzP9CHHActq3T6M1yJM0lwpRP76F9e7BXMjF18bRursSznYPk2zwncYe1tKUdZrIZvbHo6ovk/3NdbXvRNEVFsqF7fyBw0zq02WnWUc9UyrJfeqQeQk21fhRumu5fkMBKibnG33hIrm92wy5KO/AqvR1K3YmSnGsP3Oh3vI= X-MS-TrafficTypeDiagnostic: DB6PR07MB3430: X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3430; 20:4mtl04fU0Ch7Vz7X4UanilY15WyfL08T+W++qlMWZC+puRRc9ikeGBUkf3cToYe5pcE0+0s7/b8vyhyPdxW6ZEmhI7PDJc2uJXbb/Wm9wwz10W+q8Qm0GCAoxl0xGzd3KB5a/4we+CC76iUK1YVf99P3/U7zJj5jsixkX7tfzSjPFvtKrYvV3AS0Tv1zTRAH50CcduMD5K+8ZrbE5bbVEDI/Cb3KxfzMIQBHe2k8P90gC81M9ui9agIEx0VmaeLgPApwoRo26WBg2kaqxo3m5Yirh47boIbt3n6ig/s4UQgwIaYtvezQrFdvLvvfNmWilOzvG7zPZVtBNDQg8L4eWI+Mh8kdnvaBywF2IPo7IUefnj7cEH/s42C2G9UcKDjFuGJQsoqnNwRCeNbDAifxX/77A6kbJAeDACMKoRvywVo1VU4D0JDTEJAVikUQd3jBOBjrhhPgQ3/qiPu9HGeCWjFLlrgkyZkFFr+geJrd1ib5Ira3gTGO5HYiPAJTG48D; 4:k8Ne3bwNukWZ23a0IwwYiC6fhveOmImkrco9dzZpqClMN8Fq371rZTKSZRQIjNH/FIw+4zbDClsH/n25YnS/L4CYOH9DHUSLzQTWZj8UsI8WAxgNa+NkXX4waZ8uMiAnNuInaZQxdCd6VmJeDo7fVci52QMwiAoYZmCcy49kesXhNyavWTE403If9D70C716bSVSAZVOLfxwMWVRBhI45motTvoC6/OEIZaZ6dAjFWNbttZVMOfD+FRgoobG/ecoGfHMEegu3feiPgoserS7mSWIWFIECR2goQspqDtSRAct3VBh629FCklmhsvhE1N3fohYGZVDbjZlpaZw5TJxA7frRsfL0EWXRYBIctmWnxVhATry7tO5gVZzyPVIZhuAuZrPv+z4/KhuvPqwVqm+28fOC+gE6ctzX5rt4sCH9WY= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(120809045254105)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3231101)(2400082)(944501161)(10201501046)(3002001)(6041288)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(6072148)(201708071742011); SRVR:DB6PR07MB3430; BCL:0; PCL:0; RULEID:; SRVR:DB6PR07MB3430; X-Forefront-PRVS: 057859F9C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(396003)(346002)(39860400002)(366004)(376002)(39380400002)(189003)(199004)(377424004)(252514010)(105586002)(15650500001)(25786009)(26005)(3846002)(6116002)(186003)(106356001)(8676002)(2906002)(6246003)(52116002)(2950100002)(86362001)(31686004)(2870700001)(2501003)(2351001)(7736002)(64126003)(8936002)(66066001)(6486002)(83506002)(65806001)(67846002)(16576012)(47776003)(5660300001)(49976009)(31696002)(65826007)(50466002)(229853002)(81166006)(966005)(478600001)(305945005)(1730700003)(81156014)(23676004)(36756003)(6666003)(68736007)(6306002)(386003)(58126008)(65956001)(316002)(52146003)(16526019)(59450400001)(6916009)(2486003)(76176011)(53936002)(97736004)(53546011)(5640700003)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3430; H:[159.107.197.25]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3TUIzNDMwOzIzOnVKSTk3aWJKUkE2UEtqeEUrVmRPVkRDdGJI?= =?utf-8?B?OHh4ck1iM2FyQ3gyVzloVk9DK0VtYWh2endzLzNOM3FwVkhRbkY0ZU94Q21F?= =?utf-8?B?eUEza0c1NElGRzNxSENCcHRrM0laNU5iTStoU2NkSzRWbHZJM2g4cXhhZ0J1?= =?utf-8?B?YjdQVWpVRllyckZpUDN2TVc3SDdhamdEV0gvOC8relZwblBmSk9CbVdoYno0?= =?utf-8?B?RS9GVXNGSGp6Tkt4aGh4ekF4bGF1dHE0TU15cDlXemFTMU9RS3Q0a3hLWUVo?= =?utf-8?B?Y215dk14c3d5amw3bUx5K0tnL2t1Q2lWaFVoRlRPSDZWaDZ1Z2NIUzhFRDcw?= =?utf-8?B?aTVjZFdYYXc5S0Y2cFZqSG01dkYvMDlhM0ZXUm9KTERFVVZSby9RSm55cVc3?= =?utf-8?B?TDZqUnhERU5lbnJrMHVoc3ErWFpDTjhTTS9Hdy9oZ0p6RmlFdFVXTW1kVWxs?= =?utf-8?B?NTlTRzE2Vm5VeEtsWEdpRStBU0s1d1Y5elROVUIrZTdpUk1vYk5BTFZYVFFH?= =?utf-8?B?SWhEcVJ0TFVDUXJITk5uRUgrNzlMSkJsZzc0MUFULzNqcHZXa3BPZDlMU1V0?= =?utf-8?B?SnNIMEFFT0RydnkvemYxRUNPaUZkVTgxYUcwTTZMQ0VTSlhDTEpMZ2RCM0Rl?= =?utf-8?B?SUdSQ2tvalkwb3g3UmhsYUY2d2grK2pGZldxYXNhMDA3Q3hUU1U4cDhVcytT?= =?utf-8?B?Q1hmQVlBK3dneStFTS9ieERnVHBjYU8xZ0hRRjlnd0lJWUQ5Mm1vYlJ6Yi9T?= =?utf-8?B?cXRxb283L01lZzBhQjJYczBONEMzYVh1TGxabktYeFpyMDVSaEc0Nm40Y0dR?= =?utf-8?B?Y2F5Rk1QTS9qYlBLd0VVZ0F1K0Izakt0bFRGUXJxdXJ3WjNTUGp1RnVsUUVz?= =?utf-8?B?Y3MzWUNXOXk1VWExWW02YXdtMG9qTU1SekU0NHFJZXlDZjNMeGRZRjBaRmQ3?= =?utf-8?B?aHYvcEVGSDY2Ynd3ZFlxNjFFb2VsQjlYeHJWbHBhMHdzVXphSEY3Z1FqUVRW?= =?utf-8?B?Z29YZmZXMWVaUXVQWnNJbTI0cXZhV1RiL1hXVFFaZDF4VGhVamdRd3llZjJK?= =?utf-8?B?RFAwZTVtdlRVU0phVzJ6blVqWGNOcFdhSjM5VFl1ZCtqbHFFZ2plS29tVkxK?= =?utf-8?B?VnA4RGJKblpxdGR1WTYrVXlmbGhnUDdyWmZObjh2R0Z4aS9XVzRybkZoRE5t?= =?utf-8?B?OHBZVzArbkFnRmkwdzRzaU1EUmNidWFNN0ZtUWp6Q01MYk1lM1NFZ2p4SFJw?= =?utf-8?B?T3ZHZ0lSK2hjRkJ6ZGthTEttYVlxNUI2UHZreHo4b1lZcWtpRWJLQ2hXeWRD?= =?utf-8?B?WWZaa3RFOHdGV2QvTmFOMy9XWks4SnhVbXpYOUIrTjMzNXBkQkRyeFNkYXNj?= =?utf-8?B?VVFWZlZRMm80WDZkMzBHcngrM0FTVUxKalQvaG1JczNCS0NsNnJvZzV5TEMy?= =?utf-8?B?MEx5U2NyVWJwR2N1b0R6OVdiRE5Sc3d0NmphV0sxU3BMaXkyQlE5WmJuMnU3?= =?utf-8?B?bXpnMkc1OE5mOGhnU0VvU1hPcWQ1eTQrVnJGaDBxbitSbkdLTm96Z3QvYnRP?= =?utf-8?B?am1UdzNxR1h6bGZyZmdZQ0E2KzQ2MzRzT3ZNTml5UjBERExtMkRLRTRnT1Rj?= =?utf-8?B?cUNVZnZVdENwN3lZbjgxU2NIMGJuTzZmcENxMndvZ0hLWHhRV00rZ0svYkRS?= =?utf-8?B?dHF4Q2hlOThpQlZYM2pmQmltcmxvVjVMTjlWcVJBYTcvOFlyU09BNmJOZ21m?= =?utf-8?B?VW16WS80Y0JXVkpNSDAxZVFPTGtBUDRxVE5TdHZwckplRGhQcDkzT2NRL285?= =?utf-8?B?MkdnbmE3QnJDZTE4TjlhYzI2bWRkUk9MY0pRMk45dTNzOEx6S2tMUEF1N0Y4?= =?utf-8?B?VXNXY2k4Mmd1WTc4aGhyV3BwUkZaMTB1Q1lnMkdEa29uZUE2OXNDMnV1ZGJE?= =?utf-8?B?TXllL1BxK1FHcWsvZG5zUVFnM2YrTHpCV203eUxHZHhUeGxwTTNkbW56cXVM?= =?utf-8?B?QzIxa2RLUE5QSW94SWxUZDRYVHJGT0w5L3AyU0crTVh4L0JDT0JWVEM1Z3Nu?= =?utf-8?B?bnpNcGZPTi9vNnozVkxaamJSN3pYaEFlNXg2SUZiZnkvaGRaanhkYWlRMjc5?= =?utf-8?B?ZEZubWtGMDdRYkxZZXRXN25HK1d4dGNPN3MvaEY1cjVuK1BUR0UxYWFKK3dm?= =?utf-8?B?d1N4Z1hnb0IxNHFqSEtVTWRLNFpBPT0=?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3430; 6:8bR54r1//YvDvTQVgYYnrTK+TwY2mEnVvTmQdRDGvunHw6n2pH6ihJxnQqSN+drKFO+lXHs3ckga8aniwgX5fVG6EclIdbsHUC3bwkkNwiI++gnuxdWBFrLMMjUSyBn6UUc+BKMC1ZLXbqQZ7wkS6PHgSI1KrvGNdOyqUqAD4oWVBhRu8MlsK+2+J7XsXEdYzZv4r0rb9qVr9MK+67rbTTlmnkilfl86irqy6DOAzjGtjVHXvu0jbrX2cYF15ezjpv8wMaRqpnyjqNgQ1A9JSAGjAKrCyaeqtwAPfjh5VBQwHwTGXe7wnzNhRSoUVgXJoutOIDvoLcs1kpli7yo6sqS63DUCOUtYy/RNlSV92rU=; 5:1rmo+VHzfGdkOCQmMFMHQTcdwJ4e04Gc/Q8BZ5ibUBZjEJvqIsIkvrLdXOF2VZ4jl/k7Pj7Dph6Lfjlg0ggByg8FJxIeaXyiuQ69sA6mngkg0viOLSrCU4BCFoRGsAuga82yt7OJFoae/9dOi1Wgu4JhOcrx3F+Qmh2m/beSWt8=; 24:AHiKLR+bClovLvBxgFTzqqkl+JJOtiKx+gQTZ+fqAbiIs+n/xzIxZB+JuQZh2hNMpMxfF7NPdOEfhBY7CMU3Xi0ig8RmHDHOLmQ71paxSuM=; 7:DLAimSGHKl161v579MXHDrDsuCz+zhBoi8WZR2FtzdiPSHNgYaZiyZRZFY7AigJCShjUw2X7y6JDwGEtte/ajwSEvmio0myQkGcWuJ81Az2IKHoY0UR+a+tXJf4jvdrVYYyt7N7i8dfFb6F2vnpXjiYtxpUPQDbsFC5Sv1F46S6zIlnG/qh/jHdpilHk7Byoc0M2EamExb4BeL6NmRNXbUvh4xqa01SfoKW302j/Nwauhga2HqCZ98vPj00xiIRq SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2018 15:07:17.7591 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 94a8c564-ee18-49c4-645b-08d56fced04b X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3430 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUyM2K7oq7mztoog4mPOCzmX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxswPB9gK5itWHJj4k7WB8YlkFyMnh4SAicTayc/Zuhi5OIQE DjNKdF8+ygThHGeUaL+yjwmkikXgE5PE1fPcIDajQJzEzjULWSGK2pgkHu76CORwcAgLJEvM POQPUiMioC4xc+d6NhBbSGALo8Tf9gwQm03ASGJq/3kWEJtXwF5ixa3jrBDzVSR2vtsAFhcV iJGY+nEjK0SNoMTJmU/A4pwC1hLH7zcxgtjMAhYSM+efh7LlJZq3zmaGsMUlbj2ZzwTxmZLE pS/TWEDulBCYyihxe8NhdoiDNCQeXvjLClEkK3H07BwWCNtX4uO8d+wQDfsZJY5eecAI4TSw S3R2vGOEqNKS+HLuBxNE4gm7RPPbmVDt2RJnz0yFGpsjcb37OFT3DGaJ+yfvskMkZCQa9nyA 2vGATeJq13+2CYzas5A8OwvJg7OQPDgLyYMLGFlWMYoWpxYn5aYbGeulFmUmFxfn5+nlpZZs YgQmioNbfqvuYLz8xvEQowAHoxIP74lNtVFCrIllxZW5hxglOJiVRHgvrwAK8aYkVlalFuXH F5XmpBYfYpTmYFES5z3pyRslJJCeWJKanZpakFoEk2Xi4JRqYORdUd/DsVijLJLrn/Y2jT5X Lj9zpyfyHhrPdnJcWSm+V+3wqzOd+T9D3iR7b3i5VVdgzSML17cFJ7x2b7yf+qAnatKxV1ZL 55z52HEzK4/D4c7nXw2H1ordlpSd3i6wdYXu/8WVxz9W/Vz8rKkgZLLtCbupXKZtbz7a+/u4 3zl64FLHkUZdA18lluKMREMt5qLiRAAUv/DUEAMAAA== Archived-At: Subject: Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 15:07:26 -0000 Hello Jurgen, I will gladly add NMDA to the draft. However could you please be more specific. Which part of NMDA are you missing? Is it the example of yanglib that you would like updated? As the instance-data can be used to document and/or load    both config=true and false data it is IMHO relevant to the candidate/running/operational datastores. However whether it should be used to just document data or also to load data, and how exactly such a load should be implemented  is out of scope. And yes using one SW kit config=false data can be loaded from file too. regards Balazs On 2/8/2018 10:24 AM, Juergen Schoenwaelder wrote: > [Removing NETCONF since the I-D says -netmod-.] > > I flipped through the I-D yesterday and I think a common format for > instance data trees should be NMDA aware these days. > > /js > > On Thu, Feb 08, 2018 at 10:17:25AM +0100, Balazs Lengyel wrote: >> Hello, >> >> With Benoit I prepared a draft about how to document and use YANG defined >> instance data. It could be useful for documenting server capabilities or >> preloading data defined in implementation time and probably for other >> purposes as well. >> >> regards Balazs >> >> -------- Forwarded Message -------- >> >> Subject: New Version Notification for >> draft-lengyel-netmod-yang-instance-data-00.txt >> Date: Wed, 7 Feb 2018 09:28:50 -0800 >> From: [1]internet-drafts@ietf.org >> To: Benoit Claise [2], Balazs Lengyel >> [3] >> >> A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt >> has been successfully submitted by Balazs Lengyel and posted to the >> IETF repository. >> >> Name: draft-lengyel-netmod-yang-instance-data >> Revision: 00 >> Title: YANG Instance Data Files and their use for Documenting Server Capabilities >> Document date: 2018-02-06 >> Group: Individual Submission >> Pages: 10 >> URL: [4]https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt >> Status: [5]https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ >> Htmlized: [6]https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 >> Htmlized: [7]https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 >> >> >> Abstract: >> This document specifies a standard file format for YANG instance >> data, that is data that could be stored in a datastore and whose >> syntax and semantics is defined by YANG models. Instance data files >> can be used to provide information that is defined in design time. >> There is a need to document Server capabilities (which are often >> specified in design time), which should be done using instance data >> files. >> >> >> >> >> Please note that it may take a couple of minutes from the time of submission >> until the htmlized version and diff are available at tools.ietf.org. >> >> The IETF Secretariat >> >> >> -- >> Balazs Lengyel Ericsson Hungary Ltd. >> Senior Specialist >> Mobile: +36-70-330-7909 email: [8]Balazs.Lengyel@ericsson.com >> >> References >> >> Visible links >> 1. mailto:internet-drafts@ietf.org >> 2. mailto:bclaise@cisco.com >> 3. mailto:balazs.lengyel@ericsson.com >> 4. https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt >> 5. https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ >> 6. https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 >> 7. https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 >> 8. mailto:Balazs.Lengyel@ericsson.com >> _______________________________________________ >> 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 Fri Feb 9 07:23:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B20D126C0F for ; Fri, 9 Feb 2018 07:23:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VxnbDKYJS7yI for ; Fri, 9 Feb 2018 07:22:57 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0109.outbound.protection.outlook.com [104.47.2.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 590821200F1 for ; Fri, 9 Feb 2018 07:22:57 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=lQf8pMg0qtw4TmEGWvhJ+bGWXQaJVKI/4Nxge3vKUL4=; b=Ap1twJNwl5GyQuJEC0FdtsDTcyK4omNwZ2Duf84nDvg6tztnuov0NZfpqkIB0bPf+V8JyzigxpP+k5TORPxzgukQnxRy9fHT7IdNW/qrfOdH9DLOKVGzMAj/SYrxjd/Kh4Ms3v386WZfDGWjQd5HnUG8BZFZraL4lTVAApYEZ1I= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.176.21.219) by HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Fri, 9 Feb 2018 15:22:54 +0000 Message-ID: <026001d3a1b9$9d382340$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Andy Bierman" Cc: "NETMOD Working Group" References: <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com> <6BAC6B11-90A9-4CA1-AE53-FFAC084FB76E@juniper.net> <5c2ae0a9-b4b9-3d13-395e-1c779f99f941@cisco.com> <01f501d3a013$72e66180$4001a8c0@gateway.2wire.net> Date: Fri, 9 Feb 2018 14:36:28 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.176.21.219] X-ClientProxiedBy: HE1PR0301CA0006.eurprd03.prod.outlook.com (2603:10a6:3:76::16) To HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 26380124-e5dc-47b1-a8bc-08d56fd0fe25 X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603307)(7193020); SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 3:VYE007+w1/Y6ZaQRavJZmd/3fHegzUQ/IM67pfHb1TrKi3HfXIMYZK/DiQBkvrYHxb1wbDMBrcymBgc9mI22MqMKeDv+HaZ4UKNI0OAoZcZ5sPK4IMN7p78e9DSibdxpNIVRqrVPWDg40Si/HKwpgJLTY1hbFvK3SGP3y/PG+bZ0c16yVeHW9w4kE+Rd+I98fH7/9+cP5H5QU4zZXxe19TifBXYj4pHbEToH8iz3g4EAsXbkxcDCTGnOsjVfJvb+qxQ5OFoA12YQQzwwUuP5SVAtaB8ymNui/fEiGVYVB4M=; 25:pRbFmTjJwruPccUShFnVLkQLdKlb8nsB9PLPf2anSk/+d99FX+/qxycoy3e0wTMsKxC5PS15BpFdJA3b5FkwA8gEsRUJ+bf2XKpG/0cuwgPQcCD68fWQj2OZZdVGBpUEWPwOjfu0CNgOzB309EDYkBxQkMAepNEqZc0fPaJC4VMzep2vBCOaaG1+71YBWe8UQU+fuhi8KmMm7Dd3x6jx9J4RWvYT73tvuMw0NWgMFARDtfWoISw8ARpg/Sf1fDJMWpnxvaaQmCcTaNXE20qeW/8E5dAMoWgIdMCl6d5kUc7+R0psOHxBCL1mu4iG61fh0bGTtXWWspgLw0OSQswVbA==; 31:V5sVY7dwhr7CO7m5YT3yiuqNhBFXKKI6HmwspI5RIMauaJc3KvfQTbA+HOKzLX97uQNPYe2IcbhBkxgFKia8ByMxhGgQP0RhxmT6TtfkquBMjmlBdF/C5uPkXMxPcBRUD0vUvH/AaOemo6m/oF2BA0+T9KzpEiiBkQnod7pIwAojWT9vZU4MTlS2AMqVNmkdDSzfYx9yv5/BKqCW9+BLAkXwf13SudvKFU+oiu4vC5s= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3003: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 4:sO/GR6t489OdVxgWXpFgbHWeYYZDy0TMWyNdQPJu/b0kxxe7Rkn93RqJaWgTLsMGx5JzjGvFOErohwRWsTROalAtScWXc0R3rJhmmwqnjAPAdpri1pf/w9rZIFA/Crt4eEG+VoUCOGNPD2xBkc6PcR+Cu4hkyj1JpGGaeN6znwPCdsmyfetI9IwmAh6v2PkTzGsia0UPjZZle4Dn2660y1pzxJIyUQLhi5XRMm9BHcjTiUZmlBrKPWix+vTYiPn2/pPFep69jrYUp3aU7Q5qQbngIUPh6lqMkqftbo/NM/nesRm5cJmplDO8wxdgs3MW X-Forefront-PRVS: 057859F9C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(376002)(396003)(346002)(39860400002)(13464003)(199004)(189003)(52116002)(1556002)(2906002)(6916009)(305945005)(84392002)(9686003)(81816011)(6496006)(229853002)(50466002)(33896004)(7736002)(105586002)(44736005)(93886005)(230700001)(81686011)(86362001)(6116002)(53546011)(26005)(23676004)(47776003)(2486003)(3846002)(53936002)(14496001)(106356001)(66066001)(6666003)(61296003)(50226002)(186003)(76176011)(81166006)(59450400001)(81156014)(25786009)(8936002)(8676002)(4326008)(478600001)(316002)(97736004)(16526019)(68736007)(6486002)(6246003)(44716002)(5660300001)(4720700003)(386003)(62236002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDM7MjM6OERid284NHJrZkZldVlOenJKYXNSL0hJ?= =?utf-8?B?eVBzS24zT3BIUUgyOCtwVVEzUC91UjR2Q3FKY2cwT1ZkeFdlOG1malNHWUl1?= =?utf-8?B?M0srZjExN2k4TnRzZUQwQkFoWmVUSjBHOVFESTZhZXZRa0cvM3RUdTIzbHRl?= =?utf-8?B?dkVaWlpQcnB5UTFBVkEzRnpSMml5MmR1L1czS0paYjMyZ01yVnBZZFBMdFRr?= =?utf-8?B?elFFbFBieVR3VE91WFBrdWNkVktSUEcrSDNpQllNcG10U3Zrd0Zra1Q1c0ph?= =?utf-8?B?clp0clVNU0RpRXVyMHlnb3BOOTlXSGNkMGtvaDJxTmNvZkhPS1IvT1NId25X?= =?utf-8?B?Q3UzK3ZhT1FJM1JaclJxeHpBVlU5WnpFUkYrQnFZVnU3R2Q5OGViSnpHa0R5?= =?utf-8?B?TGpldlpJaGlDblZJemduNmJHam1nZHdldUR4U2pVK2ZaUk9MK2xYazhGc3R0?= =?utf-8?B?d1A5Y25TdXdXNDVHUHRydEY3RDRzWmNEVU1IOFAvR3JCY2kvQkl5ZHlTK3hO?= =?utf-8?B?ejVJTENNeTRteUR1cUNVSVJBVmpmYytHUk1NY01YTk5iMUFjSDllTEVWVGho?= =?utf-8?B?MmdIV0lNa2JvQndDTGhJa0RmL1EvM0dDVHhiMUtiK1A4YmFsQllNblluNHd4?= =?utf-8?B?d1g4WFNud21yTFlEb2hJcVhRQ1BrNDBHYnlCMFlmeGQxSHEyK3cyZEE2am9p?= =?utf-8?B?cSsvTjkvSnoycmpwcndoK05rM0VkaTJORi9OeTFCRSt2MUZnQmxKdS9FODAr?= =?utf-8?B?Z016VnRoUHAvZDR2VFdiRC9qRjNldU1zRjNXWkdQNkhmVWdNNE1GQ0VyUEpU?= =?utf-8?B?WEdETG1ZV3dsTnRkQ1V5VWt4VGtYTTZKb0tRNDNpa2kwRWZUUUJYZEJ3cW0z?= =?utf-8?B?QWlxdUJteHFMZ0xsaDhsZ1ZqdUFoWjhwWWJVWGt0eDRwVGhvMVg3ZjY4ZWZw?= =?utf-8?B?aDQ4d2IyUFdwM2Joemp3eTVuNnYrdVZiUUY2cTFLVE9LUitmaDJaNFVxLy83?= =?utf-8?B?VmRuRlZ3bTllMlI0QlY4SFJjV0pDSklNWTBDem1MZkpuaHdDUWQ5UmdjdUFI?= =?utf-8?B?ZE1LQy80V1M5eWV3UGhLMVcxV3R3aWcvT1BiVHlSbytpRTVjaUtBMVl6c3Nh?= =?utf-8?B?RFV6aElQbkp2WFF6aitJL21tSTUrQ2dUUFZHN1hETWhjM1ZSREZ2NFVzWFhm?= =?utf-8?B?MHdGNzFZU1FRWTZwcTNZZjd1UUJRU2RkZWU4VS95dXZZWXo5bWZDVG1mM0dN?= =?utf-8?B?VjhxalRtNmtRMUozdE1aMFJtS0RKSm1zOXBZRmZKRGpZNXlYQTNoN0h4MXVv?= =?utf-8?B?ajA2MXdpVFg0YTlHVmFqS2pUb0lEWGExNXc1enAzVUIvbWRQZCtVZHVjU0l0?= =?utf-8?B?RXZ6b09CYWtEMThsRVZsSEppd3Jabm5sa1pSS3RLT08yUzhIbXhPUlFiQUsx?= =?utf-8?B?ZVdZc1NXVVc2KzdmOXdIdEQ2akJ3eEJNZGpQYmw0QUQ1cWtFUkVPQmNhKzZt?= =?utf-8?B?Ymx3UVFNNXlQTDE5UmIzQ1hzYkNnSWN2dlNNci8wNDNueWNVU2taMXNSS1d6?= =?utf-8?B?Q2UrckUrTzNEVDFpYzdVenl0VnovS1hXeGZXcVl2c3h4Q00xMi8vRWp5OXdT?= =?utf-8?B?Y2xNZ3l0TlI5TmRQelFpY1VkQzRueXR1VVZVb2lPYkNWV1RZcnRuTyt5V0lq?= =?utf-8?B?V2tzWWphZjh0YnlKdjhNNXUxeXo2MGpncE1nY3BVR2ZUQjRPcGdrNHZsOVFT?= =?utf-8?B?cWowMHlMWUNDaFpLRUs3Sm5yS0xNWjZCME5aQ1dpS3dHWHdqSUwxRmkzTDg3?= =?utf-8?B?U3hHanFxOUlHSDdCdDVYR2xYY2xvNzRwRWtvVjVYdmlJcXg3dzdFc1JVUEpM?= =?utf-8?B?Z3N3bXlSNWtmcVNwam9kS053ZWNTUlZGWmJRQ2w0bG1kWjhWSTZYRktxZThH?= =?utf-8?B?QmRISEZvRmxIaXRpTHdBdXlWSjh2alNiNWdnTTlZZms5Y2FZU1pyTGZRQlV2?= =?utf-8?Q?0oZNWXQR?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:Bli7IXAYKKL7ijSpErygXvLslR/MU6teqW7EEkHcTvFr8j5NY9dJnwipodBk1oGKci79MS/Y/2tfgJKXJi3frvmHuOoTyj0aJCR1yf/c2peFcvT5rL7I5BDEXlKlmY90o29s5ouXmbbOyY/C1Jf3V0gaYegWFWliE+LduOhq/OBjs0q5waHrCS86siGreoGK1yzYfIScndn5JdWjlZZtNEPokZJDC7+4dOSn5pjyB6sepRzUWf/zsYInb8Esit95ilfHLKsQUO8vf84RY9mRibGUJfBfjMmxaPskvExmRqS0gkYKT1tRmLA9RsKif0d1jAB3SCgC/1hUJt3IJCecShYOStLyBCg77RQiKFOppqA=; 5:nSFlrdheqzUSSiY+oZdLDEuaaEX8qDYuV4AbR+79rID/J3vY2agMlSjm1q0HvFFpusO0vo/fbs6k7IArSDWyX/psbJ32vKOCvUhDmM43/Pt0MJeDoOqhwqa5oRVEjOUzXJGoJyutWlZd7cTbc8R60CHT+GWciIF6aifqiIbkzJg=; 24:RkFUcrQgo21aJCqXSJqEuwMtn+hFGABZr7SGPvVZbW1bjbxiPkoA0XrI6NQZGpo9etEyKBuwn4giCgm7x9PlDD2tA6orvDDr/Em7qrxofpM=; 7:K/w5Gc9RsM0DVfA3r9F/CAO2Bw+Pu3XMxKQ6LXTQX/1CEZgSxZ1fbrrtsexvl90iz3E4EyjVVe25nmjmMro/RZFsk7zE/yFjNuQljwuevPwXvTswzO+1J97ix+qMhHOKIUaHAmIF+gB6Oz+lx+aAZxeoSoKa8IwsGCzN8Ly6vCnqiHfYi4CI4/8D9B4JFJ7gNfm9NxLxxT4QGxtxKoJwpLQD+pIua5Co1vUwV5DjXoaeQ1UfBDj31xmGs1FC18GG SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2018 15:22:54.4304 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 26380124-e5dc-47b1-a8bc-08d56fd0fe25 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003 Archived-At: Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-16 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 15:23:00 -0000 ----- Original Message ----- From: "Andy Bierman" Sent: Wednesday, February 07, 2018 5:48 PM > On Wed, Feb 7, 2018 at 4:58 AM, t.petch wrote: > > > Andy > > > > If an RFC is mentioned in a Description clause, should it also appear in > > the related Reference clause? > > yes -- there are many places in 6087bis that mention the reference-stmt > > e.g.: > > If the notification semantics are defined in an external document > (other than another YANG module indicated by an import statement), > then a reference statement MUST be present. > > I cannot find any text that says it is OK or not OK to also put > the reference in the description-stmt. Andy Just to be clear, what I am seeing is RFCxxxx in a Description clause in a YANG module but not appearing anywhere else in the I-D, not in a Reference clause or in the I-D Reference sections or anywhere. e.g. in draft-ietf-dhc-dhcpv6-yang leaf uuid { type yang:uuid; description "A Universally Unique IDentifier in the string representation defined in RFC 4122. 4122 appears in three such Description clauses but nowhere else; I am thinking that it should also be in a Reference clause as well Tom Petch > > draft-ietf-dhc-dhcpv6-yang-05 has examples of this not being the case, > > as I mention in a recent post. I assumed that they should be but cannot > > see any discussion of this in RFC6087bis > > > > Tom Petch > > > > > Andy > From nobody Fri Feb 9 07:23:16 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E9430127058 for ; Fri, 9 Feb 2018 07:23:02 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.921 X-Spam-Level: X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8oz6Aa4b5oka for ; Fri, 9 Feb 2018 07:23:00 -0800 (PST) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0109.outbound.protection.outlook.com [104.47.2.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9385126BF7 for ; Fri, 9 Feb 2018 07:22:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=jhWyI8/+iOQ0BWtKvSZOaVKOGDZ7w9g1BJfB2y2kojk=; b=RT9H8g0OZBJvZFbfHrCXvgzSzG7AKOq0gTSs8KDyM2T7KeiI0AAG5QKSWAlYZW0ocLhW0aX6/Nx0NbdxpF72ZhkPiDduazdhjE/QfNk522JhTFn0HAeoSvTHpuGeBUC5kmHfvTMJouV95Q2z2VfNXOvu18iCWHbWxC3Br/HGBLY= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.176.21.219) by HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Fri, 9 Feb 2018 15:22:56 +0000 Message-ID: <026201d3a1b9$9e7ead00$4001a8c0@gateway.2wire.net> From: "t.petch" To: "NETMOD Working Group" References: <201802071859.w17IxjwU073675@idle.juniper.net> Date: Fri, 9 Feb 2018 15:19:40 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.176.21.219] X-ClientProxiedBy: HE1PR0301CA0006.eurprd03.prod.outlook.com (2603:10a6:3:76::16) To HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 54e7d433-ff4d-424a-102a-08d56fd0ff71 X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603307)(7193020); SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 3:R+9FRChj8nS5RHYvZT14ihhqY1RuF6PRwW82ZiyPuTzzGsDOylCEw68ub6DjyQFtvhc3vV4+POEk9zD1B4IwsFfjZtBxAzLAl+/Nz/km2Ieyvgn8nbJA8y3tjvbmOmOhUMQ1XX1x8fJwW3f+g5XZwwSpf5Ac6/WIMtXnJG7kovxh99iA0068q5t3ZZu2mrw6DfubKHoOZupUl4sb/772wSUOz1k9JH0GsNmeCyfGv4hH9to1N40u5aJkbFNj4i1/; 25:vGUc0FOS/pWSUrlZlp++h6iZgBahS4+DUCdwk4kTFRe63KfbjsgS5dSwU1ljoKrhvZ45EAF1UthLnqGlZBfE+jKgQWVctMq+QUPgkicNKz/jFRQudWmdaPIiXj3nJpYQUftrM3a8tx3/lz7PnTm1GXejDuLqyr3dE3vx1solD7i4m6kV4FUPiiIQfqjPgl4XHpF2h+XsUztiHbSAMrEAS+isfcf+iU7F3dt4qiLfoaRRTrpKiUpO+c8WLR/3TlUYPMRbFmDeBY+dgRWKQ4Gxsj1eUg9B2rJcHaAoTcjvKqj/TyaGy1BHY3ESpfKqxMgIV0SBVi/r64MeVd6RrxnL5g==; 31:NIIAufg/LEf/Ze6OQBbVqIEQFH47bfkYnXdni9FT/1eQTc2Xlr67hYSCm5lwyrzQOZt3esDA6eH7kynYvgylLhXGuA1LO+Eq8a1/M4fu7YGfq8UMFtERSJsbSAwGuK7wvDZCZpAw8RCsAARaSIKYM1ia/D2KlEsNX+I5qVKhLv8NO6IcJHnGwaAVBEqOgY/p4JuRfNydXlA5oS6/lRE8Fs3em2jwvctibcz7lHnzlAE= X-MS-TrafficTypeDiagnostic: HE1PR0701MB3003: X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(278428928389397)(131327999870524)(138986009662008); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(93006095)(93001095)(3002001)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 4:Vt80/WBk/GIdtDRcsHqOgBon5KRDxkO2Fn+isRQisTI9H5hzk4Svx05B+kFN9NO/NbofZBx2qdFB5PIlrJFuI8/4+mLJts7+vfnR+eFA/0ic0jjJYWm9Eu8zRpPDEIUc8C+SEBdcYkN+iIxGRGUPn28VKhMlY4Jboo14lgWsSJVP/1xcKqDxB87rgLsOKMPbJ+WFu4nd9HFkYHiYmuxYctwIT2L/+ImDZE8dUeJjAPbMCjodoRHNUq2chlCPF3X16pknBC0Pi3n0PfS5od5LwrEDKt9KlI6KeBqsoIwRBR5Yq+9JFxDLQ08Fs7OAy0QMQfK/Xiq2FHuhsois2uXAvmXBHatFdVWSVDujkM1wIKCN6e74OoaDhu8ZaDlNmrad X-Forefront-PRVS: 057859F9C5 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(366004)(376002)(396003)(346002)(39860400002)(13464003)(199004)(189003)(52116002)(1556002)(2906002)(6916009)(305945005)(84392002)(9686003)(81816011)(6496006)(229853002)(50466002)(33896004)(7736002)(105586002)(44736005)(230700001)(23756003)(81686011)(86362001)(966005)(6116002)(26005)(47776003)(3846002)(53936002)(14496001)(6306002)(106356001)(66066001)(6666003)(61296003)(50226002)(186003)(76176011)(81166006)(59450400001)(81156014)(25786009)(8936002)(8676002)(478600001)(316002)(97736004)(16526019)(68736007)(6486002)(6246003)(44716002)(5660300001)(4720700003)(386003)(62236002)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; HE1PR0701MB3003; 23:YiX/rcub8ohME+x3ML2evhmZf1ACrbDtU5K8n?= =?iso-8859-1?Q?jqFWORv26DvPrMxUNLIn5FZ074IfEmrwwKxrJ+Bx9iej/T9J/TpWE69HY0?= =?iso-8859-1?Q?ebNDL8NW3cJYC2NS7hB8n6vy94LQ/xh7tN7o4EgXE1WMp4hA17Zxlfa+tv?= =?iso-8859-1?Q?41lpiT0unZwFdKXgfaxJ32gwASwUKWX2S6OQCXnqflm/RUtGAZo8TyPLmI?= =?iso-8859-1?Q?6FDkqbTu2fgFQ9nNzCiYvuSaLAKm/AHslZIL/2hL4bmix8ve0F+kedjwRs?= =?iso-8859-1?Q?rO3sqPXMvixp+mPkpYfYolL/MrgCKGYymr05SBoWD8GXNuOVmXRsAkGM0O?= =?iso-8859-1?Q?9wL/6izAUJfyRPGnGBwxkt7JcJm7nuvEdkVlv96h6UhGS4WEk5O3E9cIum?= =?iso-8859-1?Q?dliQ0YvhhMAECdh+5AlkEiNJuUcrSUfPFo67r7hAnuevJkYHHrepg1a2Dq?= =?iso-8859-1?Q?oMMLxAfKWX8jXqidE/TfD2u+aYRd/9qilOUh+AUhPJsN7/RNMYoqnT19DG?= =?iso-8859-1?Q?9OeBmAxSzDOaKsdBV0pKxS5KTM0QK/2DMuSnkBnhCYmJ1iZL7AjFgWMhIA?= =?iso-8859-1?Q?ZsBrEVsPQMMg2s7e1qBeh7FqS2AgQyHRcoLbQ6/L1Mz8GqNOGgJXgZaTPw?= =?iso-8859-1?Q?7U379VRkJ01P5SkcjG0CqTt+cVgBeirBwfny8zlxkBbnLXQ4w2fFuF+Gsh?= =?iso-8859-1?Q?TsySLIfcwvDfvgGfR5qVQVeZ0OpXgR5KmalVmvn/+VVBU7klEucu0Mf1eg?= =?iso-8859-1?Q?0V66jbdqdWbQdJ9PG8ziTRK+D4mesQ/PYjDmi7IR0YQKm/dgSk+GKqE+Iv?= =?iso-8859-1?Q?kYHm6jsl+bK4oyZ+CcSVbUN3q14qltd9Zi+Y3xoofnl+x1yuhM1nU4wOlz?= =?iso-8859-1?Q?cdW0AOolXLmf3AJ5RzI6CMN+RNiA4AsSUS55uoYjOWWAQHWyca3n2dHicc?= =?iso-8859-1?Q?+MB98fGodigieEm3SHSZmkE2h0hm8xwY4pc94xgtSc9I8VqHjf3Sr3RONM?= =?iso-8859-1?Q?cB5NyzPvkAqxy3TnzKtqx0/1Be+awN0GDIOIxLJj+VPLVuE6h/ek8ePTgh?= =?iso-8859-1?Q?yly0MWCmYR/R4+ued9C3myGYJ+r8qPkAyZ8p3A493gEaBZ+cVUcUfGxVgo?= =?iso-8859-1?Q?rU6vrR8SeXCvYNc5gOyvHH0hew9s/eK0gzXjn0TCfMdRVTF1f4SvYMgCQM?= =?iso-8859-1?Q?KbdS+B3GXpyl9NsANHWd+zkLDzckOdX7rKkUUO3A+a0IetixfEcqCH6Hj/?= =?iso-8859-1?Q?ml93E3cXoRkj4z5R/GM/PadxTL2CsG3bJq8yQc2wN5tpibKXwHu+dbX8Sg?= =?iso-8859-1?Q?2vgX2xDJl0BVpD5uNzdJkjnvbk1rBdKnY7wa0WlLfJR//ccOzjhQlRIZoO?= =?iso-8859-1?Q?rsEQTyjOp4Mxbf13uqallmF1B4MlvRFlZPIGYyyO4a8953+z9tJIXNUy5b?= =?iso-8859-1?Q?6b+2/nNhWJ3tzyUHZ7+gkYzeNxx8VZFrXwZVIIByaJ6QRn/npUl9FX/NKI?= =?iso-8859-1?B?UT09?= X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:jgQApFGulxIqPG0oKUZu3R9ZbeALYWWgGh8y2GTpvXhl/QLuAHXj17qQaRVg+U5bC4tKrL5bWomuP5IOtMngq9pNhwvkJkyAdKdxurOjMgq979B4Yzy3j6wQTF6W+g7f8Py4dbERG1BfdFQ6PGnuBe7xwb+069qt8BmuD/aqoCdILQRpwFJzL1KQdAFT/mblQdfrbu4xeVn6/7zp44YaOUBEQPWeRhX5nVR/wU+sgYcp+2qjyrygCBMUM4LGOF1GNOr1HMI1xQNBNuEhCPHCAfm6CLze34dHtsjiAGupkW/aC5+SsOvjPgckaVij5P8IskUf5MUumHvLv5w18cRwgv5U3GUt0iSluqd6v8JhNjk=; 5:UdXXGza77CRonG1n6mc689EvOfBT8k0UTGQwu/y9rFv8rUECRcCucWmgIVDRhQzP1Yr2gZBSEIl0joPp68qWW+57pJtUk+2fjaE8LFuUnk65laymtIKWo/IrFTuFkaj+v5svwYBqM/5a/Dpu1Z0JD/wgcgipd1LiwMVxFY2nQG0=; 24:ds3nIqwV+ZVusTWKxis3HF1IEN78/rEixBLxBrMkehN6kruwat2jkq5iDTdOLbzk3uQsmH+HjyTb381+jmsIjksUnP+dB5rA9+bVZdIroNY=; 7:VNeRktViz08Uo6gNGnz3ms72yE9GtoZqYzSIXKkBqRTmC/zTM1DG5fltE2nq59CASr37rdNTsoZ9VJSVw61JqwVcHodrKBRXboZCqMbGllh7jB1yKRiRy3iLJpNWCwe5lxwgOUpJR/kqtMBo6tiVItOrMCn5LzPCqLm5iaPY64tWufCGauauNyN3HcuJa/BZlhMeVU2+NFwAoWqN8LzVa6Tmg73lHOMm9VCZfi3xF90YlYXd6zet7OtiHRbnjQHN SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2018 15:22:56.9617 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 54e7d433-ff4d-424a-102a-08d56fd0ff71 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003 Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 15:23:03 -0000 Oppose adoption As others have said, there is a lack of a problem to solve. When I ask users of a technology that uses #hashtags where they come from, how they come into being and similar elements of procedure, I never get an answer. #hashtags seem to be provided to allow a storm to gather on social media, around some vague idea, in order to put pressure on someone or something that would otherwise be unjustified:-) The tags listed in Section 10.2 seem just as vague and I do not see a role for something somewhat ill-defined in YANG. Tom Petch ----- Original Message ----- From: "Phil Shafer" To: "Andy Bierman" Cc: "NETMOD Working Group" Sent: Wednesday, February 07, 2018 6:59 PM Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 > Andy Bierman writes: > >The draft avoids discussion of any useful operations based on tags. > > Nor does it really clearly say "what" is being tagged. The absract > talks about "used to help classify and organize modules", but the > Introduction lacks any expansion on this. There's really no clear > problem statement or a clear definition of why we need tags or what > one would use them for. > > It would also be helpful to understand why "#hashtag" and the string > format ("ietf:routing", "vendor:super-duper:...") are chosen over > YANG identities. It seems like identity naming standards and inheritance > would be good features. > > Also it's not clear why these would be configurable rather that > controlled by the module author. I'd rather have the OAM standard > YANG module say something like: > > module ietf-oam { > import "ietf-category" { prefix ietf-category; } > > identify ietf-oam { > base ietf-category:ietf-standard; > description "This module category represents something > OAM related."; > } > > ietf-category:module-category ietf-oam; > ... > } > > The draft says: > > Implementations that do not support the reset rpc statement (whether > at all, or just for a particular rpc or module) MUST respond with an > YANG transport protocol-appropriate rpc layer error when such a > statement is received. > > The entire idea of NETCONF/YANG is that the client _knows_ what it > can safely send instead of tossing spaghetti at the wall until > something sticks. Avoid programming-by-error-detection, which > creates fragile infrastructure. > > Use "feature" to control optional portions of a YANG module. I'd > suggest one feature for "reset" support and another for "read-only", > since IMHO the idea of someone munging the categories of standard > modules is, well, disconcerting. > > "Local" tags are not well explained. The idea of a user/admin > tagging modules means that something is broken. Users shouldn't > understand YANG modules. Users use applications, some of which are > home-grown. Is "local" appropriate for my "audit interfaces" script? > > 6.1 is missing the list "module-tags". > > 9.1 advocates putting vital information in the description string, > which is IMHO not a good idea. We want to put as much information > in machine-readable format as possible, so I can ask ietf.org > questions like "give me a list of ietf-oam-related yang modules" > and get a nice list. > > It also talks about "SHOULD" and "MAY" tags without giving any > clue as to why or when this would be appropriate or useful. > > So my vote would be that this document needs some significant work > and expansion before it's a supportable draft. I think the authors > have more in their heads than they've put into the draft and I'd > like to see the rest of their thoughts. > > Thanks, > Phil > > _______________________________________________ > netmod mailing list > netmod@ietf.org > https://www.ietf.org/mailman/listinfo/netmod From nobody Fri Feb 9 08:25:34 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 689CA126579 for ; Fri, 9 Feb 2018 08:25:31 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.91 X-Spam-Level: X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4qVT6gXrrxXX for ; Fri, 9 Feb 2018 08:25:29 -0800 (PST) Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 110C31200FC for ; Fri, 9 Feb 2018 08:25:29 -0800 (PST) Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D92E79A; Fri, 9 Feb 2018 17:25:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 4vLy1Fh13hvI; Fri, 9 Feb 2018 17:25:26 +0100 (CET) Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 9 Feb 2018 17:25:27 +0100 (CET) Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id C0C8C2014E; Fri, 9 Feb 2018 17:25:27 +0100 (CET) X-Virus-Scanned: amavisd-new at jacobs-university.de Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id i0PX3E49RuUs; Fri, 9 Feb 2018 17:25:27 +0100 (CET) Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 055AE2014B; Fri, 9 Feb 2018 17:25:27 +0100 (CET) Received: by elstar.local (Postfix, from userid 501) id D279442404D3; Fri, 9 Feb 2018 17:25:26 +0100 (CET) Date: Fri, 9 Feb 2018 17:25:26 +0100 From: Juergen Schoenwaelder To: Balazs Lengyel Cc: "netmod@ietf.org" Message-ID: <20180209162526.5siyzlqgiru73nsb@elstar.local> Reply-To: Juergen Schoenwaelder Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com> <20180208092408.ir25jwkorxozq6gr@elstar.local> <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline X-Clacks-Overhead: GNU Terry Pratchett Content-Transfer-Encoding: 8bit In-Reply-To: <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> User-Agent: NeoMutt/20171215 Archived-At: Subject: Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 16:25:31 -0000 How do I know which datastore the data belongs to? Would it not make sense to carry that information inline? If we do not carry this information inline, how is that information supposed to be provided if for example this format is used to validate examples included in documentation? /js On Fri, Feb 09, 2018 at 04:07:11PM +0100, Balazs Lengyel wrote: > Hello Jurgen, > > I will gladly add NMDA to the draft. However could you please be more > specific. Which part of NMDA are you missing? > Is it the example of yanglib that you would like updated? > > As the instance-data can be used to document and/or load    both config=true > and false data it is IMHO relevant to the candidate/running/operational > datastores. However whether it should be used to just document data or also > to load data, and how exactly such a load should be implemented  is out of > scope. And yes using one SW kit config=false data can be loaded from file > too. > > regards Balazs > > > On 2/8/2018 10:24 AM, Juergen Schoenwaelder wrote: > > [Removing NETCONF since the I-D says -netmod-.] > > > > I flipped through the I-D yesterday and I think a common format for > > instance data trees should be NMDA aware these days. > > > > /js > > > > On Thu, Feb 08, 2018 at 10:17:25AM +0100, Balazs Lengyel wrote: > > > Hello, > > > > > > With Benoit I prepared a draft about how to document and use YANG defined > > > instance data. It could be useful for documenting server capabilities or > > > preloading data defined in implementation time and probably for other > > > purposes as well. > > > > > > regards Balazs > > > > > > -------- Forwarded Message -------- > > > > > > Subject: New Version Notification for > > > draft-lengyel-netmod-yang-instance-data-00.txt > > > Date: Wed, 7 Feb 2018 09:28:50 -0800 > > > From: [1]internet-drafts@ietf.org > > > To: Benoit Claise [2], Balazs Lengyel > > > [3] > > > > > > A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt > > > has been successfully submitted by Balazs Lengyel and posted to the > > > IETF repository. > > > > > > Name: draft-lengyel-netmod-yang-instance-data > > > Revision: 00 > > > Title: YANG Instance Data Files and their use for Documenting Server Capabilities > > > Document date: 2018-02-06 > > > Group: Individual Submission > > > Pages: 10 > > > URL: [4]https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt > > > Status: [5]https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ > > > Htmlized: [6]https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 > > > Htmlized: [7]https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 > > > > > > > > > Abstract: > > > This document specifies a standard file format for YANG instance > > > data, that is data that could be stored in a datastore and whose > > > syntax and semantics is defined by YANG models. Instance data files > > > can be used to provide information that is defined in design time. > > > There is a need to document Server capabilities (which are often > > > specified in design time), which should be done using instance data > > > files. > > > > > > > > > > > > > > > Please note that it may take a couple of minutes from the time of submission > > > until the htmlized version and diff are available at tools.ietf.org. > > > > > > The IETF Secretariat > > > > > > > > > -- > > > Balazs Lengyel Ericsson Hungary Ltd. > > > Senior Specialist > > > Mobile: +36-70-330-7909 email: [8]Balazs.Lengyel@ericsson.com > > > > > > References > > > > > > Visible links > > > 1. mailto:internet-drafts@ietf.org > > > 2. mailto:bclaise@cisco.com > > > 3. mailto:balazs.lengyel@ericsson.com > > > 4. https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt > > > 5. https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/ > > > 6. https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00 > > > 7. https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00 > > > 8. mailto:Balazs.Lengyel@ericsson.com > > > _______________________________________________ > > > 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 > > _______________________________________________ > 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 Fri Feb 9 13:24:09 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 984061270AE for ; Fri, 9 Feb 2018 13:24:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.701 X-Spam-Level: X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b_HClGD5_Gqc for ; Fri, 9 Feb 2018 13:23:59 -0800 (PST) Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 25F011242F7 for ; Fri, 9 Feb 2018 13:23:59 -0800 (PST) Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w19LNZa9006521; Fri, 9 Feb 2018 13:23:58 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=6ZDnvkjZ/gddLP3Gb1WEYGx3sWQCbIMh4c+cwXBLmbI=; b=VLlR2AXJHpcaMrGPXAKdwyYNIlyNGE+p8dAwvAS3FEuuKhtg4B+8UK0UCoBWslxNQZjT Is2GH1nOpmadn+Lg/XneRC4p7xj488GI9RRyP0TUBaNuWnsjdXSnQkfZGQaPnfdjAcqD EBHP8VidIi9BS6BeNM1oZBKhKfijtWrMYIOIcsdtAjhlOpnpL7O5L1Q/DT4PyKHRCz+Y cb8vvxlj4wwhKGPSFi09zSae+j9fkWxDrYTyoxNXU8KXejWfzsWy74PgIT1V4p2m1PHF tXhK/uogQSaudhIHm5h3tey6tuMD7USY3IdDWzSsmoiPVqqFz/5QvJYEpTThLrdWBflD 4A== Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0176.outbound.protection.outlook.com [216.32.180.176]) by mx0a-00273201.pphosted.com with ESMTP id 2g1jfkg3b5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2018 13:23:58 -0800 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3467.namprd05.prod.outlook.com (10.174.240.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Fri, 9 Feb 2018 21:23:56 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747%13]) with mapi id 15.20.0506.007; Fri, 9 Feb 2018 21:23:56 +0000 From: Kent Watsen To: Eliot Lear , Jan Lindblad CC: netmod WG Thread-Topic: [netmod] [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang Thread-Index: AQHToYdR/zDWYmmDG0yVdYnnwYn9hqObza2AgAB0BoA= Date: Fri, 9 Feb 2018 21:23:56 +0000 Message-ID: <8E0CD57D-9FFF-4363-B0CE-F4A42524367A@juniper.net> References: <1f32428b-6751-8303-9fc7-ac2c2a92990a@cisco.com> <6ecf354c-42f2-7dc2-f858-7e46f1721be1@cisco.com> In-Reply-To: <6ecf354c-42f2-7dc2-f858-7e46f1721be1@cisco.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3467; 7:M7IRxnxTYNliiXHP9EGf8AQke0l8/iAeEh1DQnpiuFWfehgSGBiiWpylaC6v0zBKwInQ7y6RxINdl9nCjoC4KUQgyyVfu6tlzYRpDgpkDCFRdHOht4fHBhruSbvD3yqHM4dVQkDju6AcB3nhgSvCpfn5CxDoa3rhMIE9FDAWw9mVyQ3jNSrwoOBSm/0BmcSYU47+wh0E8tIcceT7f2U0+DJrL0aAuFpK576o8lIUbEYwI6BpWY/8ZINbyA/Xvm0O x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: ee1423f7-c9a9-4e7c-5b8e-08d570036d37 x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3467; x-ms-traffictypediagnostic: DM5PR05MB3467: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(788757137089); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(8121501046)(5005006)(3002001)(3231101)(2400082)(944501161)(93006095)(93001095)(10201501046)(6055026)(6041288)(20161123564045)(20161123558120)(20161123562045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR05MB3467; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3467; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(396003)(39860400002)(39380400002)(366004)(199004)(189003)(5423002)(6436002)(6246003)(5660300001)(81156014)(58126008)(82746002)(110136005)(25786009)(345774005)(97736004)(8676002)(2900100001)(5250100002)(3660700001)(316002)(3846002)(478600001)(6486002)(99286004)(6512007)(83506002)(106356001)(83716003)(105586002)(26005)(86362001)(6506007)(36756003)(53546011)(59450400001)(66066001)(7736002)(6346003)(229853002)(6116002)(2906002)(76176011)(305945005)(102836004)(14454004)(2950100002)(3280700002)(33656002)(53936002)(93886005)(8936002)(4326008)(68736007)(81166006)(186003)(221513004)(222073002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3467; H:DM5PR05MB3484.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) x-microsoft-antispam-message-info: RAo2aAvtVvaQtKOlKCb236e/YsLg1o4EUeLlbBRN9zJLxxXc5Iv1PRumgfjkeCA6I1py63NHm5w5EK7wIBBt6w== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1EEDDAFC62D4734B8A5C1516438A9E49@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: ee1423f7-c9a9-4e7c-5b8e-08d570036d37 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 21:23:56.1725 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3467 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090270 Archived-At: Subject: Re: [netmod] [OPSAWG] Minor change in ietf-access-control-list@2018-02-02.yang X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 21:24:03 -0000 WWVzLCBpdCBtYXkgYmUgYSBidWcgaW4gT0RMLCBidXQgSSBhbHNvIHRoaW5rIHRoYXQgdGhlcmUg aXMgc29tZXRoaW5nIHdyb25nIHRvIHVzZSBzdWNoIGEgbG9uZyByZWxhdGl2ZSBwYXRoLiAgSW4g dGhhdCBjYXNlLCB0aGUgcmVsYXRpdmUgcGF0aCBpcyBhY3R1YWxseSBsb25nZXIgdGhhbiB0aGUg YWJzb2x1dGUgcGF0aCEgIFRoYXQgc2FpZCwgdGhlcmUgaXMgbm8gZ3VpZGFuY2UgaW4gcmZjNjA4 N2JpcyBjdXJyZW50bHksIHNvIHdlIG1heSBuZWVkIHRvIGxldCBpdCBnbyB0aGlzIHRpbWUuDQoN CksuIC8vIHNoZXBoZXJkDQoNCj09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT0NCg0KVGhpcyBt YXkgYmUuIGJ1ZyBpbiBPcGVuRGF5bGlnaHQgdGhhdCBpcyBiZWluZyB0aWNrbGVkLiAgUmFuZ2Eg aXMNCmNoYXNpbmcgaXQgYSBiaXQuDQoNCg0KT24gMDkuMDIuMTggMTA6MjAsIEphbiBMaW5kYmxh ZCB3cm90ZToNCj4gRWxpb3QsDQo+DQo+PiBJbiBvcmRlciB0byBjb21waWxlIHRoZSBwdWJsaXNo ZWQgWUFORyBtb2RlbCB3aXRoIE9wZW5EYXlsaWdodCBZYW5ndG9vbHMgSSBoYWQgdG8gbWFrZSB0 aGUgZm9sbG93aW5nIGNoYW5nZSAoIGRpZmYgcHVibGlzaGVkIGZpbGUgdnMuIGNoYW5nZWQgZmls ZSBpcyBiZWxvdyApOg0KPj4NCj4+IDU4M2M1ODMNCj4+IDwgICAgICAgICAgICAgICAgIHBhdGgg Ii4uLy4uLy4uLy4uLy4uLy4uL2FjbC9uYW1lIjsNCj4+IC0tLQ0KPj4+ICAgICAgICAgICAgICAg ICBwYXRoICIvYWNjZXNzLWxpc3RzL2FjbC9uYW1lIjsNCj4+IDU5N2M1OTcNCj4+IDwgICAgICAg ICAgICAgICAgICAgcGF0aCAiLi4vLi4vLi4vLi4vLi4vLi4vLi4vYWNsL2FjZXMvYWNlL25hbWUi Ow0KPj4gLS0tDQo+Pj4gICAgICAgICAgICAgICAgICAgcGF0aCAiL2FjY2Vzcy1saXN0cy9hY2wv YWNlcy9hY2UvbmFtZSI7DQo+Pg0KPj4gSSBhbSBub3Qgc3VyZSAoZG9uJ3QgaGF2ZSBlbm91Z2gg WUFORyBleHBlcmllbmNlKSB0byBrbm93IGlmIHRoZSBlcnJvciBpcyB3aXRoIFlhbmd0b29scyBv ciB3aXRoIHRoZSBwdWJsaXNoZWQgWUFORyBtb2RlbCBidXQgSSB0aG91Z2h0IEknZCBzZW5kIHRo aXMgaW5mb3JtYXRpb24gdG8gdGhlIGxpc3QganVzdCBpbiBjYXNlLg0KPj4NCj4+IFRoYW5rIHlv dSBmb3IgeW91ciBhdHRlbnRpb24uDQo+IEJvdGggdGhlIG9sZCBhbmQgdGhlIG5ldyBwYXRoIGxv b2sgdmFsaWQgdG8gbWUuIEV2ZW4gaWYgeW91IGNhbiBhbHdheXMgcmVwbGFjZSBhIHJlbGF0aXZl IHBhdGggd2l0aCBhbiBhYnNvbHV0ZSBmcm9tIGEgWUFORyB2YWxpZGl0eSBwZXJzcGVjdGl2ZSwg Y2hhbmdpbmcgZnJvbSByZWxhdGl2ZSB0byBhYnNvbHV0ZSBwYXRocyBvZnRlbiAqY2hhbmdlcyB0 aGUgc2VtYW50aWNzKiwgc28gdGhhdCBpcyBub3QgZ2VuZXJhbGx5IHNhZmUuIEluIHRoaXMgY2Fz ZSwgaG93ZXZlciwgdGhleSBkbyBhbW91bnQgdG8gdGhlIHNhbWUgdGhpbmcgKHNpbmNlIHRoZXkg Ym90aCBlbmQgdXAgZ29pbmcgYWxsIHRoZSB3YXkgdXAgdG8gdGhlIHRvcCBsZXZlbCBjb250YWlu ZXIpLg0KPg0KPiAvamFuDQo+DQo+DQoNCg0KDQoNCg== From nobody Fri Feb 9 13:27:30 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6666126D05 for ; Fri, 9 Feb 2018 13:27:29 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.491 X-Spam-Level: X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=juniper.net Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GMYT_lR7fhDQ for ; Fri, 9 Feb 2018 13:27:27 -0800 (PST) Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 3FFC91242F7 for ; Fri, 9 Feb 2018 13:27:27 -0800 (PST) Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w19LNawE031095; Fri, 9 Feb 2018 13:27:23 -0800 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=EPOJUG6YHp0kBV67+ubWBMk5MDXPFERWjOQqN8PE5bQ=; b=DKeWaE8ioQ8ZfyO1BgpeQ3VLfcClFfzVMemmO9zbTynci3b/uy9rLoB+74Ouo6ZDWmdW J0UyqV9xZOynaJIyn52fwSnUo1QnGVmegtULA0VQ05V9MFiF2JqWrh87KMsJE4RItHXR NjZB+ve0QGSPBBOrmz46moCNlcuSKIY748MKmKa9SCV0qHEon+/OIUkDN3X0qrVwV73T nMYeVQmSm9noPjJEkQEZkbJYPAvxmKaXpJOGgCWwC+1qGGSnhpOuPjvcqzXXpTEIzwpE I049pSVkUQMYFBkxNxOfLnQJbTVwDVXHJYyCr8+vuX5snYyHGdONEe4roc+GUjOIns2v dg== Received: from nam02-sn1-obe.outbound.protection.outlook.com (mail-sn1nam02lp0023.outbound.protection.outlook.com [216.32.180.23]) by mx0a-00273201.pphosted.com with ESMTP id 2g1kdnr0ja-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 09 Feb 2018 13:27:23 -0800 Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3579.namprd05.prod.outlook.com (10.174.242.160) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Fri, 9 Feb 2018 21:27:22 +0000 Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747%13]) with mapi id 15.20.0506.007; Fri, 9 Feb 2018 21:27:22 +0000 From: Kent Watsen To: "t.petch" , Andy Bierman CC: NETMOD Working Group Thread-Topic: [netmod] draft-ietf-netmod-rfc6087bis-16 Thread-Index: AQHToBO3CuCKGPD7x0Ol5E7YFjuR5KOZN7QAgAL77KeAABHwgA== Date: Fri, 9 Feb 2018 21:27:22 +0000 Message-ID: <296DAB6D-9A99-4FD2-A8F9-65A4D2206407@juniper.net> References: <6f96ec70-1532-5d99-97d1-5d5531e7865e@cisco.com> <6BAC6B11-90A9-4CA1-AE53-FFAC084FB76E@juniper.net> <5c2ae0a9-b4b9-3d13-395e-1c779f99f941@cisco.com> <01f501d3a013$72e66180$4001a8c0@gateway.2wire.net> <026001d3a1b9$9d382340$4001a8c0@gateway.2wire.net> In-Reply-To: <026001d3a1b9$9d382340$4001a8c0@gateway.2wire.net> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/f.20.0.170309 x-originating-ip: [66.129.241.14] x-ms-publictraffictype: Email x-microsoft-exchange-diagnostics: 1; DM5PR05MB3579; 6:TDTqi6krT5Qo8Ep8xHppq8ljPRpSFK7o9kdBcOmed5tpmGDkKD+JVM7S/csyfozJ4MjSUt26tXCK8jDuOhVz17JO0eKlUJTy6afSaZ9Q04nYfNgpm+S4rtq/EdnjgD9zDgfBJUFBvN1fTloZQQpcYUfXz1T8DxUoc84U/nq4lVfySqLMtRD+x77cIRxBfeWf5x688ddUL77TZRCkvwRuVx1ThYlq2GMpqNtJ2cPhH4NmG61vYf508Q0nRAxUgC9owOEkXdcatM14bYgRJvaBMEC8AZGIzfcta3zPrvSBFOPhIy90JudXahNr9Ji73S/hcOi7uz/ENCw76N2odNTW4Y5N7x/TOMTnR36XGtlmk7AHSeGiTN1KTtzPAaF6GJjP; 5:qdwFY5uY1yVZji9RYZPzmkmL6VQQbxk3WtMo3ncpp3EJUpqs8Xp0qcJWUHi68HroYmuVkhFt5GczyTSiV8EESQiXdNZHPW6OOpzS1Hu5J8PsVNHTnR0bZWnCQHPNjM23YYT6s/GHvKSp07KWFWnbD8ORjw4M3NYRqel6TRMdlgY=; 24:YHQ3350QvNH1f+vM+fZwsIpD7DgC5m/Sa61gdX3hO1HvM1J2IB5Ti6HvyHuBxGmeoKAQvoO11dImyS3gAgwsATu9bK2ck0Oie6f60rInKM4=; 7:NmTk1tclvfwISplVzRU9u824eTH5ZES9g6MVFOoa6jL3PyQEoLGk/ieAzeklA6+IFxVQ8qV7U/of6EXsz2M8fCUqnZvj3LQq+Dwzaqc3GNpm1kIpK8g5Bq5da6Hs0dEjDT7I4CYvB3C4UyMgVXxYwm5L/yFKR4A7c9xCPSEaFOKE8f6Ey+8DN2LqpfEtg+q65d1AbA4r6jL76fgGu2cRsxBKO5hqURfM4IZg44IjaYn9qfH0SHecsPfLeuHieNCW x-ms-exchange-antispam-srfa-diagnostics: SSOS; x-ms-office365-filtering-ht: Tenant x-ms-office365-filtering-correlation-id: fcc7b90b-89c1-4942-ddaa-08d57003e7f2 x-microsoft-antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3579; x-ms-traffictypediagnostic: DM5PR05MB3579: x-microsoft-antispam-prvs: x-exchange-antispam-report-test: UriScan:(178726229863574)(10436049006162)(166708455590820); x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231101)(2400082)(944501161)(10201501046)(6055026)(6041288)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123564045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:DM5PR05MB3579; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3579; x-forefront-prvs: 057859F9C5 x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(366004)(346002)(376002)(199004)(13464003)(189003)(8676002)(83716003)(106356001)(6506007)(8936002)(86362001)(575784001)(81156014)(8666007)(59450400001)(97736004)(81166006)(33656002)(186003)(76176011)(102836004)(478600001)(82746002)(966005)(3280700002)(26005)(6306002)(66066001)(5660300001)(7736002)(6116002)(2906002)(14454004)(296002)(4326008)(25786009)(93886005)(6486002)(6436002)(3846002)(68736007)(6246003)(105586002)(3660700001)(2900100001)(305945005)(99286004)(110136005)(6512007)(36756003)(53936002)(53546011)(5250100002)(229853002)(83506002)(2950100002)(58126008)(316002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3579; H:DM5PR05MB3484.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) x-microsoft-antispam-message-info: 6xPQoO6S8kef8TCPLQs6YvyseoNykA8wmwYNelEtkCqMaws7PWqt2ifbX8bse/atITEoos8li8capu2edLpRHg== spamdiagnosticoutput: 1:99 spamdiagnosticmetadata: NSPM Content-Type: text/plain; charset="utf-8" Content-ID: <1556E40242CA064E904B19C5229CABBA@namprd05.prod.outlook.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-OriginatorOrg: juniper.net X-MS-Exchange-CrossTenant-Network-Message-Id: fcc7b90b-89c1-4942-ddaa-08d57003e7f2 X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Feb 2018 21:27:22.0678 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4 X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3579 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-09_11:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802090270 Archived-At: Subject: Re: [netmod] draft-ietf-netmod-rfc6087bis-16 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 21:27:30 -0000 SGkgVG9tLA0KDQpJIGtub3cgd2hlcmUgeW91J3JlIGdvaW5nIHdpdGggdGhpcywgYW5kIEkgYWdy ZWUsIGJ1dCBhcyB3ZSdyZSBwYXN0IEFELXJldmlldywgbWF5YmUgdGhpcyBpcyBhIGdvb2QgY2Fu ZGlkYXRlIGZvciBndWlkZWxpbmVzLW5leHQ/DQoNCiAgaHR0cHM6Ly9naXRodWIuY29tL25ldG1v ZC13Zy9ndWlkZWxpbmVzLW5leHQvaXNzdWVzDQoNCktlbnQgLy8gc2hlcGhlcmQNCg0KDQotLS0t LSBPcmlnaW5hbCBNZXNzYWdlIC0tLS0tDQpGcm9tOiAiQW5keSBCaWVybWFuIiA8YW5keUB5dW1h d29ya3MuY29tPg0KU2VudDogV2VkbmVzZGF5LCBGZWJydWFyeSAwNywgMjAxOCA1OjQ4IFBNDQoN Cj4gT24gV2VkLCBGZWIgNywgMjAxOCBhdCA0OjU4IEFNLCB0LnBldGNoIDxpZXRmY0BidGNvbm5l Y3QuY29tPiB3cm90ZToNCj4NCj4gPiBBbmR5DQo+ID4NCj4gPiBJZiBhbiBSRkMgaXMgbWVudGlv bmVkIGluIGEgRGVzY3JpcHRpb24gY2xhdXNlLCBzaG91bGQgaXQgYWxzbw0KYXBwZWFyIGluDQo+ ID4gdGhlIHJlbGF0ZWQgUmVmZXJlbmNlIGNsYXVzZT8NCj4NCj4geWVzIC0tIHRoZXJlIGFyZSBt YW55IHBsYWNlcyBpbiA2MDg3YmlzIHRoYXQgbWVudGlvbiB0aGUNCnJlZmVyZW5jZS1zdG10DQo+ DQo+IGUuZy46DQo+DQo+ICAgIElmIHRoZSBub3RpZmljYXRpb24gc2VtYW50aWNzIGFyZSBkZWZp bmVkIGluIGFuIGV4dGVybmFsIGRvY3VtZW50DQo+ICAgIChvdGhlciB0aGFuIGFub3RoZXIgWUFO RyBtb2R1bGUgaW5kaWNhdGVkIGJ5IGFuIGltcG9ydCBzdGF0ZW1lbnQpLA0KPiAgICB0aGVuIGEg cmVmZXJlbmNlIHN0YXRlbWVudCBNVVNUIGJlIHByZXNlbnQuDQo+DQo+IEkgY2Fubm90IGZpbmQg YW55IHRleHQgdGhhdCBzYXlzIGl0IGlzIE9LIG9yIG5vdCBPSyB0byBhbHNvIHB1dA0KPiB0aGUg cmVmZXJlbmNlIGluIHRoZSBkZXNjcmlwdGlvbi1zdG10Lg0KDQpBbmR5DQoNCkp1c3QgdG8gYmUg Y2xlYXIsIHdoYXQgSSBhbSBzZWVpbmcgaXMgUkZDeHh4eCBpbiBhIERlc2NyaXB0aW9uIGNsYXVz ZSBpbg0KYSBZQU5HIG1vZHVsZSBidXQgbm90IGFwcGVhcmluZyBhbnl3aGVyZSBlbHNlIGluIHRo ZSBJLUQsIG5vdCBpbiBhDQpSZWZlcmVuY2UgY2xhdXNlIG9yIGluIHRoZSBJLUQgUmVmZXJlbmNl IHNlY3Rpb25zIG9yIGFueXdoZXJlLg0KDQplLmcuIGluIGRyYWZ0LWlldGYtZGhjLWRoY3B2Ni15 YW5nDQogbGVhZiB1dWlkIHsNCiAgICAgICAgICAgIHR5cGUgeWFuZzp1dWlkOw0KICAgICAgICAg ICAgZGVzY3JpcHRpb24gIkEgVW5pdmVyc2FsbHkgVW5pcXVlIElEZW50aWZpZXIgaW4gdGhlIHN0 cmluZw0KcmVwcmVzZW50YXRpb24NCiAgICAgICAgICAgICAgICBkZWZpbmVkIGluIFJGQyA0MTIy Lg0KDQo0MTIyIGFwcGVhcnMgaW4gdGhyZWUgc3VjaCBEZXNjcmlwdGlvbiBjbGF1c2VzIGJ1dCBu b3doZXJlIGVsc2U7IEkgYW0NCnRoaW5raW5nIHRoYXQgaXQgc2hvdWxkIGFsc28gYmUgaW4gYSBS ZWZlcmVuY2UgY2xhdXNlIGFzIHdlbGwNCg0KVG9tIFBldGNoDQoNCj4gPiBkcmFmdC1pZXRmLWRo Yy1kaGNwdjYteWFuZy0wNSBoYXMgZXhhbXBsZXMgb2YgdGhpcyBub3QgYmVpbmcgdGhlDQpjYXNl LA0KPiA+IGFzIEkgbWVudGlvbiBpbiBhIHJlY2VudCBwb3N0LiAgSSBhc3N1bWVkIHRoYXQgdGhl eSBzaG91bGQgYmUgYnV0DQpjYW5ub3QNCj4gPiBzZWUgYW55IGRpc2N1c3Npb24gb2YgdGhpcyBp biBSRkM2MDg3YmlzDQo+ID4NCj4gPiBUb20gUGV0Y2gNCj4gPg0KPiA+DQo+IEFuZHkNCj4NCg0K X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCm5ldG1vZCBt YWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZw0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19u ZXRtb2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6 b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPUNUOUhm NEY0SDJwcm5PZzBzTHA5V3ZQRTUxcTB6U3d4QXVmbkZHRUZJMzgmcz1yS0x5WkZnSEs4ODRXdncy WGoyZ3UyX3h1NlBSSkRaZWtoM0ZnemhUekkwJmU9DQoNCg0K From nobody Fri Feb 9 13:57:55 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C2321270A3 for ; Fri, 9 Feb 2018 13:57:53 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 wClwwhngcgUo for ; Fri, 9 Feb 2018 13:57:50 -0800 (PST) Received: from mail-lf0-x231.google.com (mail-lf0-x231.google.com [IPv6:2a00:1450:4010:c07::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 528911242F7 for ; Fri, 9 Feb 2018 13:57:50 -0800 (PST) Received: by mail-lf0-x231.google.com with SMTP id r143so844034lfr.11 for ; Fri, 09 Feb 2018 13:57:50 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=OyfmAUcSYr7kt9l59ThnBL81Ky4ITXh6cOXpgZGCpzo=; b=lUaI2n6r4+ylcT5XC0C7IRd3awxnZb9JZMmETrwJXVj2+vKUxDTfeC1THay/e1Yn6J t5PpktksDrRCSCwLsrn5PXor4Y7DSrt58IdwMxhxaMyM1bkTyq+QKQdjF4z/+5N2rm9a kPjZYe+BJVSVhSnGrm2fEnfJxRueSTVdupzD+vRKb9WwAIXhOUcceZS8wruA6jCITcIT pcsThk9nmCAivy4QPAFwRC0NH0JFxeNd0Fg5H6ziglugykwQdpdzxbK4wcKj9erqQEBG pJH9kOAmOOHPcx7pGDyJcY2BOXgSiOQAubsWCa0RfFpW2ctzEBrUZJ+nFi0dV+GKGo3e bh8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=OyfmAUcSYr7kt9l59ThnBL81Ky4ITXh6cOXpgZGCpzo=; b=bZPVAEdm3g5TF0qz11TNwGdYnAHoRRocrV59QBhIN2Danzgx3UsG2eIpPOLxesbfCL Max8TjDMIlzZFpUlYY6hU+fXYNbrdfoORDsC/fOfWCo3ot8eUrwmkB8cowoEEWbewcvL XNOHjQZuA79LbUQcSDh+O13siIITxtATNsW0sTZxDqsxess7cpLIs/zAbZ8t5vzkw0Gd 3Z/s7hJp9cCl9NN4ru7ThEJSRqWRV8zIPwa6Umeu4Pc1QcpHT/apM1NxGCxTgHUt8zrP H9ZgZW0g6yJKIa8KtA2BiN2O9OxsKzHN55Nc93XYW9Bq/Uv2FfpMQpfBLFeJgE3Vh1d2 WKwA== X-Gm-Message-State: APf1xPBdCnD3/qsltj1kaqkYDu901kgR5/mtK+e93eO0IlLhIqS961kz GUvuGkvzHyR1o2KSDz6vhcPE+kGu0NqV5UhLDrY+pC9j X-Google-Smtp-Source: AH8x227INa+f9WxQZsZyNTv3w/mSC++JMifRs4E3E81pgklJB9Yg/lCwfWcKaLzB/jLEC5b79eaZ8/AiJYjhcQYd6CI= X-Received: by 10.25.20.168 with SMTP id 40mr2948936lfu.23.1518213468487; Fri, 09 Feb 2018 13:57:48 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.225.18 with HTTP; Fri, 9 Feb 2018 13:57:47 -0800 (PST) In-Reply-To: <026201d3a1b9$9e7ead00$4001a8c0@gateway.2wire.net> References: <201802071859.w17IxjwU073675@idle.juniper.net> <026201d3a1b9$9e7ead00$4001a8c0@gateway.2wire.net> From: Andy Bierman Date: Fri, 9 Feb 2018 13:57:47 -0800 Message-ID: To: "t.petch" Cc: NETMOD Working Group Content-Type: multipart/alternative; boundary="001a113fb1187b99d60564ce9eca" Archived-At: Subject: Re: [netmod] Adoption Poll: draft-rtgyangdt-netmod-module-tags-02 X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 21:57:54 -0000 --001a113fb1187b99d60564ce9eca Content-Type: text/plain; charset="UTF-8" On Fri, Feb 9, 2018 at 7:19 AM, t.petch wrote: > Oppose adoption > > As others have said, there is a lack of a problem to solve. > > Actually, I see eventual value in the tags themselves if: - each tag is defined with a YANG identity - there is standard filtering based on derived-from-or-self - the standard tags are maintained in an IANA module (iana-yang-tags) - there is a standard YANG extension yt:module-tag that can be used to assign tags to an entire module - there is a standard YANG extension yt:data-tag that can be used to assign tags to a YANG data subtree - standard YANG modules include appropriate tagging IMO it is similar to iana-if-types, which is much better than each vendor or each operator assigning all the code-points. It would be a lot of work to come up with a good set of standard tags but it seems there are people willing to work on that. Andy When I ask users of a technology that uses #hashtags where they come > from, how they come into being and similar elements of procedure, I > never get an answer. #hashtags seem to be provided to allow a storm to > gather on social media, around some vague idea, in order to put pressure > on someone or something that would otherwise be unjustified:-) > > The tags listed in Section 10.2 seem just as vague and I do not see a > role for something somewhat ill-defined in YANG. > > Tom Petch > > ----- Original Message ----- > From: "Phil Shafer" > To: "Andy Bierman" > Cc: "NETMOD Working Group" > Sent: Wednesday, February 07, 2018 6:59 PM > Subject: Re: [netmod] Adoption Poll: > draft-rtgyangdt-netmod-module-tags-02 > > > > Andy Bierman writes: > > >The draft avoids discussion of any useful operations based on tags. > > > > Nor does it really clearly say "what" is being tagged. The absract > > talks about "used to help classify and organize modules", but the > > Introduction lacks any expansion on this. There's really no clear > > problem statement or a clear definition of why we need tags or what > > one would use them for. > > > > It would also be helpful to understand why "#hashtag" and the string > > format ("ietf:routing", "vendor:super-duper:...") are chosen over > > YANG identities. It seems like identity naming standards and > inheritance > > would be good features. > > > > Also it's not clear why these would be configurable rather that > > controlled by the module author. I'd rather have the OAM standard > > YANG module say something like: > > > > module ietf-oam { > > import "ietf-category" { prefix ietf-category; } > > > > identify ietf-oam { > > base ietf-category:ietf-standard; > > description "This module category represents something > > OAM related."; > > } > > > > ietf-category:module-category ietf-oam; > > ... > > } > > > > The draft says: > > > > Implementations that do not support the reset rpc statement > (whether > > at all, or just for a particular rpc or module) MUST respond with > an > > YANG transport protocol-appropriate rpc layer error when such a > > statement is received. > > > > The entire idea of NETCONF/YANG is that the client _knows_ what it > > can safely send instead of tossing spaghetti at the wall until > > something sticks. Avoid programming-by-error-detection, which > > creates fragile infrastructure. > > > > Use "feature" to control optional portions of a YANG module. I'd > > suggest one feature for "reset" support and another for "read-only", > > since IMHO the idea of someone munging the categories of standard > > modules is, well, disconcerting. > > > > "Local" tags are not well explained. The idea of a user/admin > > tagging modules means that something is broken. Users shouldn't > > understand YANG modules. Users use applications, some of which are > > home-grown. Is "local" appropriate for my "audit interfaces" script? > > > > 6.1 is missing the list "module-tags". > > > > 9.1 advocates putting vital information in the description string, > > which is IMHO not a good idea. We want to put as much information > > in machine-readable format as possible, so I can ask ietf.org > > questions like "give me a list of ietf-oam-related yang modules" > > and get a nice list. > > > > It also talks about "SHOULD" and "MAY" tags without giving any > > clue as to why or when this would be appropriate or useful. > > > > So my vote would be that this document needs some significant work > > and expansion before it's a supportable draft. I think the authors > > have more in their heads than they've put into the draft and I'd > > like to see the rest of their thoughts. > > > > Thanks, > > Phil > > > > _______________________________________________ > > 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 > --001a113fb1187b99d60564ce9eca Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


On Fri, Feb 9, 2018 at 7:19 AM, t.petch <ietfc@btconnect.com&g= t; wrote:
Oppos= e adoption

As others have said, there is a lack of a problem to solve.



Actually, I see eventua= l value in the tags themselves if:

=C2=A0 =C2=A0- = each tag is defined with a YANG identity
=C2=A0 =C2=A0- there is = standard filtering based on derived-from-or-self
=C2=A0 =C2=A0- t= he standard tags are maintained in an IANA module (iana-yang-tags)
=C2=A0 =C2=A0- there is a standard YANG extension yt:module-tag that can = be used to assign
=C2=A0 =C2=A0 =C2=A0tags to an entire module
=C2=A0 =C2=A0- there is a standard YANG extension yt:data-tag = that can be used to assign
=C2=A0 =C2=A0 =C2=A0tags to a YANG dat= a subtree
=C2=A0 =C2=A0- standard YANG modules include appr= opriate tagging

IMO it is similar to iana-if-types= , which is much better than each vendor or
each operator assignin= g all the code-points.

It would be a lot of work t= o come up with a good set of standard tags
but it seems there are= people willing to work on that.


An= dy



When I ask users of a technology that uses #hashtags where they come
from, how they come into being and similar elements of procedure, I
never get an answer.=C2=A0 #hashtags seem to be provided to allow a storm t= o
gather on social media, around some vague idea, in order to put pressure on someone or something that would otherwise be unjustified:-)

The tags listed in Section 10.2 seem just as vague and I do not see a
role for something somewhat ill-defined in YANG.

Tom Petch

----- Original Message -----
From: "Phil Shafer" <phil@= juniper.net>
To: "Andy Bierman" <andy= @yumaworks.com>
Cc: "NETMOD Working Group" <netmod@ietf.org>
Sent: Wednesday, February 07, 2018 6:59 PM
Subject: Re: [netmod] Adoption Poll:
draft-rtgyangdt-netmod-module-tags-02


> Andy Bierman writes:
> >The draft avoids discussion of any useful operations based on tags= .
>
> Nor does it really clearly say "what" is being tagged.=C2=A0= The absract
> talks about "used to help classify and organize modules", bu= t the
> Introduction lacks any expansion on this.=C2=A0 There's really no = clear
> problem statement or a clear definition of why we need tags or what > one would use them for.
>
> It would also be helpful to understand why "#hashtag" and th= e string
> format ("ietf:routing", "vendor:super-duper:...") = are chosen over
> YANG identities.=C2=A0 It seems like identity naming standards and
inheritance
> would be good features.
>
> Also it's not clear why these would be configurable rather that > controlled by the module author.=C2=A0 I'd rather have the OAM sta= ndard
> YANG module say something like:
>
>=C2=A0 =C2=A0 =C2=A0module ietf-oam {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0import "ietf-category" { pr= efix ietf-category; }
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0identify ietf-oam {
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0base ietf-category:ietf= -standard;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0description "This = module category represents something
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 OAM related.";
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0}
>
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0ietf-category:module-category ietf-oa= m;
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0...
>=C2=A0 =C2=A0 =C2=A0}
>
> The draft says:
>
>=C2=A0 =C2=A0 Implementations that do not support the reset rpc stateme= nt
(whether
>=C2=A0 =C2=A0 at all, or just for a particular rpc or module) MUST resp= ond with
an
>=C2=A0 =C2=A0 YANG transport protocol-appropriate rpc layer error when = such a
>=C2=A0 =C2=A0 statement is received.
>
> The entire idea of NETCONF/YANG is that the client _knows_ what it
> can safely send instead of tossing spaghetti at the wall until
> something sticks.=C2=A0 Avoid programming-by-error-detection, whi= ch
> creates fragile infrastructure.
>
> Use "feature" to control optional portions of a YANG module.= =C2=A0 I'd
> suggest one feature for "reset" support and another for &quo= t;read-only",
> since IMHO the idea of someone munging the categories of standard
> modules is, well, disconcerting.
>
> "Local" tags are not well explained.=C2=A0 The idea of a use= r/admin
> tagging modules means that something is broken.=C2=A0 Users shouldn= 9;t
> understand YANG modules.=C2=A0 Users use applications, some of which a= re
> home-grown.=C2=A0 Is "local" appropriate for my "audit = interfaces" script?
>
> 6.1 is missing the list "module-tags".
>
> 9.1 advocates putting vital information in the description string,
> which is IMHO not a good idea.=C2=A0 We want to put as much informatio= n
> in machine-readable format as possible, so I can ask ietf.org
> questions like "give me a list of ietf-oam-related yang modules&q= uot;
> and get a nice list.
>
> It also talks about "SHOULD" and "MAY" tags withou= t giving any
> clue as to why or when this would be appropriate or useful.
>
> So my vote would be that this document needs some significant work
> and expansion before it's a supportable draft.=C2=A0 I think the a= uthors
> have more in their heads than they've put into the draft and I'= ;d
> like to see the rest of their thoughts.
>
> Thanks,
>=C2=A0 Phil
>
> _______________________________________________
> 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

--001a113fb1187b99d60564ce9eca-- From nobody Fri Feb 9 14:09:08 2018 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 C3240127286; Fri, 9 Feb 2018 14:09:02 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: netmod@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.72.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <151821414276.22978.3548815622838472384@ietfa.amsl.com> Date: Fri, 09 Feb 2018 14:09:02 -0800 Archived-At: Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-20.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 09 Feb 2018 22:09:02 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Network Modeling WG of the IETF. Title : A YANG Data Model for Syslog Configuration Authors : Clyde Wildes Kiran Koushik Filename : draft-ietf-netmod-syslog-model-20.txt Pages : 34 Date : 2018-02-09 Abstract: This document defines a YANG data model for the configuration of a syslog process. It is intended this model be used by vendors who implement syslog in their systems. Editorial Note (To be removed by RFC Editor) This draft contains many placeholder values that need to be replaced with finalized values at the time of publication. This note summarizes all of the substitutions that are needed. No other RFC Editor instructions are specified elsewhere in this document. Artwork in this document contains shorthand references to drafts in progress. Please apply the following replacements: o "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft- ietf-netconf-keystore o "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value for draft-ietf-netconf-tls-client-server o "zzzz" --> the assigned RFC value for this draft The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-20 https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-20 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Feb 9 18:57:02 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81AE2126CC4 for ; Fri, 9 Feb 2018 18:57:00 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.92 X-Spam-Level: X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gFyG_U_PbwEh for ; Fri, 9 Feb 2018 18:56:58 -0800 (PST) Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0100.outbound.protection.outlook.com [104.47.1.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E43B124BAC for ; Fri, 9 Feb 2018 18:56:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=s8lxfXe+xppJ3bc57C+1S3kI0ZpRQicpykZ+nStdk+M=; b=CRXrBUcDw0AW1AVw4Q2hxzsOo+gq4f3Kf9DaWP9p/brgS4UWBrlDqw/lqxkxfUZHz25+Ka1sXKwxFB6M03lULQkwTVgjUUpxcDkFhvthBCWiKJ9R5I6owhVOHtJTJAOk4nfzU/2MDtbqMKNDCx33/mR05xoNwtQQdXy0IQ1aM20= Received: from VI1PR0701MB3008.eurprd07.prod.outlook.com (2603:10a6:800:87::22) by VI1PR0701MB3008.eurprd07.prod.outlook.com (2603:10a6:800:87::22) with TransportReplication id Version 15.20 (Build 506.7); Sat, 10 Feb 2018 02:56:56 +0000 Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; Received: from pc6 (86.176.21.219) by DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.485.3; Fri, 9 Feb 2018 12:10:22 +0000 Message-ID: <02d601d3a19e$b73cdbc0$4001a8c0@gateway.2wire.net> From: "t.petch" To: "Henrik Levkowetz" , "NETMOD Working Group" , "Benoit Claise" References: <26131545-049c-9a1a-eb2b-cdad6fce3190@cisco.com> <036201d39c25$7bb5a060$4001a8c0@gateway.2wire.net> Date: Fri, 9 Feb 2018 11:33:12 -0000 MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2800.1106 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106 X-Originating-IP: [86.176.21.219] X-ClientProxiedBy: CWLP265CA0064.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:12::28) To DB6PR0701MB2997.eurprd07.prod.outlook.com (2603:10a6:4:73::7) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: f3facf7e-8825-458e-1473-08d56fb61880 X-Microsoft-Antispam: UriScan:(178726229863574); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:DB6PR0701MB2997; X-Microsoft-Exchange-Diagnostics: 1; DB6PR0701MB2997; 3:MSFpJYwR6PrbioCv9B9faiJlZ4sDoGCPU2ByMgAVs1rDVN31v4FptSHzsohg8sCPnqNwsLPYT4+Q6OdB0OIYScINaxlkCkhLaWzS9zW04LxiqNPqeeIEYYkPRC27bdgaIfyMSFZA49be7YH4jJ8bKMfWEeXScUs89TgQixMghOsPPi8Vhyb6V66OskUPrROSLD+6Xu3lPWOv49f9xXhgn3SuaNH0O5TZHGQ/bnWdjXDvnU35oEJ/PDRynln+3gs+MJ8L95rFEKX4raFU/CxNBqOi17Ip4yn9QltWYs3ZXS0= X-MS-TrafficTypeDiagnostic: VI1PR0701MB3008: X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 25:ThEC1paTvADOzX/MhM1jUoqodygAIIRi8VwAN4wD+1G5kJPUeUB2jD7HikrHuzeBIpHgkZ9BHqd3Ur4wVDqNEP4ZYpYQgkoOXhkOWd48R4lkpwAZpsXVtnX+wXv3CUy960KyM/cAQ043vFFT2WbIFe8vBmn+KpZ25ZrFHVimy/MZQ+LnVVFeFBeK2ze+0F6alzcty/5xgHwxqiiJyQrduH5F6XJseePcNU3h7/FKVhsNdaeMvig+lS/KiTW70qyV7gvSFobdBgSBcbccqy5LFD3wGYhCwiL64rkkntvjzUApUQAAZFnKLzvP3sEquxV87CC5Alb+K72+5sir0/es8w==; 31:MofmlSPtFmZziIjIM4FEowUj6uZV3ftfXVpruVqS+PpqpVVnhzn+THKYwzLz/+EGxQlEBCl39N4UhjE5li5uHkWJnmnrz6P3MMb3k1NvkMvRszKtlXQX5rzhVHxohdPB32ObyahWhwpltn2ApgEUWQlcEDWtXjvLmtaDkHb5MCBf7zbTH9j1oPFx4VXrvsXopasglF9vmEzBkwE9Ec06Gxz+6m9o66+kEymcAC/p184= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3231101)(2400082)(944501161)(3002001)(10201501046)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0701MB3008; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3008; X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 4:053IOqvXWV4/Z4IBTsFy0iU0gypYcRmEOBqwlGFHXA5DX2On2nmN5gkzPr+l60bij073A2s3TpW90pp+GponfvgKrTlJMt1hifxEnng60AUd0PsIqPyyZAfn6O3/Aw+sPgUwpvWrW+3HXZrBkEEwurSMj1EPVXaCrywV8V+EcF2spjv/52DPIGKUmLhXxXuo+uIozH9BL+MkVckBv2Vr5gRxWyKsKxi0cz2+pfHLp55tVvHqdBo+ZcYjyrtu2DlT9+frjRUbp3c5368cs8BsJoYeKvcE3MelUwIypp8XMq/pPQ0MmrAjsI/0Mj3jHGVa8+VDldDY8r5Y4mOxXKXFfzaOxwbH8eR8B12DkZ8IdnY= X-Forefront-PRVS: 057906460E X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(396003)(346002)(39860400002)(376002)(366004)(39380400002)(13464003)(51444003)(199004)(189003)(81686011)(16526019)(86362001)(59450400001)(44716002)(5660300001)(2906002)(6666003)(6496006)(66066001)(23676004)(7736002)(62236002)(33896004)(2486003)(52116002)(305945005)(386003)(3480700004)(105586002)(9686003)(6246003)(230700001)(61296003)(50226002)(229853002)(186003)(14496001)(8936002)(1556002)(4720700003)(50466002)(53936002)(76176011)(478600001)(956003)(8676002)(97736004)(221733001)(81816011)(106356001)(26005)(110136005)(316002)(84392002)(68736007)(6116002)(81156014)(3846002)(44736005)(7116003)(25786009)(6486002)(47776003)(81166006)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3008; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; A:0; MX:1; LANG:en; Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjMwMDg7MjM6U2trY1YxTTJWSnVpcklDN1FXcUllQzNn?= =?utf-8?B?TUM3ZWFNQmNZQ3N5SEhJa2t3aUVHM3FOUlIyN0ptRitxMHl0MW9IN2w3T3Vp?= =?utf-8?B?SXdZOHdoaTk4cDB6NFZHVlZmbjBlVUV5ZDVSVVNUWm9rNzJhb3BoWjBGQjRK?= =?utf-8?B?aExaeGo0Smw2NUVKcW1QQjFUdElDVjNkTmR6bFZqRGtHVmx0aWxiMTNTQTZD?= =?utf-8?B?TzlNaUNyWllWeFFXaGlhZHp2d0FXb3Jhc2VFeGNsUFE0Uld3QWNIb3R4bGta?= =?utf-8?B?LzIwL0FPU2dMSnBPM2tIWnMyUzBxcDZ5WDkyczhUUHJKaXRLajY5TUt6OXpn?= =?utf-8?B?U2F0cEVJbVphNHhkU0hJcG85NG5KWi81RXVER2RhUENzS1E5Rkk4aVdnTnNn?= =?utf-8?B?ODA1WVk2b0gyaTNKUjNJeTFqTENlNC9LYzBYbDhjOHVXTGh3SzJoV2t1TnVH?= =?utf-8?B?UU1idFlNSDdleVJSa0JSSmZUbXZxZG10L0htN3hxNnFsdEY0aGUwS3gzejZo?= =?utf-8?B?M0laTk45bmhsSzZiMTJZTGJUSmRCU0hsT1lhNXVhYU1CbGNKSVErbzZvbTU0?= =?utf-8?B?TDBBYSs0RHpCTWNveTBZUHhxd1hLSk9RclVnRzBNaUM1ck4vREx1YTZlK0hL?= =?utf-8?B?YUdxZ3lFbXlCZlhZWDlWRUx6bVNIcU0vWHg0YUZ2anpZTERiVUNUMDNUcXVm?= =?utf-8?B?a29yYnAxU0xwMXZpZEtKa3U1NXdUcE1yeDRZV21HbVYvczE1TmNueHRuM0pG?= =?utf-8?B?V0V1RG54UXFwM2lCbUdpTXpwMFBqQ1NxdURVNGxvQStlREFqaUE0czNRWGZ5?= =?utf-8?B?THBVRTlNc1oycDR6TEtUY2ViQmIxQ295V3p6RVdRdVExNWorT0p5ei8xTkZ0?= =?utf-8?B?SHZmYzFhR0xHbjVOdnhvV283QytST2h2ZkEyVENxdmllZkx4bHNVY2MxbTRM?= =?utf-8?B?SzhDbWV5Tmc5L3ppWXVNQmt6OUxxSDU1K3BvYmNpT2wzc1BldGtWTkZyWCtW?= =?utf-8?B?QU9YNjRITHZ6WUV2aFNqM2R0ejdCaStHUkdDd1kzd3VUSjVGM3RjaU54MFpt?= =?utf-8?B?M0pRQ1ErRGlVQ3hlbUhDQTRJM3lrNkQ0Wk5uWTd5VHVRdUlISEhSQlBqRjlR?= =?utf-8?B?cTUrQWhYREo5QlEvblU4QVZ1U2pYUEhGajdpUEF4R2pQdy92T3RVTGhscVRq?= =?utf-8?B?ZXY4d2kxc2RqTENEUjVpS0xGZ0U0cXMwTXFNa25zRy95b2c4RFJVdjh4TnBv?= =?utf-8?B?dUtrMW9KVjNmdzJDOERpUlBxcHZmTVZZaXFoZlloYXFzV3ZkTUFndmNzeUwv?= =?utf-8?B?YTlCdUtGZUgyeDlvOVRLSnZYU0pIK3poWUNlNWdvekJMUnUzUGNNeFFkcW0x?= =?utf-8?B?bGJwcWtSOXp6bkJGOVlab0puS3ZKTkszdTBrRTJ3U0FDcWpuQ0VaT2VlalBa?= =?utf-8?B?MHAxM2hwVmQ1TDFJL1dtRDVsS2lUOEZHdkxRYXJyWmhibmx4NDc3YmRWekhy?= =?utf-8?B?dTJQdG9qUUg1VDUvWU1WQ2xYbldqZk9EWkY4K1d3Z3FwZnhhcm1CekFPb2la?= =?utf-8?B?LzRwNTdLa3Z4L3BTeU5lL3l3dmduTjFMU0wxZUpRU1ptNXlWRGNpSDhBV3FM?= =?utf-8?B?c3FENVdhRFA2RVpIdlM4MmJBUVFOTGtsZ1BGQW5FMWRFa3dqZVJ4bnhOZDht?= =?utf-8?B?TzlBc3JvU0tnNzhPSzc5dVVLUHlTRUJUVkpNZWJON1N1eGVtVDAzOCtqYmJZ?= =?utf-8?B?R05ja0VHUXV3cldBbGdwQ05aZGttK05pV3pNS1M1dDZKbzV3Wkx3K0Vhcmsr?= =?utf-8?B?OTQzSTVTSjk4aVNBN2RZWVA3VlN3elBQLzVnVFB4SDJ2VWVXd01SVTN4WWhy?= =?utf-8?B?VzViZll4NjJKT0NMNE5KdGtweGtaNXJMUTlkK3NiSHdkYVNrcEVOTUFVem5q?= =?utf-8?B?NGlKTGJUdVhBSFhWeUc5RG1lMW5ONzkzb1JHRGRmdlJwcUw2MC9VVWdPUElN?= =?utf-8?B?RnRiTUJKR2UyZXFKWU44czVPWW05WFpyaERDNi9CWG9rUnBGUWdTWnJSWWVu?= =?utf-8?Q?gexU1c=3D?= X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 6:NHTdcm3UXXbmldQj3EfoTrefcG2IkGdOsjiNVkYhtPUi9pW6nCjBKzP6RX51wfsCgE8fsiV5BzXiccSbTcCLVje1KaYPfv6lkIeqQyfXnEHiZe2HOLjma9O1CIMVxU9fPRJs0iOUZGhKHltXce+3wp+mIFBsGKnku8gRxLiTzBmKoJ9IgbgRMU/sWyaZmyTugTyT5Mcph45reNDk9x709UcBnbirvY40kbxg1EasK5vijvUoFeZa+qh0CDbivM63vRkFlM+kU1SofgSFwmjyeW4XvDk/8ITPwYYy3Zxrm6f2P7fLs5xFhfQ1hoRMw7DuzH/dRtIub7BIu3B/MpLHUgtoops1jOitWPWO+Ad/y74=; 5:zQYexBbENSzG6WfucYvN7ILOv4kVLyTpXvV6jlm/ItTMgVI5ZEpPPp9+koXfnmlE21hnREd3ex3fcoSdPBmhwn5hwgko07hjeH+kjtQnwc+Db0OnRrYZkGpiG6f1OTewYGbxYRBJwzeHDIXkXI9gZOSUbdOfSr2QOBkk3rApzHY=; 24:ts1yae8rf2mTz5CwJOBrVQAiSPDTJ1fBU+174s7+ROXQ3CndMEGLNaLia0GKE4rB+L5RVJyiniUckWqKVNgu21rfcU+AMs1oanZmGRFra9Y=; 7:5T3N8CB7eetbXJeCE8ubX0yK8Wjecz8ZVEioquIwFSSMdQ91reJRykPm5p7kNqTGKxgwNFaxrV9nwUgToyL8xilob8+6Q8KfBUWY6hhKzi9k2HvqroWnwl8e/UQH8yRsURThPL7Fgnjvswvk4QWHHujwO2myyhnxrfFK+/wxybKznzl0mNsVfikjhqT3GeQHivRFgULgghegqO3W/Wf4yV2/z0oXYw9FGb5WsjiqbaiUCwyqxjUE+WLS519b3exg SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: btconnect.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 09 Feb 2018 12:10:22.5602 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: f3facf7e-8825-458e-1473-08d56fb61880 X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30 X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3008 Archived-At: Subject: Re: [netmod] Missing references X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 10 Feb 2018 02:57:00 -0000 Henrik, Benoit My first e-mail was sloppily worded. What I meant was RFCxxxx in the Reference clause of a YANG module, since I think that those should be in the Reference section as well. I think that it should apply to the Description clause as well, but that might be more debatable i.e. missing when it appears in Reference I would see as an error, but missing when it appears in Description, um perhaps a warning? Tom Petch ----- Original Message ----- From: "Benoit Claise" To: "t.petch" ; "Henrik Levkowetz" ; "NETMOD Working Group" Sent: Wednesday, February 07, 2018 11:56 AM > Hi Henrik, > > Could this check be added to idnits? > > Regards, Benoit > > I just came across (yet) another example of a reference to an RFC in a > > description clause of a YANG module that appears nowhere else in the > > I-D. > > > > This seems to be a systematic error that some YANG module authors make; > > can the tools be modified to pick it up? The logic is simple enough. > > > > The latest example is in draft-ietf-rtgwg-yang-rip-09 which fails to > > reference RFC5952; I think that the I-D is in the RFC Editor queue. > > > > Tom Petch > > > > . > > > From nobody Sun Feb 11 11:14:08 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A960812711B; Sun, 11 Feb 2018 11:14:03 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.62 X-Spam-Level: X-Spam-Status: No, score=-2.62 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id tyDII_MUY9Ls; Sun, 11 Feb 2018 11:14:01 -0800 (PST) Received: from mta8.iomartmail.com (mta8.iomartmail.com [62.128.193.158]) (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 57CA2126DFB; Sun, 11 Feb 2018 11:14:01 -0800 (PST) Received: from vs3.iomartmail.com (vs3.iomartmail.com [10.12.10.124]) by mta8.iomartmail.com (8.14.4/8.14.4) with ESMTP id w1BJDxlR009902; Sun, 11 Feb 2018 19:13:59 GMT Received: from vs3.iomartmail.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 669A422042; Sun, 11 Feb 2018 19:13:59 +0000 (GMT) Received: from asmtp4.iomartmail.com (unknown [10.12.10.175]) by vs3.iomartmail.com (Postfix) with ESMTPS id 513F922040; Sun, 11 Feb 2018 19:13:59 +0000 (GMT) Received: from 950129200 ([209.48.7.126]) (authenticated bits=0) by asmtp4.iomartmail.com (8.13.8/8.13.8) with ESMTP id w1BJDhgN005923 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 11 Feb 2018 19:13:58 GMT Reply-To: From: "Adrian Farrel" To: Cc: Date: Sun, 11 Feb 2018 19:13:42 -0000 Message-ID: <006501d3a36c$77414cc0$65c3e640$@olddog.co.uk> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdOjKaRssnhzz+RERRacalWe/aU+9g== Content-Language: en-gb X-TM-AS-GCONF: 00 X-TM-AS-Product-Ver: IMSVA-9.0.0.1623-8.2.0.1013-23658.002 X-TM-AS-Result: No--2.038-10.0-31-10 X-imss-scan-details: No--2.038-10.0-31-10 X-TMASE-Version: IMSVA-9.0.0.1623-8.2.1013-23658.002 X-TMASE-Result: 10--2.038100-10.000000 X-TMASE-MatchedRID: XTE/s1WT6sGQG6Uyrf0PKLxygpRxo4691kqyrcMalqUKXKtfi06bFKPF jJEFr+olfeZdJ1XsorgUBfgS1SLQ+BbO8svD7XxHxEHRux+uk8hxKpvEGAbTDgBvlaK42jdnIQe 20Z37JI/lyoHJt4LiFErWVQkcCx6HJeJ1WMCERkGtftyYo2KwDjKpoRvzNKOP9DB8M7tiaMB/7B 6iVYd2rpRMZUCEHkRt X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 Archived-At: Subject: [netmod] L2SM working last call on draft-ietf-l2sm-l2vpn-service-model X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 11 Feb 2018 19:14:04 -0000 Hi Netmod, draft-ietf-l2sm-l2vpn-service-model is going through working group last call in L2SM. Please send your comments to the L2SM list. In exceptional circumstances you may send your comments via the L2SM chairs. Thanks, Adrian From nobody Mon Feb 12 01:50:10 2018 Return-Path: X-Original-To: netmod@ietfa.amsl.com Delivered-To: netmod@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5BBFA127286 for ; Mon, 12 Feb 2018 01:50:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.597 X-Spam-Level: X-Spam-Status: No, score=-3.597 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, 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 Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Q1MHQIVS; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.com header.b=Qi82vvuc Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y6xCrn4EAwat for ; Mon, 12 Feb 2018 01:50:05 -0800 (PST) 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 CBDB112711D for ; Mon, 12 Feb 2018 01:50:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518429002; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=yeOAScxyQJcnftG2vhQ4C9/0zzT/toPfTPxjdburHI0=; b=Q1MHQIVSRY02haMamlEs1+PcuZlQRqw0cKzbg6fXdubc9HGBINdGC/S+TOsYFGnm ridA6bC5to66dXAvP9VgUZtp6dOrhG9MzpefI3LKd79K8TB0iWp/DavMltyL48k7 hbhc5nVy7+rIXtpfXQPHShmICrzmGAbwAbfvfkr7ZDc=; X-AuditID: c1b4fb3a-728f89c0000067b4-df-5a81634afe3d Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B1.A4.26548.A43618A5; Mon, 12 Feb 2018 10:50:02 +0100 (CET) Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 12 Feb 2018 10:50:01 +0100 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=BXYnwaLLLRfGhWltgYEu4oABA39rtyeUtuMmTIl+u8U=; b=Qi82vvucnMSPxlBCTaasHTBsxau5Qf+0lwDBo+/goNaU41aYr2tD7eoTgM4sWB9UroREfNbtV7ZxjnsMXSGnrao4qwJ9gTcjeRwY6SElUudMHuhyAQ4bcaoWsIXmHoudxz9XJN6ItD37nyaMtwm6Pkd12BB/SMuPUg88YUyJxZA= Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; Received: from [159.107.196.252] (89.135.192.225) by DB6PR07MB3431.eurprd07.prod.outlook.com (2603:10a6:6:23::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Mon, 12 Feb 2018 09:49:59 +0000 To: "netmod@ietf.org" References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com> <20180208092408.ir25jwkorxozq6gr@elstar.local> <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> <20180209162526.5siyzlqgiru73nsb@elstar.local> From: Balazs Lengyel Message-ID: Date: Mon, 12 Feb 2018 10:49:48 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <20180209162526.5siyzlqgiru73nsb@elstar.local> Content-Type: text/html; charset="utf-8" Content-Language: en-US Content-Transfer-Encoding: 8bit X-Originating-IP: [89.135.192.225] X-ClientProxiedBy: HE1PR0101CA0019.eurprd01.prod.exchangelabs.com (2603:10a6:3:77::29) To DB6PR07MB3431.eurprd07.prod.outlook.com (2603:10a6:6:23::22) X-MS-PublicTrafficType: Email X-MS-Office365-Filtering-Correlation-Id: 966219dd-b9b3-4d7c-bdaf-08d571fdfb7a X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DB6PR07MB3431; X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3431; 3:ZkQcSDFARu84hP9NTuBQ0XiFY1rP4BP8jNClfMefsssqLuSMspfeEcWVVc9UFSaYtfFZ1RoQa4riljbhL8rJKBE02OhBRGDElWfdksYvbl4xQ8muOZZV8YpJDqFBMG0zhbinMgraPRr84kdo3JKyT1T229fCH/K3l1YSeTbOAdsXat8nwD9ciM0EWcuRcyj6jCVEgdb8x7WvdOQM/C5Z0nwWHVmVDrEZJNMrREVQkKBAHCdzTsv5BvA/xeICf28d; 25:s5tq7JbOdBHVs6q43hOWp4WpfalTH5rRPov0Ng5h9OwjtFf+1P49C/wbQYoI3IQ3FZSy2/1CkSYCAEtCahudtXMuM8v7VGPAyW5fHTXjL1C10Wihr86qIqrq9OZ5BCF6l+k5rUotChiaJWCfkDgcpGKifEwMuLbgFzKeh2d/eGP5VgijnMLMyq4vlKMJ0iYYAJ0QilcPIzqZTD56mHRItTgFrfgkAXKzyCXBfc9BSLiD+QEcCWcueGilwJI5m05eDOT5i32NrDrUlGtTg7XU2EBU8OVWs+AuS85HkJObfj2aA4ul7nPAm8o4OX3ewyemWT62nLsMe9kxW1G9dgkStg==; 31:tYltOXtVFEe4D/DDgmAWHDtVweG+AkXKD0EGwGaqmlVyDVj5cAMTp6iIZ5/QPraF98IdicYO30wwBdMt0b0eKfzZOxEDXOsYhJ+sbn4iWbBJxJisPgAcsAz1YjYhkAtftIKL08oT+Vn9/nmAJThH2wgFe2pmlc4ZA1pkcT3DI9LLmJBiR9SDyDZYYb0b1a+OXOYOWN6oRDpFFst51r4Lk0TcVBbIn5gXO9loxVleeoM= X-MS-TrafficTypeDiagnostic: DB6PR07MB3431: X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3431; 20:gQJ0JPqNkH2CwEG8+CwSYHG4qRdWQT4Gi0OI4AYoFvyKeu42WFNuSGWAbCO7LHFxeZChv5hkuWYEIERBCSFsEYMZk5TgMGMdBzOYgv7L/aFC3Is88s9/SXeKt8JUnTkF358WDuTRPBOLjg6zTpaHOzrJX2BPOhWU4ohKQXkSh7r9AV3dwjwdKj7d1jODHyRp+4eg/9u/TXCfmhSxGd/Gwhbi88QlXnr5QSB/13Py+ZJFaInNFcM5iLFRsZnJd0n4Ay4+qh6ZZ1JLsl8FHXb6YPf8bFWnXG5uTsgCWpa1InzrahyZIIYbrFCpuezkM1UrUAJ5Zo6sGtUhFJZ0608XCiZWiwlq9k96U1c3gA/qi98d0BRT2BWrsSQ9RtwKeLVkQuCHBgSk3+m118krYwO2IXkzUaxwH9ndzPr0DWwYYUVJ4vfy/C1JDijkP5wPOx/63fYTiRbfjnAgHaFiFkgp5yovIvAJPH5ZDH0hXceXkYCjnrS3pg3OEwLJLsT2h5w0; 4:/4djxJKkdRlfH1QraFDeULGauOWYTqFPWf+2A2rvDtyjR8OTYId69AWrqlJ2LHzGTv0cliPSs3eeF/Mtekjhww8o0Z3JA/EL03u9TTJFgxtfG7Q4XgthWNEPnF4IMTMEyrGHQMu+QHCr4amfhf6Q3jk57enggdOtgWjPnSF26L/61TcqrSALHTxmv/bl91ZUa6lfBln9IyiRqCYbTL9UWLqyOEo1BF2BRNYLVdYdIcDajXTBINGYw27ynHqeEBFtcRj6cHTwpDIejHO0VA4wRnz01zyboTsWmD2L5iVmFnXwUan0dcvtQ9Hd9mI3R6MSYgc+eWKLOV8e/arKygFjAh7HDSp76d0LpA6BmT2o/pa4H98xUv9y20V0SkVeW41o4BZdxsfywrqXPF7/gRJvR6bAznP1LdnZ2sHbDYMZVDE= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863)(120809045254105)(95692535739014); X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(944501161)(3002001)(93006095)(93001095)(10201501046)(6041288)(20161123564045)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(6072148)(201708071742011); SRVR:DB6PR07MB3431; BCL:0; PCL:0; RULEID:; SRVR:DB6PR07MB3431; X-Forefront-PRVS: 0581B5AB35 X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(366004)(39860400002)(396003)(376002)(39380400002)(252514010)(377424004)(189003)(199004)(6116002)(5640700003)(6486002)(68736007)(86362001)(54896002)(31696002)(25786009)(6246003)(49976009)(6306002)(5660300001)(53936002)(97736004)(16576012)(2501003)(316002)(58126008)(236005)(2906002)(386003)(7736002)(186003)(2870700001)(478600001)(15650500001)(59450400001)(53546011)(16526019)(966005)(229853002)(3846002)(26005)(2486003)(23846002)(52116002)(23676004)(76176011)(1730700003)(36756003)(81156014)(8676002)(606006)(52146003)(2950100002)(6916009)(65826007)(81166006)(8936002)(93886005)(2351001)(65956001)(65806001)(31686004)(83506002)(6666003)(64126003)(105586002)(50466002)(66066001)(106356001)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3431; H:[159.107.196.252]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts) X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3TUIzNDMxOzIzOi9EbnVtREFZWXhqUUJaaHdtV2tDejc1NFQw?= =?utf-8?B?K3ZTU0JxWnN3R2dpYUF4ek43bHJCRklWSE1RMStGQWlFaGQ5clR0SHdYc3J5?= =?utf-8?B?dlFoQlNQb2JTM2svQ20xcWdLTm82MmQ4d0NpUklRbXl2b0xxK2R4YWRCU0lG?= =?utf-8?B?NjF2cjN1eWxjbExpdzVOTzVrdmRuMXRyVndZRHdYRzBISVl4VVg2UlBJTGh6?= =?utf-8?B?aEpxSVZpaWdDSWEyZmRFbWlOK3FPMHdwQWYvckgrN0YyWWl0VTA4b04zYmFi?= =?utf-8?B?d3hZOW5JWCtoVExVRjJSbXZXQ3J0U1BCSkk2L1dXcnBtckNSQnExSUdocVFH?= =?utf-8?B?NmlHRWU2VHdGUlZyNGtUKy9GZUh2UkF3dlFjNGZBOXU2TGprMXNjUFNoQ29V?= =?utf-8?B?SkZkSU9PeGVINW85RTdJd0pUYjlqRmJOZjJJUzArN2lJV093L0FaQTBhR0Zi?= =?utf-8?B?TjAyWXNjN2lXOGp1TGl0VkJlVUJwU2UvczUxVmRtSnRadFhmVi9Cc3M0eE9K?= =?utf-8?B?K3NjSWZiTmtiM1hHVmI0MjRVTUxweWlWQmdCTzhvSTduZGlZZ3lGekIzeDR2?= =?utf-8?B?c0FnY1h3WmVHYU5CWjNRZ05BZEMwUmVmd3M0U1lGS1RDOVdNZ0ZlOStWVHV4?= =?utf-8?B?d3QxNUcraG1ScTBEdDlMSVdFN1d5R3RRVFJMWndIdkt0S3E5dFVmRDVrcWpp?= =?utf-8?B?SkVzMjhVQkV2b09jbWsvaytlZG9ORWpvcnF3M2Z6RE5zcEk2RnFwQTNPSTd3?= =?utf-8?B?Tk91NWgyTmFTT1U5R1Z5UU9WVzRFd1NzNGhYZUhUYjk4bkE1Z3Z4REt5M2hG?= =?utf-8?B?WWtUYTRQeEVnMklabkhvUWR4RzRlYmY2V2t2YXk4N0RnMWZVYmhpTUJvYUtr?= =?utf-8?B?QUwwRnVTTXdzbFEwVFpYUTZNbWhvVXN2NDByWHc0ZkY2eTJoMnQyU2NOS1Bp?= =?utf-8?B?Sk1RdnBqVWNvdFJQQ0JTYlBPRFh0MTRFQzZsekxSeGRWSW5DNEdxeUd0S3hq?= =?utf-8?B?U0dpdWlOQlFCRDF1YlEvbm16V2V1QUIxSm4vN3drdmNoL0NSQUVGUG5jejFk?= =?utf-8?B?WGVwUWp6UlFUUzZQbVhKN2M3TnVDbnIwMEhqVkgxcDdOanBmSUdLWnZlRmhR?= =?utf-8?B?SE5TNEQ2Mk41SEpxNkRIM2p5MzhwQjl5WGxNbXBQdVkrbURYTTJPWGJkM2xk?= =?utf-8?B?R2hhMys5akpTTEVveSs1VlpFNTJJVERCejhJQkI4UkRqeUcvOW9vakZubzcx?= =?utf-8?B?UFZDNGFVOEM0WElmL2UwNXNLRDVUbktEU0Q0TXBnSTV3Y0RzSEdyQmtPTG9p?= =?utf-8?B?cm1IT2UzV3pJQUhmbjN0elRleUtDdkxQOUdiQkFxb3F6d25LdDF5RWs2bVBi?= =?utf-8?B?UUVTY3pjbUlBSkZvd25FRkZkS0RtQTZxUWhJS2R3YjZ6S2MxYUFwVVdaSHdi?= =?utf-8?B?a1FtU0NwMlNDK0xmdlZtWXp3QnltSzF6VlVFRDZFU1pDZjdWdEpLT2hXV1hi?= =?utf-8?B?b3QxcVY2ZHVNazlrV2gwOEs1L20wV1VpMFpNbzlMeFFhdmhoc241WFdaOFhj?= =?utf-8?B?ZXZnNlNueHBIOHJxWnB1Zkw4N0lCRTJ2bUV3WmF4WHdBOGNoa0tVYmlrZ0Jw?= =?utf-8?B?ZjVoMUNQQ0J6bVZYcXpGbGw1akNXU0lxWmtDUU1MSmNkMnQwRUxsbXkybGpa?= =?utf-8?B?TGZ4VTBPb3JFYy80NWJoOGpqcldZSXA4aEdpaXUydUl5b3VyZFVwa20reTRR?= =?utf-8?B?aVpOeW5nS0FXM3hFZ2E2SXpaWkVFdVdnTU9KdWlHY0N0SVVCd0hsbDFSQmE2?= =?utf-8?B?ZHpReURTZ1psdEJmSllaVkdnY0hWeHBsdTgwcHBsZ2M1THUyRVNqVjBKUUh2?= =?utf-8?B?bUhLRS9HbXhNRVZvamdIb2ZHelZUYTFZOHN0SmhjdU1oUFdPMmI4ZjE0Sjds?= =?utf-8?B?eW1HRzE5RTlrTGsxSFBJWDVpWnFSblE3cWd0Si82TTJqNW1RVnN6eThpbG4w?= =?utf-8?B?SjZQdTZvNnluOWs3aExPWGwxQWpqZFNYUTZ5eWthZG43YkZ2Q1lyMWx1Tkt4?= =?utf-8?B?NGVSMzZkc1R0MVV4bmVINlFGeG1WYWNHRkZSWGdsenJxVWRMc01JczJOWk9D?= =?utf-8?B?aHVrQjBrRUZGTHRXQ1VBb2lIMm1rSTZXRW9UV1gzWXdibnpFU3hTcUx5S05v?= =?utf-8?Q?gADlwPTbanE7MjrmNollDxvqDL3QIs+XBsgn+wdQBQ=3D?= X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3431; 6:0I6yukPutf4rHA+M/a1g0NignwBXFKaI3GZVW3q8uQV6kQjOzTB+9LoTAljU63G+8yBwgf28o3zHpbdZdSn2bEHci+t0HyyRkrk7BJi8PaM8cpgNR35YKosxNQ/goKNjU2I0/H2Y3+iY1+6JMwTEmGQPp0vyoxFq0ju+s/+JVDjHVyz3IJXMg/lhTbF1S+VTAfPds+yKOcZT6pEAQ85rQzqD08EKVjJA6cWat4LJZjqOfLQ77RGbN1BT9giWHlUWy/we+BZADEwvDO1otWEwR6Xy3oBrVq+TsZSRbC263/BoCffsC34Gp4whwhUsEpy5uODn2mF6GpBupy34fY1DEyLMNoQIRX74DhjEfQysVGE=; 5:1Ebsubne9htj31kVo6QehMFaydJ39F0/IYyaIqLvNh4rshV7wSb6okEwCZIHwNsC81vBiHKgHh0GejD7JhDASHW+Efn+oRg6O8VctDa0Q1wKkOAGayF+R7yTK0NiMU5zGzkM6h3933mPY1PmPnQLo4h5S799amT/wOCCgvWV4aU=; 24:a2a3itmmwc7yenE9Pb+9UkzQ9xb+07Zz9OSxNgBIbPmiPIu8TLBdG2m0ZKRl8EkB3O27bJu2aKTphWqqu6lEPPkAJzv1GRjnp0BMvu2vGSY=; 7:Fgab0hO/XDq3w/LG7qKIVvBe2ShxF59qSsBW0mTJ1ObVc4ywASqcwh9SZRELpfF/rjmL4a+Fnu3Rc53mZiGoZqExZTg/G5F+rHOajUNB4iwDbWfEOiQsGaSlzgvm37oMDGdzhzZBfQ1IHvJU+81exks+D/SeyFiWXfv9yiPved8ToutA5C+W0n5taPVQb8dhZKR1kmVJel9uV1PfdyvmJ3S8NsvYmqr/JVXM0jCsWaJZ6G4U6fn+NK5AbBVQiA3Z SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2018 09:49:59.9145 (UTC) X-MS-Exchange-CrossTenant-Network-Message-Id: 966219dd-b9b3-4d7c-bdaf-08d571fdfb7a X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3431 X-OriginatorOrg: ericsson.com X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUyM2K7ma5XcmOUwfE/QhbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoErY+7Fl4wF990r/v+fwNTAuMqqi5GTQ0LAROLpnrfsXYxcHEIC hxklPm84wwrhnGCUeHHgOitIFYvAJyaJaRudQWxGgTiJnWsWQhV1MElMen4AyOHgEBZIlph5 yB+kRkRAXWLmzvVsEDWzmSSObdvADpJgEzCSmNp/ngWknlfAXmLbAj+I+aoSt5c+YQOxRQVi JKZ+3Ai2l1dAUOLkzCcsIDangLXE6z9XmEBsZgENidY5c9khbHGJW0/mQ8XlJZq3zmaG+ExJ 4tKXaSwgN0gIzAL6rOE12CAhoOaHF/6yQhTJShw9O4cFwvaVOPXqMztEw35Gid47K9ggnAZ2 iY/rGhghqrQkNn75AFX1hF3i86EZ7BCJbIm5839D2TkS17uPM0IU9TNLzO/9ygSRkJF4+3IC E0TiA5vE2+tHmScwas9C8uwsJA/OQvLgLCQPLmBkWcUoWpxaXJybbmSkl1qUmVxcnJ+nl5da sokRmCgObvlttYPx4HPHQ4wCHIxKPLwzghqjhFgTy4orcw8xSnAwK4nwzowCCvGmJFZWpRbl xxeV5qQWH2KU5mBREud1SrOIEhJITyxJzU5NLUgtgskycXBKNTDm7bOfxP1r61Tr2942r9dz r8jMfPzu9Mln8hpqgkuDP92Yv6B5s7/ClsCcA/ushG45Zy7Y6vPML+ijclyGxJ1dV/elXN37 64jW03PTrGQ8xeTfuRjceFfvHpii2mgg+71k15HLn7N0Db98e+yUkipinuWxRijGN7Lr8eyp d9ZytK7+IJl83kVDiaU4I9FQi7moOBEARGEgqRADAAA= Archived-At: Subject: Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt X-BeenThere: netmod@ietf.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: NETMOD WG list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Feb 2018 09:50:08 -0000

Hello Jurgen,

IMHO once we know whether the data is config=false or true and know the datastores the server supports the datastore the instance data is relevant to is fixed. One exception is the possible loading of dynamic datastores. However as I do not have a use-case for these and we do not have any dynamic datastores defined, IMHO we can leave the usage of these datastores out of scope. If I added the following paragraphs would that help?

"If the instance data specifies config false (state data) and the server support the operational datastore, the instance data documents the operational datastore. If  the operational datastore is not supported the data documents additional state data that is stored outside the configuration datastores. The instance data MAY be used to load the relevant datastore or it MAY just be used to document its content.

If the instance data specifies config true (configuration data)  the instance data documents the running datastore.  The instance data MAY be used to load the running  datastore or it MAY just be used to document its content. While the instance data format MAY be used to load other e.g. dynamic datastores that is out of scope for this specification."

Also further clarification may be provided for each use-case in the relevant document.

regards Balazs

On 2/9/2018 5:25 PM, Juergen Schoenwaelder wrote:
How do I know which datastore the data belongs to? Would it not make
sense to carry that information inline? If we do not carry this
information inline, how is that information supposed to be provided
if for example this format is used to validate examples included in
documentation?

/js

On Fri, Feb 09, 2018 at 04:07:11PM +0100, Balazs Lengyel wrote:

Hello Jurgen,

I will gladly add NMDA to the draft. However could you please be more
specific. Which part of NMDA are you missing?
Is it the example of yanglib that you would like updated?

As the instance-data can be used to document and/or load    both config=true
and false data it is IMHO relevant to the candidate/running/operational
datastores. However whether it should be used to just document data or also
to load data, and how exactly such a load should be implemented  is out of
scope. And yes using one SW kit config=false data can be loaded from file
too.

regards Balazs


On 2/8/2018 10:24 AM, Juergen Schoenwaelder wrote:

[Removing NETCONF since the I-D says -netmod-.]

I flipped through the I-D yesterday and I think a common format for
instance data trees should be NMDA aware these days.

/js

On Thu, Feb 08, 2018 at 10:17:25AM +0100, Balazs Lengyel wrote:

    Hello,

    With Benoit I prepared a draft about how to document and use YANG defined
    instance data. It could be useful for documenting  server capabilities or
    preloading data defined in implementation time and probably for other
    purposes as well.

    regards Balazs

    -------- Forwarded Message --------

    Subject: New Version Notification for
             draft-lengyel-netmod-yang-instance-data-00.txt
       Date: Wed, 7 Feb 2018 09:28:50 -0800
       From: [1]internet-drafts@ietf.org
         To: Benoit Claise [2]<bclaise@cisco.com>, Balazs Lengyel
             [3]<balazs.lengyel@ericsson.com>

  A new version of I-D, draft-lengyel-netmod-yang-instance-data-00.txt
  has been successfully submitted by Balazs Lengyel and posted to the
  IETF repository.

  Name:           draft-lengyel-netmod-yang-instance-data
  Revision:       00
  Title:          YANG Instance Data Files and their use for Documenting Server Capabilities
  Document date:  2018-02-06
  Group:          Individual Submission
  Pages:          10
  URL:            [4]https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt
  Status:         [5]https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/
  Htmlized:       [6]https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00
  Htmlized:       [7]https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00


  Abstract:
     This document specifies a standard file format for YANG instance
     data, that is data that could be stored in a datastore and whose
     syntax and semantics is defined by YANG models.  Instance data files
     can be used to provide information that is defined in design time.
     There is a need to document Server capabilities (which are often
     specified in design time), which should be done using instance data
     files.




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

  The IETF Secretariat


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

References

    Visible links
    1. mailto:internet-drafts@ietf.org
    2. mailto:bclaise@cisco.com
    3. mailto:balazs.lengyel@ericsson.com
    4. https://www.ietf.org/internet-drafts/draft-lengyel-netmod-yang-instance-data-00.txt
    5. https://datatracker.ietf.org/doc/draft-lengyel-netmod-yang-instance-data/
    6. https://tools.ietf.org/html/draft-lengyel-netmod-yang-instance-data-00
    7. https://datatracker.ietf.org/doc/html/draft-lengyel-netmod-yang-instance-data-00
    8. mailto:Balazs.Lengyel@ericsson.com
_______________________________________________
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

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


      

      

    

    

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


  



From nobody Mon Feb 12 02:47:33 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5DF641273E2 for ; Mon, 12 Feb 2018 02:47:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hws3zbEQq1YF for ; Mon, 12 Feb 2018 02:47:29 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C89CB120454 for ; Mon, 12 Feb 2018 02:47:28 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2392D675; Mon, 12 Feb 2018 11:47:27 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id NvGr_wWARbXA; Mon, 12 Feb 2018 11:47:24 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Feb 2018 11:47:27 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id F25BC2014E; Mon, 12 Feb 2018 11:47:26 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nVegIfAoUWTF; Mon, 12 Feb 2018 11:47:26 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 87F8E2014B; Mon, 12 Feb 2018 11:47:26 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 99AB74242DE2; Mon, 12 Feb 2018 11:47:20 +0100 (CET)
Date: Mon, 12 Feb 2018 11:47:20 +0100
From: Juergen Schoenwaelder 
To: Balazs Lengyel 
Cc: "netmod@ietf.org" 
Message-ID: <20180212104720.cydwwzeo5htxvibl@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" 
References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com>  <20180208092408.ir25jwkorxozq6gr@elstar.local> <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> <20180209162526.5siyzlqgiru73nsb@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 10:47:31 -0000

On Mon, Feb 12, 2018 at 10:49:48AM +0100, Balazs Lengyel wrote:
>    Hello Jurgen,
> 
>    IMHO once we know whether the data is config=false or true and know the
>    datastores the server supports the datastore the instance data is relevant
>    to is fixed. One exception is the possible loading of dynamic datastores.
>    However as I do not have a use-case for these and we do not have any
>    dynamic datastores defined, IMHO we can leave the usage of these
>    datastores out of scope. If I added the following paragraphs would that
>    help?
> 
>    "If the instance data specifies config false (state data) and the server
>    support the operational datastore, the instance data documents the
>    operational datastore. If  the operational datastore is not supported the
>    data documents additional state data that is stored outside the
>    configuration datastores. The instance data MAY be used to load the
>    relevant datastore or it MAY just be used to document its content.

Having to guess the datastore from the instance data feels wrong to
me. It is not robust.

>    If the instance data specifies config true (configuration data)  the
>    instance data documents the running datastore.  The instance data MAY be
>    used to load the running  datastore or it MAY just be used to document its
>    content. While the instance data format MAY be used to load other e.g.
>    dynamic datastores that is out of scope for this specification."
> 
>    Also further clarification may be provided for each use-case in the
>    relevant document.

Why not make the data format robust? What speaks against indicating
explicitly to which datastore data belongs?

/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 Feb 12 03:14:25 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 90B1E1275C5 for ; Mon, 12 Feb 2018 03:14:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=Dd2bD2vk; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.com header.b=LIRdF7qv
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HbA_klhLfs1Y for ; Mon, 12 Feb 2018 03:14:20 -0800 (PST)
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 5B5651241F3 for ; Mon, 12 Feb 2018 03:14:20 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518434058; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=eguAZboJpfDgu2gys8o9UO9iLTNvxTClSeL3R+mDtwY=; b=Dd2bD2vkHPRd2ZangnGblPgqNpoJt6mwHJsymW+5t96sXvsvI9cFhzl5vh9y2AMI NL71PHzgUztUDeY7BLtl+wbiwgam8xbG5EiSBhakpNvfJB+Bjdy6mYm1sItUDdOZ 95T7rlPYq8i4ENGiS6xEfc67cr3L1Nz1/2C2gRRQ/jc=;
X-AuditID: c1b4fb3a-35fff700000067b4-15-5a81770a7ff3
Received: from ESESSHC012.ericsson.se (Unknown_Domain [153.88.183.54]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id 17.68.26548.A07718A5; Mon, 12 Feb 2018 12:14:18 +0100 (CET)
Received: from EUR01-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.54) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 12 Feb 2018 12:14:18 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=JFw+VNNN+61FLf18G8iCuUCsBuGRCg3IJHnQuMMd4vQ=; b=LIRdF7qvn5zTwx1BvU7HfOxfuMfYjTfmJhryEF4GYfXZ3LH73HNMKMM7sTdnmdPBFU78LIJBQYstLWveZa+78yYdtVhrzCg6Hw/IQ15IVpMguwWLLmA6+oZtNcIgtvL/ZBUqPB8nHY0vP5wRErpBS/50s/XmxXzug0dG8zrV4QI=
Received: from [159.107.196.252] (89.135.192.225) by HE1PR07MB3433.eurprd07.prod.outlook.com (2603:10a6:7:2c::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Mon, 12 Feb 2018 11:14:16 +0000
To: "netmod@ietf.org" 
References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com>  <20180208092408.ir25jwkorxozq6gr@elstar.local> <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> <20180209162526.5siyzlqgiru73nsb@elstar.local>  <20180212104720.cydwwzeo5htxvibl@elstar.local>
From: Balazs Lengyel 
Message-ID: <2af89159-7fa3-1017-3105-59675ca1f62e@ericsson.com>
Date: Mon, 12 Feb 2018 12:14:11 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180212104720.cydwwzeo5htxvibl@elstar.local>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [89.135.192.225]
X-ClientProxiedBy: AM3PR07CA0134.eurprd07.prod.outlook.com (2603:10a6:207:8::20) To HE1PR07MB3433.eurprd07.prod.outlook.com (2603:10a6:7:2c::12)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: e290d7bc-a974-4878-6562-08d57209c175
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:HE1PR07MB3433; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3433; 3:0fz3YmR3DTYR2HhYFSOEeu5y9T9PzxIIYyLWa8srGRtxb9fT5+iz6B69B/PYteD56SJSEpkS/dILEzCbJsheucAlZFFaMRe+5v8wev/T4vRedI+liyri6kZWMxR+c/wiLbr7FSCqolaOp2+FIZ43FcXKNohmx0hfwjBYBfZ8MVwf6Yus8S6E6HEg4TRrXEANRO+4lCYV1L4YhzoMQWi2rqixsvH6w+iT040Ib69w+wRSAs3Gms0Hl79zdtQ2gEBp; 25:xCQ8dWEObnGIkF3CY6nIXzh3CVhQVkNyXgMjCyfC1jfN3iRY95aHjlQawZ5iKkVI5DQuoPKRrMREywoi2kh0ovSscQUyzGu3hpq1K7FdKpRCjWrBfmRlbZ3k5zIXiuwgnHHpOVEIiTSmVVptJC2Dcl8L0AtXnx8DuhoHekeK8XAMABos/b7hDiZ8E1fnXTWvdavfmcHOHZWviO/2+IQqVIb9JKYDZf2QEdR1UN7ZQPQNMPCMM19beKbq7ybw1PZ2tIDfE8pOfl/kDoG0T03uDw88tNKFeLJd3rPncOlss70Mnc+FvW61XRsPaCVKGbHAevZlIeWKcHSL+wncfmo4KA==; 31:s88NUCmHVHZBMDXxzYf6Gxp+qUsn23ZdHihS48pdO7n17dXX9q5/xo0k+rMbsR+cq/0BkSz3D6gJFg00VAhJMbxBK08FuXHZnqmyVA2CWP9xPP2oO1QM8MwMlIdpflVkDSI+kyI8FApCDyOSkIfM0W02VbTTDKQMeJws4pPI4mB3WPJAYHECCPxUVz8991lQ3SvESpM9b0bB9rFTZMxNtZ1AmkyAdjM/vc1e1yHw9qE=
X-MS-TrafficTypeDiagnostic: HE1PR07MB3433:
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3433; 20:lw87RTbPqtpZwtnHb/mWbJAun4ezrzt8YYXpcsFSqPEMEREPZ6z80klmUekoCveNEVwq+7fC8Doj2rPk5cE6mas4oj1mi84v/EiAi6+9I0Yu5101PuIGjWh/l7GQknQg1n08btQYqXN4Db6cAAQIyTUDLrjgSYcWpvTmwATJ9D3D725zHkrdulw4Meaff87C0N1NL/qES0yxufhXh2kxG33sv4HRQSi3xvMjeo2mGW4Q4w6vgSXZ+h/u4DpNWfE3g4iL7S+g3UXGBs3V7Pz5lL0/aI8hl2uQgVxnERykaUtruGSRBfWqLtm8N1SzUd/GsnYoMI5T2zUOw6IrawRqmBKBE1b19dfkfLVRQZFgeCXI746ZWx92CRfL6jwBE+Xy/LdP4v4420rb8NSIOeaTMZMtFScezS9Mtyhb6KrtW7xVFnkwkPQNxtZxCL6HcwWsLlhzXpo/HtBoWdHNP5vWjRHpBtCYJxuQSerceNQI1qZSUsquiWwCCeVL4zLmCP78; 4:jydcSJrHl2TCGlaoewBj1DHXEpLjKZ2B0nh4F4bND7yyti2iV3AyrV+vrNDV0j8s4kcYTTjiY9dvtWfs2uiANmLuhGTxJNwuxEjVTtFfby80oLxl1DfZfQa4ZJTOOIwBUijCWVf9T3rGrG42ikG7in1MzyjLt4fqr2z/+OF7DGVUFHqedElNhoSdErPtgiVZ9TG7o4jwLekxwU5SOwVsJR/rSaio4bVX5afcSbpXVjrKo/WArqbceuwdZ2Gavd80HzYqJh9XMibcz3x7BiYTqkVDOAF5GTvcQMbCTwFF5BiyIT9S1qhV8l9mXOl2677xrYHW6lkO8tq3aSexMY798ZjEfNp5Q1o3ra0iIY9lh5U=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(944501161)(10201501046)(93006095)(93001095)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:HE1PR07MB3433; BCL:0; PCL:0; RULEID:; SRVR:HE1PR07MB3433; 
X-Forefront-PRVS: 0581B5AB35
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(346002)(39380400002)(366004)(396003)(376002)(39860400002)(252514010)(189003)(199004)(2950100002)(5660300001)(6916009)(81166006)(8936002)(1730700003)(6666003)(65826007)(81156014)(8676002)(105586002)(53936002)(25786009)(6246003)(31686004)(2501003)(6486002)(5640700003)(97736004)(106356001)(386003)(53546011)(6346003)(16526019)(26005)(186003)(49976009)(478600001)(64126003)(93886005)(2351001)(7736002)(305945005)(50466002)(229853002)(68736007)(83506002)(65806001)(3846002)(6116002)(67846002)(52146003)(2486003)(23676004)(66066001)(86362001)(65956001)(36756003)(52116002)(2906002)(76176011)(47776003)(2870700001)(58126008)(16576012)(316002)(31696002)(78286006)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:HE1PR07MB3433; H:[159.107.196.252]; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3TUIzNDMzOzIzOldNblJURFMxemRtRXVZN0lNKys5WXNyNnBn?= =?utf-8?B?UjJzZ09ISDZnTHB0ZzZsbG41U3c0QlBBdDllZk1aa0FxdmpHckp5bytEcGFW?= =?utf-8?B?NHErUFVoVTdRNVpJZmpKcm9PazdHNnd2VW1YUCtsNFdzYVkwYk0rMGtaU2pU?= =?utf-8?B?U2JIS3RESU1QZ05xNy9IUzdXVGE0eHRsdW5VWEUyQWNRSGRhb0t6L1c0ajJh?= =?utf-8?B?M00wdUhrZ3JxT0pnVmVia1R5QXRzcUJOcVJPcU85Qm16dnpJM3hsUTV3VUg2?= =?utf-8?B?WmNVcnhiSnpiS2FvMGNqTVdaaERwTS8vdVJhQnk2NGRRYm9adHdhb3k4eXZP?= =?utf-8?B?TkpkdlYvZm9hLytPNTJrUlJiRUhVY0JZQjRZbVY5cVJaSUo4emJ6c0FNWTU5?= =?utf-8?B?T2x6VmNPK0szS3VQNnZUOEs4RUdUQ2Q5clVtRm10bDR3dFE3aDlzUGV5NTJp?= =?utf-8?B?MlIxM29NeWZHQUlnZ051MEtkQnVVaEZTYXJwaGc0UXhmcXVIYUl1Zk9wc1hh?= =?utf-8?B?YmVTT0VlZEtKWlRWcnRQbHNoMDRWUzAxMFBXS1NVTmF0aFB3VzZucDQzaDZx?= =?utf-8?B?VFNHYlB2NUdWeE9xaVdaeGxNMFZIeDAwOUNpeTlQZWRSbG84K3B0c1VSNHJP?= =?utf-8?B?SDNkeFBDZnFvOHI0RzJHM1FqRjBOWThEWElZWG0xOHVoWUd6MTFzS1lzcVFU?= =?utf-8?B?SGh0WHVRdXFieVdxaGtNbGhnd25ZVUtzZUFNb3ozRzZBb0pGaGI3WWt3VEFQ?= =?utf-8?B?Q2xqUEZPSHZzSG44bGhqeFdEcGY4VTVzeVVWTXZWaERObWNENC95TU0veXZo?= =?utf-8?B?V29tc2FiUzViRG5xeDFjWVNSaHErK2swZWowMW9FcVNPMm5tRzlzQjN4ZVRL?= =?utf-8?B?RzlyZDFFaEkvd1hJc3hYRlNkeWtzNnVVbG41RXRCSmhGVmdZOEtHdWNka1lw?= =?utf-8?B?aXovc056RjdGYjhOWFpUdkwvczh1QTJIR1Q1NEV1QzQ3N1hpbFFCREZXUTRm?= =?utf-8?B?d09zYUVZa1grcndEZHRiYld0eHdIOVZoS1VUaGZuVWY3RnYveEYyckh1c1Ju?= =?utf-8?B?M2VkdXcvUmxTT3pTRU93Tm1BM0xtQmNOcGFSZ01uampsL1QrQjZ5YmxJZkx3?= =?utf-8?B?RnIrSkhTT1gwdUl0WkhKYnVrQWNIK05jdURkTnRmMG9FSDM1akNDQnNiNWlO?= =?utf-8?B?c1ZMNE5xbG1tcnU3SXYzS3NuaTRuQzNNRnJ0eDlhNGREZkg1TFhwZVd3SkFX?= =?utf-8?B?SjBVbUx0aTBsYkh6cC80TzYrQ3BIcjNLNDdEUkRHWktSdjZZYUhtdVp4LzJ0?= =?utf-8?B?WFNaby9xUE02N0hqTW5RSng1RmFXNXFGYU1uRVRjK24zZVpXQ2F3eHdPekZi?= =?utf-8?B?b3pXemxycVBtb21nVlFNZk00cVR4Y05rRnFDNmQvRTA4d1FoRTVleEE4V3RT?= =?utf-8?B?L1hqNWRCcWZnU2EvMGxnWG4zeHhJSUw1SUR0RjQvVUZuTS9DM0liUmtJaGVR?= =?utf-8?B?Zkx0V1Q4cndjT3I2dWlDMjRxVHk1bWlGd3NzRm5NRWp4Ymw3dDNsVytwSXBj?= =?utf-8?B?cWpTMitPc21wYXNod3hnOWxUVFdHOFA5RkM2UTBLdVNaK21EeTV4eW9sallr?= =?utf-8?B?UTRiNFM5eTVPQjNvaGZ6MmVJMEs2UWFMYzRtdUtkZFdqclBpUXByZG9Mckhs?= =?utf-8?B?ZldxdHo1Z2crdXBNY3E4VkhEaGRzOCttbktHRlBlcDdSUnZvMnU0NEJnaFpZ?= =?utf-8?B?NWFWbHJLZldyaE1UeEV5Sm9wM2lNMXgrVWh6Sk9VcWI1djg5cVdVTlhqY1hn?= =?utf-8?B?amJYSmxoOFNGNUwyb3dBNXBRcnZBU2dBVWE5RnVIUllNT1NjRmE0cko0a0o1?= =?utf-8?B?aEpicU5SMXBjL3I5b0lwV3lMK25WOHNoYzhaMGIzRzNLUGtGUzNxZ0NQcXpS?= =?utf-8?B?MUtCdzUxcTcxVWtvVXhSTFRqREN0NUZoekF4Ymk3UU5WdU1GSHdaZ002djlp?= =?utf-8?B?eThVUDM0SEZlK3czN1d5N0lQOU9CTDZ0eVpGQmg5Tnhtc0N4bjZycy9DWmxz?= =?utf-8?B?U21HaXVpQ3hKcmlvbVJOZ3U0MEJyd1pqMVF3TnRuRGV0eFpHQUFUYmxpcW5X?= =?utf-8?B?K0E9PQ==?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR07MB3433; 6:6oBaYb60TWpVTy9qyUVmXmGy5t5WF3u4oNlemRguNQ1TOqjT7w7px2el1Gu9fDI1HoUlG+XfFMd5+SldKp/n6uQGCP1o5eHHdyC3fn3fLMe5YBKD4daQ9Oa2K9AZLv9jpwOYoISFNFEnjatDcIts4uXmZYL98cQfl3pBlT+/R1zB1ycqNlwcGPo0u9g+QCkH/0X7CLezF85EtXkUelFaeNP92b2+Sjl9RkPoFXo5m1kMqZuweWCmDNSwmbjXAMU57IhDl4uMTQnOD1yfaJVDEMcaiE925Rvw2M5wktq6wavJV9NvZVLM9/pc9JE5lHgUyh62+INKwsB25R6iILj0/xVj/G5sl6EPXrUADELKXwI=; 5:6mdBXBLt2ah7pKaG/Mb8xomFeew3df8EAgDwfcdK3H7fOM/4NTIMQD5vwU13BYYADWAii42KN/QUTKMBPXgKKSc4brf0p7u0bB5YD9l+thPuEiIIQZUFDh/lK307z3+5n2Is61RKJInvtvcY2k7Q4mWwXRnnow3wiG5F+QTspRE=; 24:jzFeYQgCxkMUKIfOQrE7Wx7qYEzS/232ZTDJWjqLHxpSAkTxv5c0aNVa/6EkoL7kAT0AV65QDw2wrLXUJVtFj9hie4WrKGeZGkv+pkGRbww=; 7:Sg8dGRg3U0QaAmvG4NXyDDVk9T5ZcXuPEWpRVYqmtgP/OKQkc+4uJ2qTK64usqAB3FO0q5d+8bbtyw7t/J9Th9vp0rJQx6HIM9YTUSE61uBQafM8m5sprKHtO6JOXBqflW31OMSJ0k0M0/zJVRyhUgN+hLTI80/h10qEdRglzMk3HNO6psBFntL5FWMTDK8Y6fII1AymXDwyn1v5FpvdZoQSjgd4ED2rdrXtceX0zckMLnipR1/5aDcH00j2gb3u
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2018 11:14:16.6886 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: e290d7bc-a974-4878-6562-08d57209c175
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR07MB3433
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNIsWRmVeSWpSXmKPExsUyM2K7mS5XeWOUwaJJchbzLzayOjB6LFny kymAMYrLJiU1J7MstUjfLoErY9WyTUwF58Uqlk/rYWtgPCDYxcjJISFgIvF03l42EFtI4DCj xJtTGl2MXED2CUaJSf+3soM4LAKfmCRerL3KCJHpAHLWNzN3MXJwCAskS8w85A/SLSKgLjFz 53o2iJomZol3fb9YQBJsAkYSU/vPg9m8AvYS815sYwWxWQRUJb5c2wa2WlQgRmLqx42sEDWC EidnPgGr5xSwlph4p5UZxGYWsJCYOf88I4QtL9G8dTZUXFzi1pP5TBDvKElc+jKNBcKewijx tk0N4jUNiYcX/rJCxGUljp6dA1XjK9E/cRPYYxIC+xklHp+4wwThNLBL/D03hw2iSkti8sQ2 NojEEnaJMy/XsIC8LyGQLXH4XAZEjbdE+7PL7BA1/cwSu05vZ4dIyEi8fTkB6rwTbBJ3NrBC nJQqseVGC9sERu1ZSL6eheTTWUg+nYXk0wWMLKsYRYtTi4tz042M9FKLMpOLi/Pz9PJSSzYx ApPEwS2/rXYwHnzueIhRgINRiYdXOKsxSog1say4MvcQowQHs5II78wooBBvSmJlVWpRfnxR aU5q8SFGaQ4WJXFepzSLKCGB9MSS1OzU1ILUIpgsEwenVAOjJk/qy87o2MNpun6JR52fGzIs 9gnl5Pn6nNnp7JL/waI3TlnvOyT9TWpBvMylmG6J+66sfx/LXJm6N8xRrGdp68vZTt+X5lzf O2PzwcoVz6J9RRbNTDFcymznb7vuL0dKe/08p0+uvzs/Vz14coyp/8v/6CfOmmKRzuyO3+vO 9ajtexWz5PQzJZbijERDLeai4kQApqpKpA4DAAA=
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 11:14:23 -0000

On 2/12/2018 11:47 AM, Juergen Schoenwaelder wrote:
> On Mon, Feb 12, 2018 at 10:49:48AM +0100, Balazs Lengyel wrote:
>>     Hello Jurgen,
>>
>>     IMHO once we know whether the data is config=false or true and know the
>>     datastores the server supports the datastore the instance data is relevant
>>     to is fixed. One exception is the possible loading of dynamic datastores.
>>     However as I do not have a use-case for these and we do not have any
>>     dynamic datastores defined, IMHO we can leave the usage of these
>>     datastores out of scope. If I added the following paragraphs would that
>>     help?
>>
>>     "If the instance data specifies config false (state data) and the server
>>     support the operational datastore, the instance data documents the
>>     operational datastore. If  the operational datastore is not supported the
>>     data documents additional state data that is stored outside the
>>     configuration datastores. The instance data MAY be used to load the
>>     relevant datastore or it MAY just be used to document its content.
> Having to guess the datastore from the instance data feels wrong to
> me. It is not robust.
>
>>     If the instance data specifies config true (configuration data)  the
>>     instance data documents the running datastore.  The instance data MAY be
>>     used to load the running  datastore or it MAY just be used to document its
>>     content. While the instance data format MAY be used to load other e.g.
>>     dynamic datastores that is out of scope for this specification."
>>
>>     Also further clarification may be provided for each use-case in the
>>     relevant document.
> Why not make the data format robust? What speaks against indicating
> explicitly to which datastore data belongs?
>
> /js
BALAZS:  Sorry but where is the guessing?
The YANG model explicitly states whether data is config=false or true.
For config=true data it is always the running datastore
For config=false data it only depends on the NMDA support. E.g. the 
yanglib model will be used on new and old servers too.
Also it is an explicit aim of the draft that we should allow mixing of 
config=true and config=false data in the same instance data set.

Would you prefer that I add as metadata "ida:config-datastore=XXX" ? 
Here XXX could be running or some dynamic (e.g. SDN) with default being 
running. Or do you see any use case for documenting/loading candidate, 
startup, intended or operational data for config=true ? If so please 
describe.

Config=false data it will always go into operational or "other" in case 
of a preNMDA server; so I don't see a need for any extra selector here.

regards Balazs

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


From nobody Mon Feb 12 03:41:06 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC76A1275C5 for ; Mon, 12 Feb 2018 03:41:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JV_hDdWq-1yl for ; Mon, 12 Feb 2018 03:41:03 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9C2E81201FA for ; Mon, 12 Feb 2018 03:41:02 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id D43216AD; Mon, 12 Feb 2018 12:41:00 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id lRu-DfHvhniH; Mon, 12 Feb 2018 12:40:58 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Feb 2018 12:41:00 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAD1B20150; Mon, 12 Feb 2018 12:41:00 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id k3KODEqko0BX; Mon, 12 Feb 2018 12:41:00 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 597712014E; Mon, 12 Feb 2018 12:41:00 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E2818424301F; Mon, 12 Feb 2018 12:40:58 +0100 (CET)
Date: Mon, 12 Feb 2018 12:40:58 +0100
From: Juergen Schoenwaelder 
To: Balazs Lengyel 
Cc: "netmod@ietf.org" 
Message-ID: <20180212114058.w7tmwzimfjipoyk2@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" 
References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com>  <20180208092408.ir25jwkorxozq6gr@elstar.local> <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> <20180209162526.5siyzlqgiru73nsb@elstar.local>  <20180212104720.cydwwzeo5htxvibl@elstar.local> <2af89159-7fa3-1017-3105-59675ca1f62e@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <2af89159-7fa3-1017-3105-59675ca1f62e@ericsson.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 11:41:05 -0000

On Mon, Feb 12, 2018 at 12:14:11PM +0100, Balazs Lengyel wrote:
> 
> BALAZS:  Sorry but where is the guessing?

If there is no config false instance, how do I decide?

> The YANG model explicitly states whether data is config=false or true.
> For config=true data it is always the running datastore
> For config=false data it only depends on the NMDA support. E.g. the yanglib
> model will be used on new and old servers too.
> Also it is an explicit aim of the draft that we should allow mixing of
> config=true and config=false data in the same instance data set.
> 
> Would you prefer that I add as metadata "ida:config-datastore=XXX" ? Here
> XXX could be running or some dynamic (e.g. SDN) with default being running.
> Or do you see any use case for documenting/loading candidate, startup,
> intended or operational data for config=true ? If so please describe.
> 
> Config=false data it will always go into operational or "other" in case of a
> preNMDA server; so I don't see a need for any extra selector here.

I see a use case of having examples in documents (which likely are not
even complete) and I think tools prefer to know upfront which
datastore the example belongs to without first doing complex
processing.

/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 Feb 12 04:02:18 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD83C12778E for ; Mon, 12 Feb 2018 04:02:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D-iHBggTVGYg for ; Mon, 12 Feb 2018 04:02:15 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id CC2F81276AF for ; Mon, 12 Feb 2018 04:02:14 -0800 (PST)
Received: from localhost (unknown [173.38.220.45]) by mail.tail-f.com (Postfix) with ESMTPSA id 877EE1AE0339; Mon, 12 Feb 2018 13:02:13 +0100 (CET)
Date: Mon, 12 Feb 2018 13:02:12 +0100 (CET)
Message-Id: <20180212.130212.2080346646041413993.mbj@tail-f.com>
To: lhotka@nic.cz
Cc: netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <87fu6axobc.fsf@nic.cz>
References: <87fu6axobc.fsf@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: 
Subject: Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 12:02:17 -0000

Hi,

Thank you for this review.  Comments inline.

Ladislav Lhotka  wrote:
> Hi,
> 
> here is my review of the rfc7895bis document:
> 
> *** General comments
>     - This revision is a significant improvement necessary for
>       supporting NMDA. However, it is also flexible enough in that it
>       allows for implementing the NMDA rules in an effective way but
>       doesn't preclude the use of other datastores and datastore
>       architectures.
> 
>     - Another benefit is that the new YANG library schema can be
>       easily integrated with schema mount information.
> 
> *** Specific comments
> 
> **** Sec. 1 - backward compatibility
> 
>      Given that the old YANG library schema is carried over as a
>      deprecated subtree, how can a server implementor actually cater
>      for backward compatibility of e.g. RESTCONF clients supporting
>      only RFC 8040?  Could the same YANG modules that comprise NMDA
>      datastore schemas be advertized also via the old YANG library? Or
>      is it necessary to also have pre-NMDA versions of all modules?
> 
>      Some more explanation might be useful here.

The text says:

  The recommended approach to populate /modules-state is to
  report the schema for YANG modules that are configurable via
  conventional datastores and for which config false data nodes are
  returned via a NETCONF  operation, or equivalent.

Do you think that more guidance is needed?

My opinion is that a server that wasnt to be backwards compatible
probably advertise exactly what it used to advertise (in
/modules-state), even if new NMDA-compatible models are added and
advertised in /yang-library for new clients.

In general it is of course not possible to advertise everything that
is availabile in /yang-library also in /modules-state - if this was
possible we wouldn't have done YLbis.

I don't think this document should provide recommendations on whether
to implement pre-NMDA versions or not; this will be up to each server
implementor to decide.

> **** Sec. 1 - YANG library stability
> 
>      The text basically says that the YANG library information can
>      change at any time. This has been recently discussed but I
>      haven't seen any conclusion yet. I understand it is difficult to
>      enumerate all the situations when this information can change,
>      but it should also be emphasized that YL info is not just another
>      subtree of state data and that it should not change haphazardly.

I agree, but I think that YANG library's job is to report what the
server implements.  If the server dynamically changes its set of
loaded modules, then YL should adapt.

I welcome more discussion on this topic, but I don't think it has to
be documented in this draft.

>      It is like with database schemas, REST APIs and the like. Of
>      course, these can change as well, but everybody has to understand
>      that doing so means transition problems, broken clients etc.
> 
>      For this reason, it might be useful to set YL and schema mount
>      data aside and call them metadata or schema information - even if
>      we continue modelling them with YANG.

Do you have some concrete proposal for where to introduce this term?

> **** Sec. 3 - semantic versioning
> 
>      Some placeholders for future inclusion of semantic versions in
>      YANG library information might be useful. To this end, I would
>      suggest to introduce a new choice node and make "revision" (or,
>      even better, "revision-date") its only case. This way, other
>      versioning schemes such as semver could be easily added via
>      augmentation.

When revision is used as a list key, we can't have a choice.

And when it is not a key, it is an optional leaf, so adding a 'semver'
optional leaf in the future is also ok.

The proposal I have seen adds semver as an addition to revision, so
using a choice would not be correct in this case.


> **** Sec. 4 - checksum
> 
>      I think it would be very useful (even if not immediately) to
>      standardize the procedure for computing the checksum. What I
>      envision are systems that construct and process YANG schemas
>      (such as the YANG Catalog). They could benefit from having a
>      universal hash string as a characteristic of any particular
>      schema. Just consider how useful the universal hashes are e.g. in
>      git.

Ok.  It would be interesting to see such a scheme.  But I agree it is
not needed immediately for this document.

> **** Nits
> 
>      - sec 1. paragraph 2: s/informaton/information/

Fixed.


/martin


> 
> Lada
> 
> -- 
> Ladislav Lhotka
> Head, CZ.NIC Labs
> PGP Key ID: 0xB8F92B08A9F76C67
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> 
>


From nobody Mon Feb 12 04:51:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB669126B7E for ; Mon, 12 Feb 2018 04:51:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=NVX0Pu7P; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.com header.b=LTU6cSZS
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id a_1sp2fWp1PO for ; Mon, 12 Feb 2018 04:51:40 -0800 (PST)
Received: from sesbmg22.ericsson.net (sesbmg22.ericsson.net [193.180.251.48]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1BEDD1204DA for ; Mon, 12 Feb 2018 04:51:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518439898; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=ZRe8q4dmci41cL4Yq8Q63vIne6FZpAXPVvp+6T/AnSk=; b=NVX0Pu7P+3qSFsO1CWZ+p873pSYUWUKdgeijDukr4DgtaSFRhzLpxqckgrs28wU+ HoTohY6gDpYSt4tzOIfh5zCdG9pa1KYtMZYEH+/mNMn1sHs1h/kzIt7w6Vbq6ohi k2tKhLC1KJeVyKAV/HUY9nukWVB7jLjZNYmE4UQnY1g=;
X-AuditID: c1b4fb30-799639c000004778-70-5a818dd9a3a6
Received: from ESESSHC021.ericsson.se (Unknown_Domain [153.88.183.81]) by sesbmg22.ericsson.net (Symantec Mail Security) with SMTP id 2C.73.18296.9DD818A5; Mon, 12 Feb 2018 13:51:38 +0100 (CET)
Received: from EUR02-HE1-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.81) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 12 Feb 2018 13:51:36 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=UmrYygN4xpEKJnD30htrZi8J+xAOUsUwMLaqZiuGzwY=; b=LTU6cSZSWzi8vYXPyzwtqJlqDgBOuKtQ7JzEaEEFF3CPa7NyL6YFfsdJD7/CObisjgUOTnRmdzVBqtlwb0USDKhHuTzNIYdb8I+u3cyXDbzMbsk6NpPt0ZwJ5uIiUSaLnZUCZbxmBkEmbWLdfDG5bS2gHr0vMjLQmsU3tEsw8tY=
Received: from [159.107.196.252] (89.135.192.225) by AM4PR07MB3427.eurprd07.prod.outlook.com (2603:10a6:205:b::12) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.506.7; Mon, 12 Feb 2018 12:51:34 +0000
To: "netmod@ietf.org" 
References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com>  <20180208092408.ir25jwkorxozq6gr@elstar.local> <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> <20180209162526.5siyzlqgiru73nsb@elstar.local>  <20180212104720.cydwwzeo5htxvibl@elstar.local> <2af89159-7fa3-1017-3105-59675ca1f62e@ericsson.com> <20180212114058.w7tmwzimfjipoyk2@elstar.local>
From: Balazs Lengyel 
Message-ID: 
Date: Mon, 12 Feb 2018 13:51:30 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180212114058.w7tmwzimfjipoyk2@elstar.local>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-Originating-IP: [89.135.192.225]
X-ClientProxiedBy: DB6PR07CA0088.eurprd07.prod.outlook.com (2603:10a6:6:2b::26) To AM4PR07MB3427.eurprd07.prod.outlook.com (2603:10a6:205:b::12)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 66083dd8-9c2e-48e6-4926-08d572175913
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:AM4PR07MB3427; 
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3427; 3:owfutj72HzUZVaCq6V8RTAedVET5616lk/CVIh1iwQ8EYQSQ0EjalPVxUV+viD8qSQ9SkptDISqiOcvkt/ngnHI+gwuGM0X81bq64nbMYi589Gz9gh8c5fgAOgRHfMF6a7KY17xE/tWs/UK0jF6vsPex6eA93EIqjRwy/oc4xuJCApYu2STYXqVwbf0L9vjOWZ9mdz3M5KL43o9VrEdq935oy9B5cSHFbqTBWUobTwimPorLSMNdW536+Pml/RDb; 25:sMtoxYDqB+t7x774qzx+aBvuCguLS/7+dxiSCROkoh7GLXevejkEHnUq+WH/WgRnvwLcsa9zKyoF3H1iVpgNs+Tvh2UqUnm6fFrkQhCv8EutBfyRegA92IsbYLsxdWfrzOGaV2sJXQZX8aWxWd2RkvXMfPm5vw/bfxGu1JkPS72M6OtawlkGT5JTClwaqSFzofNoYLUL6ZMIBrziHIT/9JOgqn+YH6SwbVYJxYZhXW1VqFStAh398AKhoQMOtm13j/9cGNoJ6+iZ9DvU9MUtcf+Bd/WeTp3b0dNzYyaZdB8xg89E4Mrd/bjCGibfeaRIgF5pvmGD6ZB+cYGtATIGsg==; 31:nvk/3Egb5kmgUR7xyu0Vqdhd8Om3uxZZWm00wmQ6aHSTE7TDdfpuUmSm572Rd6laAS0wvTUYwFdsn8KHctEC+DcY9/iFL7oLE1F4WG5PrHt7zjpNzS/E73bbW/X+tvpQ1vSC9P1V5N9CxjLO7PuoTCsyfvLC21iXtURWvb7+GoyLyS0tTUy53weaysToYsdd58QFqJY5EagdWBvsIxLtJnqzy5515oLrFkDxxdd69so=
X-MS-TrafficTypeDiagnostic: AM4PR07MB3427:
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3427; 20:95V/Vur7xbEUk4TT08Abk5eKcuguTHZodi2VJr5SLNzqWob40poVFXT6/vya1PUq2Czu0yP4U0x90jpG2NQOXDQTfpJUTYxs1UKdu4NbGnBcl+iJlCTsVPgCRhkOZhG5TwWd2sIvbkbY4gJ2hdoo3T/5s4AFvCl32l/3hDIu9gSfI5jzAkM7HbxxhUQYeolV3StsyBzp4gN5YJ1rd1Vrn6BLkNQfE6Usgw01nIM4oXtSlMPEMK4GdfHvQL2vOX+nzFi2ZftMlcHkvoRz8gQnuwDyg1U+pW1kvwQUnDx1ltGmgft3V0ZF4LNZgFBqpv6DApy1mUNL804tt3wIY3Ban0NQyejBj2+CUzy67sVDYKnUNUzni/+5BnsQBgEry44cQOY2hzwB7Q/R7NrvbdhT7VMpl7pLbs3mHeZ4kVyJ+7uUEbKNTxvHA/Pd8PULFtUx5EtNAriesGXDKUGrZZqAwyQOJDa+UELs0XQ2pJD49MI5zZADAkODUYvuhYdUdtdx; 4:USgJyQsU+9xbTMJcEmMJQKIJWL8DLdo7OE7wsJinU6cJYSZvKcnoq609zRklUIBx1SCWSwBhou5f4fjibfOp9vb4wocIE5fX+kzP4huSnhCHlO1fmOtUr0U1d2gUrwgnY/BZfhaMNG/NIWPHjGco2gGxAnbPbh0MKhsc78dkOUKFjCxzB9bZdVAuo9S0wGB63wGFXn9RTRN06m3LKV73FlMXhfJD7yd3qde7CvaKAz5vWINYKu7klSzc4bOfuEmmlpwcgFUX8zHB/OhgwdnDfiF9gzayauTZr3CC19rRuFHVwwncFdmdhlNiTM8L8ELwFskfAhEAXwlvEdqR9RE5yvR70iIJ/PigcLQVotxK98A=
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322)(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231101)(2400082)(944501161)(6041288)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(6072148)(201708071742011); SRVR:AM4PR07MB3427; BCL:0; PCL:0; RULEID:; SRVR:AM4PR07MB3427; 
X-Forefront-PRVS: 0581B5AB35
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(39380400002)(346002)(396003)(376002)(366004)(39860400002)(199004)(189003)(252514010)(5640700003)(316002)(86362001)(23676004)(2486003)(83506002)(106356001)(105586002)(53936002)(52146003)(25786009)(16576012)(93886005)(58126008)(47776003)(186003)(81166006)(36756003)(16526019)(52116002)(8676002)(1730700003)(97736004)(67846002)(81156014)(66066001)(65956001)(8936002)(2501003)(478600001)(64126003)(76176011)(2906002)(386003)(3846002)(49976009)(6116002)(7736002)(31696002)(2870700001)(26005)(2950100002)(305945005)(6916009)(53546011)(65806001)(6346003)(31686004)(2351001)(50466002)(6486002)(5660300001)(68736007)(65826007)(6666003)(78286006)(21314002); DIR:OUT; SFP:1101; SCL:1; SRVR:AM4PR07MB3427; H:[159.107.196.252]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTRQUjA3TUIzNDI3OzIzOnZCU1dFNVJsTHQ2bTB1a2c1aC9zSXhIcVN3?= =?utf-8?B?OWJmMHYyQ0dORE82K0FwUDhIZTFYN1JTakl5MHEyUmJrWTFxTWNyUDFjeUx3?= =?utf-8?B?b0xITWE4aFVIT2FuQ2p4bWpDNm5HUmp1YXlYQmdhTlhmUmJsYlNlVGF3bERH?= =?utf-8?B?U05oNnZlVGRGNitWU0drZUtWdzA4MVdnNk94MUQzMkZNa3haSjE3dll5U2Fu?= =?utf-8?B?NkZoTFZSeXRveEM1Y2dLQ0R2UExFeHRDWENIMXZxMDJxRkVObmQyejh3NE5o?= =?utf-8?B?M1FPVDBzYTdhNXlCL3UxS0VoS2ZsaERlejJFNUtzUXBMOHcvSTAyMHlkM2pC?= =?utf-8?B?aW9raFlBVS9VeDRuZDdmTlZkRk12ZFh1ZkdMSVpCQ0ZsbVlxNG1zcE5EOEdH?= =?utf-8?B?eXFHblh2V09zMklFTkdkcnoxRWJ2emxFdm1PQnpKOUJ6UEg5dzE0NXphZ1Fr?= =?utf-8?B?TzRKYmt0MGtESjQ1LzlDM1E3ckZMOGt6cUxQb1JTTkFhYzN6K0lTWko5RjBx?= =?utf-8?B?UjIvMEVvQXVKUDlBKzNPSksrRUFlc21vUXF0dFI5b1NmZUxFSlFaTC9RSEFV?= =?utf-8?B?bU5VWFNOMmdWMWczUWpjYlV2NTJwWC9yZmJ6VXp3YkphZG1LMHRCU0dHR2p0?= =?utf-8?B?UjZaZG1wWFRXMzRMcHl1enJRUHZNZVZzSnR6K1hXM3MvNEhmaWVZZ3JhM1cr?= =?utf-8?B?YktYUjN6czRjdWkvUFRSalJDSXN0OGIwSnBlSWJsTGN4eERMWmE2QThWenhj?= =?utf-8?B?TDByYXh1MEpTVk1kTWVLSG81dHdDRVpKMlN5TXpDNDdtVFRwc1gzUXpwYWFF?= =?utf-8?B?VyszdGVHV2RZVVdPcGxJeEZBODZlWGZWRmRvcG4rY0kraEpyQW8vNkN1QVRG?= =?utf-8?B?ekdQTXp2M1JVbHppcXoyWENmaGVjaCtYRC9HQ0VNZ1RtbGhtTXBFRWsrU2pa?= =?utf-8?B?YkhTNW1qQW5adHBBMlR5NlBqMUhMRjlJc0VDaWdJME82WmNTOWIxaGtWakZZ?= =?utf-8?B?YnNISzRiTmNsaDRtdHlLcDBjb1FKV0VLUDk2dzlReG1GcHl5VmRLcithd0Yr?= =?utf-8?B?ZHRtZmptMmVmNE5GSG1pblk3blVUMHZ3Smk4SWFWVnJieEx5eVdJUkFoOG81?= =?utf-8?B?eHUwQTRqS3E0NkRCS1J3d1podmp1WTJjZ2lTd3plNXkxNDcxbzdER2FVcmsx?= =?utf-8?B?Q216WmpMMnl1UXpjNmxSYkZzT3o3TmhNY1lGTU1kalk5MmtGZllCYmFSdktK?= =?utf-8?B?MEZpNTN3V1lhc3hDU0hnY0x4aVg4bGxmV0grSGM2YS9uUzcyZGk4RGpNcmRa?= =?utf-8?B?eXNvK3hGdkpwdU9RaHJWYkV1akJra251dWR6N2k4ekFBWDVYOEdtazh1TTBR?= =?utf-8?B?dkZvRk9ldjlQUUR3TURzelhPN3p3Y2M4UzFieUVNWUgrMTNYaDN5aVE3YUZP?= =?utf-8?B?M1I2ZUoxUUY0WU1waGZCVGU3TFJocEdRWlRtNVNnaStuRU5KRkVIS3llRjlT?= =?utf-8?B?K1NWV3dETjlqT05KQ2NWNjlWVFVuYkZTbVQ4bEhUdW5NU1hmampHMTlVU1Bi?= =?utf-8?B?YjY5dXpuS0xTZGtEdVhWQ1pmQjlRbHZCdnA0K2JHcHRXT09adUY4L2s3a2hl?= =?utf-8?B?VEl3WFV4eTdXVWkwYzQxVStFVWU0L2FaK3VESGxWaFZRUE1kZVZkZ1k4eUlB?= =?utf-8?B?QmFJbTdOb1R3Z1hESS9zc05ORUk3Q0FSNVVZbEREbkg4Q2I2QXZtT1lPSlhZ?= =?utf-8?B?NU1Rd0NHZDREcjlPaVlWdFg5QUtSQ1pxeE9MWi9vaVJxZmF1SXZQcXpDYnNx?= =?utf-8?B?RnZVNXVrODZ4SDRFeWg4N2NmcGZacDE5S3ZWRnN5eVk3VTVTaFg5c1F0OVBk?= =?utf-8?B?MEEyR3EwNVdBOGJwOFF4Smgvb21OWWZSNStyV0RvQityQlVrYjk0TmxZbXBT?= =?utf-8?B?dks4VmJja0hIeXRrNWN4aTNqeHVzM3lUYUVOczlZQ0h0dXlGVjArWHAza3I0?= =?utf-8?B?eWxXdWtZR0pCQWt1cmllcHdBcEcwMXJtS0R6MVQxRUtZNGg0M3N5WE5pUzlK?= =?utf-8?Q?7Xtk=3D?=
X-Microsoft-Exchange-Diagnostics: 1; AM4PR07MB3427; 6:Av9ig5CrLqzTwFHdmu0/lUWYNOxHsvH6jaWW1YgqbeWP2mST+gdH28LuuxytJMSq+LHSWLgyrEjj+ztTnHf8UfLkq3cTbBaEDBN7pHDOXQ7DMX5YjGQnU0gn7fNdW2PNOEDcbuyCvNgtRLJOHe18/mxr6sxJaMgH7hd/y7meEi05Bj+cPa53jtpIuns3MTlnLLw2vlOmnbiYISeGzECcBGMTNWya3XLiJUDnH4l37dh4DDaaCgKK4fCYkT5S3Sywt+3bHdKUbFwdD3lkActQlWaGJAo3IbtVy1FZ3Vp7iw7tGThSXKkhX4gXisYTXYvWW02QKd5HluC5kbnx1fWeqV9nIR3enektbnmabN8+Xsk=; 5:H41n/lgSuWqGLqYDLLCtqxw65fEIbjWAmCV0Fs/PYnOmDqxS+p1j+fF+8vjvaACp5JfNYWp0GZO/aE/Is3Ym/nY8GgaqcnlXwF6fXvKHjDGIq6QF6VYIufJqcfYW5XD6Wab09YjYiIwt+MmZFvHJs0qcGa21SmEhyodVW6H+fVE=; 24:Rcd18xzLtUtODq0UaVlqt8tbzFAClwSGctK/MhsESGccpNfaUXsJAXIzlqNeMF3Fa0ro01SqWqTeRYtNhpKqaJoBEZrlPBkLXf/1BLmUA9k=; 7:DrJteuvCYMFYBqvBopWe/XgaTIuj3N6mwTls2F7za7Nz/Eq98Jd2SU5KWL1vErBrz9brTLBs942po0CXVQZ6J7SI3ChE8HAQnrJrWVH6GqK8IMEahmYyHuYnGHqijy38uPL3NNGadsYNodRq8hNxUECSm4OpRUDpokd+fzcFZBeOCgWGbpFjCILrlYETtdixtmzR771/yfjGPmWDOqdMJueJUglgytE3LQZ11s3Y4zjr/axBYt1kcpC23HKLRMXN
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2018 12:51:34.5102 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 66083dd8-9c2e-48e6-4926-08d572175913
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM4PR07MB3427
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrHIsWRmVeSWpSXmKPExsUyM2J7oO6t3sYog8nfuS3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXxpwLW1gLpvFVtN2+ztbAOJm7i5GTQ0LARKJx1m2WLkYuDiGB w4wSL/4tZIdwTjBKzHr7kx2kikXgE5PEi3VuEIkmJomJz7qYQRLCAuUS79e9ZwKxRQTUJWbu XM8GUfSSWWLv/JUsIAk2ASOJqf3nwWxeAXuJa22/2SCmqko87noBtkFUIEZi6seNrBA1ghIn Zz4Bq+cUsJb4/HUe2AJmAQuJmfPPM0LY8hLNW2czQ9jiEreezGeC+EdJ4tKXaWD/SAhMYZSY tmQl2DIhAQ2Jhxf+skIUyUocPTuHBcL2lfi3eQkrRMN+Rom3PZuhuhvYJb68mskMUaUlse/Y BEaIxBJ2icXvOqES2RJHdk2Fsr0l2p9dZocomsEs8fnDM6gdMhJvX06AOnALm8Sv13wQN6VK bLnRwjaBUXsWkr9nIfl1FpJfZyH5dQEjyypG0eLU4qTcdCMjvdSizOTi4vw8vbzUkk2MwFRx cMtvgx2ML587HmIU4GBU4uFtaW2MEmJNLCuuzD3EKMHBrCTC+6cZKMSbklhZlVqUH19UmpNa fIhRmoNFSZz3pCdvlJBAemJJanZqakFqEUyWiYNTqoFRp3hT71p2Hde/195FMVguFtx37kLw y7lL3m95tOpJ2HqDsuK998IkknzcKk4JPQ+6Yf181vGKr3eubp+t5LOz2TUhL2jKU6aM15Pd P9pwVNz6wNjrXVxhyOFrzXtMoLpj15SNETXFnK3O6xsehAiYzrBIeTot8NIpw18fdi880WE5 58yuZMZQJZbijERDLeai4kQAQ1xMPBEDAAA=
Archived-At: 
Subject: [netmod] Datastore metadata: Re: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 12:51:42 -0000

Hello Jurgen,
OK, I will add some text about:

datastore selection, default being running/operational for config 
true/false data, mentioning NMDA.

I will add a ida:datastore metadata that can placed on any any data-node (?)

A section about a use case of having examples in documents

regards Balazs


On 2/12/2018 12:40 PM, Juergen Schoenwaelder wrote:
> On Mon, Feb 12, 2018 at 12:14:11PM +0100, Balazs Lengyel wrote:
>> BALAZS:  Sorry but where is the guessing?
> If there is no config false instance, how do I decide?
>
>> The YANG model explicitly states whether data is config=false or true.
>> For config=true data it is always the running datastore
>> For config=false data it only depends on the NMDA support. E.g. the yanglib
>> model will be used on new and old servers too.
>> Also it is an explicit aim of the draft that we should allow mixing of
>> config=true and config=false data in the same instance data set.
>>
>> Would you prefer that I add as metadata "ida:config-datastore=XXX" ? Here
>> XXX could be running or some dynamic (e.g. SDN) with default being running.
>> Or do you see any use case for documenting/loading candidate, startup,
>> intended or operational data for config=true ? If so please describe.
>>
>> Config=false data it will always go into operational or "other" in case of a
>> preNMDA server; so I don't see a need for any extra selector here.
> I see a use case of having examples in documents (which likely are not
> even complete) and I think tools prefer to know upfront which
> datastore the example belongs to without first doing complex
> processing.
>
> /js
>

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


From nobody Mon Feb 12 05:15:34 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C41E127978 for ; Mon, 12 Feb 2018 05:15:33 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yVUDL0XXtuw0 for ; Mon, 12 Feb 2018 05:15:31 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEFB6127876 for ; Mon, 12 Feb 2018 05:15:31 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 7CDE0675; Mon, 12 Feb 2018 14:15:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id KfJd34TazuOQ; Mon, 12 Feb 2018 14:15:27 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Feb 2018 14:15:30 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3A6D82014E; Mon, 12 Feb 2018 14:15:30 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id IpD2ryy8Js1T; Mon, 12 Feb 2018 14:15:30 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id E48AB2014B; Mon, 12 Feb 2018 14:15:29 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id CF74742432FA; Mon, 12 Feb 2018 14:15:29 +0100 (CET)
Date: Mon, 12 Feb 2018 14:15:29 +0100
From: Juergen Schoenwaelder 
To: Balazs Lengyel 
Cc: "netmod@ietf.org" 
Message-ID: <20180212131529.h6whdwwprbdruza7@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" 
References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com>  <20180208092408.ir25jwkorxozq6gr@elstar.local> <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> <20180209162526.5siyzlqgiru73nsb@elstar.local>  <20180212104720.cydwwzeo5htxvibl@elstar.local> <2af89159-7fa3-1017-3105-59675ca1f62e@ericsson.com> <20180212114058.w7tmwzimfjipoyk2@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Datastore metadata: Re: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 13:15:33 -0000

On Mon, Feb 12, 2018 at 01:51:30PM +0100, Balazs Lengyel wrote:
> Hello Jurgen,
> OK, I will add some text about:
> 
> datastore selection, default being running/operational for config true/false
> data, mentioning NMDA.
>

Once again, this is ambiguous.

> I will add a ida:datastore metadata that can placed on any any data-node (?)

On any data node???

/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 Feb 12 06:09:24 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B954B1270FC for ; Mon, 12 Feb 2018 06:09:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.321
X-Spam-Level: 
X-Spam-Status: No, score=-4.321 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=ericsson.com header.b=b8Z6gtoI; dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ericsson.com header.b=IwL25JtP
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zM-AgV7zShXg for ; Mon, 12 Feb 2018 06:09:22 -0800 (PST)
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 3A11F124C27 for ; Mon, 12 Feb 2018 06:09:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; d=ericsson.com; s=mailgw201801; c=relaxed/simple; q=dns/txt; i=@ericsson.com; t=1518444560; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version:Content-Type: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=opDv95zttIL6kTGk4GAssXAx14puQkTob9nLPQr5Iss=; b=b8Z6gtoIRWmGwc1qE4JMVaqpfRqdCpLiV/QSvaii5bzO5XTUkrWfNy3nEKQIgJVn PklrrYZhgNnTlOMTehZMHS4EqsSYWkx6zndBY56FLMUd9dOJxtj/A6QjtyT/LScp mkW7xr5z7R6OOyjYkjR9L/UYE1K/xQxDOf9hywlq77I=;
X-AuditID: c1b4fb3a-35fff700000067b4-80-5a81a0108d0c
Received: from ESESSHC019.ericsson.se (Unknown_Domain [153.88.183.75]) by sessmg22.ericsson.net (Symantec Mail Security) with SMTP id B5.9D.26548.010A18A5; Mon, 12 Feb 2018 15:09:20 +0100 (CET)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (153.88.183.145) by oa.msg.ericsson.com (153.88.183.75) with Microsoft SMTP Server (TLS) id 14.3.352.0; Mon, 12 Feb 2018 15:09:19 +0100
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ericsson.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=oMtF3Vf23wDKmG4NPTawCqZ7xQZMsuZXh1x3+z0UA1I=; b=IwL25JtPg4CuttRURJQ5QCFIflqDFMxkeKUr2QE+D50QitEFjNxv07GX7FpTrq76ZGdG3FenM9GVjfgB6XmuxKMo5iWuXpzBwYh0uehDUOntmbxhaDV1ava79vyLfB9n4WR3A7itWBnkQ+wBrRodK8Ye2kPJh4zH/AM1H5NP2iw=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=balazs.lengyel@ericsson.com; 
Received: from [159.107.196.252] (89.135.192.225) by DB6PR07MB3430.eurprd07.prod.outlook.com (2603:10a6:6:23::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Mon, 12 Feb 2018 14:09:18 +0000
To: "netmod@ietf.org" 
References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com>  <20180208092408.ir25jwkorxozq6gr@elstar.local> <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> <20180209162526.5siyzlqgiru73nsb@elstar.local>  <20180212104720.cydwwzeo5htxvibl@elstar.local> <2af89159-7fa3-1017-3105-59675ca1f62e@ericsson.com> <20180212114058.w7tmwzimfjipoyk2@elstar.local>  <20180212131529.h6whdwwprbdruza7@elstar.local>
From: Balazs Lengyel 
Message-ID: <134cc8b0-21cb-1bc7-122c-15a79037d93e@ericsson.com>
Date: Mon, 12 Feb 2018 15:09:08 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180212131529.h6whdwwprbdruza7@elstar.local>
Content-Type: text/plain; charset="utf-8"; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
X-Originating-IP: [89.135.192.225]
X-ClientProxiedBy: HE1PR06CA0148.eurprd06.prod.outlook.com (2603:10a6:7:16::35) To DB6PR07MB3430.eurprd07.prod.outlook.com (2603:10a6:6:23::21)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 5c0bff7f-80dd-4f56-170f-08d57222352d
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DB6PR07MB3430; 
X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3430; 3:ag9IHuCNAnZ24J67BK0+T9+Y1+dgdVIgMPXu6f6/f5MxNg7Hbz/4VIMeLkzAgmFrJuKAmZnyarxDIJL+iESlExNuFHQN6rdftfy+X5dTuxvmpyE2hrNEGm4iBez5ut4EWR3+52UxYUD8o/Y5YaDaEt8JS9ORe0xb1GjQpEgCqlLsWV6MxTPH/OD301G/BahazejBJ2TANbZHab4G5ht86fQYQOV0w8Cqpa0B0oo/fcbMSXFIIx+4zaItAIDVha1D; 25:QnUuNoKgzUNlLs13eU3uktDRnsdOoeZrrDYsAgA9hln/8hFR+ARHxag/49sOO1f1N6pj+bgyuv8Ni2N2ExEpXhHKBa8Uazq7GfOj4eVuXhDc6IwHLofL5kXDqM9K3Pfn4zaRzz54uUr2LkZJXyhU4qTVPanXKzSDVOntGNPT5ehAZsIzMbVaEExCx3F8L9kISI9B8IezHCKS3cEvhCRJTQZndffLvEl871voQeLF7CmGF2CYMn23to/C9thbBDpRg62tcYlkuidB4ngsO1TrvJHz5zxjDV2PCE+TMv+i9n7qwlG+9V1BBWh1We70ulB6eGouwnYkf0HYZ4mTg+CEgg==; 31:4wcBg3Azi5mMbdTxpk8s0QnIGSxK/VRdt00vWMs4oYttaMm1Z/bSGdex62SyUqNCmOb/9ddE63hLry7W5bck9SpFU9rlyq4Y436Srg2z7APq/iJ5YtR7F10FSs6qxrMExf7/pQXwuQ+aHq2tFoOuDzLDyWBcKLIV05Jgn3YWJkh1rCLuKTkHGgxbokKY7iS37XlygymLK/4zt+8XoxMkwHdo+nb1XL3mWHkjNVdPyPA=
X-MS-TrafficTypeDiagnostic: DB6PR07MB3430:
X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3430; 20:cILFPVypErRhfPt/5LY5SsfQOpxB5rlwY52VgN232scjp7bkBfPMJn8Yyiak/opfZO6TNAsLKi3VApLJB0wR6MRx30RhuRuXU1qI6BkTFqrJd196id+BAwkq9u0g5P6mAF3fVPbsOuzCpkhPlXXu4RAdnYHiSztLoHtERk2dYh1EsEkqB3wGU+vYNB7VTjrSc36iM9bXIXk0ZXtdjxsW35GY5xIL6U7AoUw4KhQOJKyNAqe5cpGB0oqHBsofM/2CniL2T+lNtvtYd+gFnVYmidUnA0z7eIobLVu/TmmNkefd4pIUZ7iccIhRU/TYWyJFw3cezxli/6vrliA7Yg3Aowe9DQ7kjgPJ3WxPzXeKGDvZKJhorsGbB6xnP3pl4uO4Vtd1/ksizKZGkeTgMmQxHvOz17eQYTLHDma+0oRPqs2OhX3+GhdEWEc5L0S9kUoM1/AcB1jH66E6ogJ/iberXV3/x3qbqX/GBM9rfDfEop3q3+sY29SQ0St1xwM6GA7p; 4:XAx9bbPyeyomyjyWEExMBaH1BYCtp2Km5YEOJLoq3VyB9Qz+a8440RefPpwWfB3jS9a5r3DpFdnvF+rkyQM+z3R+Q8dKTnQuOStBHyTp6bqixHNbgrTy0HqXskRhATzioDoSw/YrN47ePZ/UZq9P+His5t4mXMz4oEp6VPx6sUw2YhhzcbuKmpMobntZ0Uy9ZgGmhQFrTUBKhikXN1LMEmbENzSd5QgYkW+Fn094a4kIQLMNQb0d2WFja6MkAzc8SgcQu6s9qBeCKjYTOLoDhiueFcTNe0m5Z1EgjCAsSDGxlYDS1JRmbv6IQ+i1IFD0
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(37575265505322);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3002001)(3231101)(944501161)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123564045)(20161123562045)(6072148)(201708071742011); SRVR:DB6PR07MB3430; BCL:0; PCL:0; RULEID:; SRVR:DB6PR07MB3430; 
X-Forefront-PRVS: 0581B5AB35
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10009020)(6049001)(376002)(396003)(346002)(39380400002)(39860400002)(366004)(199004)(189003)(252514010)(2906002)(5660300001)(93886005)(64126003)(386003)(58126008)(53546011)(49976009)(83506002)(2351001)(229853002)(67846002)(76176011)(2486003)(6116002)(36756003)(316002)(106356001)(186003)(3846002)(86362001)(52116002)(50466002)(26005)(478600001)(52146003)(16526019)(16576012)(23676004)(81166006)(7736002)(305945005)(68736007)(8936002)(2501003)(81156014)(31696002)(6666003)(65826007)(230700001)(66066001)(8676002)(65806001)(25786009)(97736004)(1730700003)(53936002)(2950100002)(6486002)(6916009)(65956001)(105586002)(31686004)(5640700003)(47776003)(6246003)(78286006); DIR:OUT; SFP:1101; SCL:1; SRVR:DB6PR07MB3430; H:[159.107.196.252]; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en; 
Received-SPF: None (protection.outlook.com: ericsson.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtEQjZQUjA3TUIzNDMwOzIzOjVTUWFIam1idzljenRKWjBsTTFtY0Rsd1pR?= =?utf-8?B?S2NCckxtUEQ3bFNFMmM3cDVKb0hpWTU3MDhBZjdLOVZRa2E4VXd5d21Pb24r?= =?utf-8?B?OGhLRWJCRk1vOXM5RDRwTytpcnpUa3FVTTQ2V05vZGNlYkdUaDBNYTlRMElt?= =?utf-8?B?c3VwanhpMHpUYStrTjdUZ0VIRjhvbjI5OGk3c2VvM0RaMmYweFpyNmo1cVRq?= =?utf-8?B?VkZMTU42a2gzQ05SQ0xnZXhJSjNNSnZJYTBrVndBV1BldmVSVzZ6M3FOWXAv?= =?utf-8?B?VDlVcHJuazJvMVIyVVg4Y2pOeDVnSUhNS2szTGp4SmNSOUMzanpTU2V4VUNw?= =?utf-8?B?YlFaS3BQeXo5T0Jkbk82cFFPSGsxMzNLenFkeWhFZlF5Slc1VzB6TGlMM3Nu?= =?utf-8?B?QllUMkJlNmZqTXRhMVJFT0d5L1VpRHc0c0ZTWW5MVFFHWEtiUTZXRGJZWmts?= =?utf-8?B?Z1c0VmNKZU5SNXJtQ0JKRm9pT05Dci84L0RiVXgvZWR3ZWhBNXlDNzZoRGJN?= =?utf-8?B?Ym9sUEJyRHY3TUFhNnpPam9LUkhUVTFvTFZpVUxNcUphbHpZekFJVG54RExu?= =?utf-8?B?ZGRhVHdBbXBaVGFiQmJZeWJGbXBHcyt3WlFyeE52eDh5c3VyaHVodzVndGd1?= =?utf-8?B?ZGdnb2VRYW9GR05CcXdHTWhxWi9nM1dkVlVPT1lFTktzZlhZNlAyR1JNU0o1?= =?utf-8?B?a0lyeFFUcW0xVmpEWkNJMzYrOUcyTklDWGw5QkRSUkM3NTlycERrTGg4WjdG?= =?utf-8?B?c3V6WW84bXlxQkQxekVHMno0bWVvd1B2Z25pNkpUUmhQd3F5VWdETmpHS3dE?= =?utf-8?B?ekRRNDFTbGlheGt5TEVBdEVuQytVLy9qUnFkWWJJOUszOVlyMmRVeVBISlpM?= =?utf-8?B?WFdVMnA4Yjl3eVoxdStpNmo3T09BT3pUd2t6ek5LTklBWlorazhVSmFVaGd0?= =?utf-8?B?dnpaRExNWmlhK2lLdUpZVVo1ZFIrbFZOc3Q5blpGczltZWJUeFZoeEw2eWNL?= =?utf-8?B?RmdMSFlGVzJIM3VYVVR2cWFtSG0ycDBXb2FHZVg0MngzcWw5UGZJZ3hJRmda?= =?utf-8?B?WEVDLzQ1bnRXMGViS2hyNGF4MTN0OFozNGtoYi82ODhxRW5jd3NXckRXY3V4?= =?utf-8?B?RUNNMzRjTURmajR5aHc4dzFhVWJvQkRLZWZhZEVTOEpVZWFYSHBHZzFXajNm?= =?utf-8?B?N3Q3UjBXTjZrc0YzSjZaRlFpQm9IdTNzMGFUMmREQmJNK2ErcytQeEhHbzQ4?= =?utf-8?B?UVBLWUNNTGpHc1duRGs2U016YnB0bUtuWmFDZFlhcEpTenhhYzhTWUdQa3Ez?= =?utf-8?B?Q1FIcWlqOVhnem5zZkdldDZDMTZSdHR2U0Q4aVpVN0JKUGJxcHI2eVRucjZp?= =?utf-8?B?TXlCcGFlcGtDK2ZIeS8ra3grZFZWeGpwWXdoTWhqcTM3ZEhFbkcyQXJnU0Nh?= =?utf-8?B?Ri8wM3E5anIwTG8xZm04R2lGZXZpNXNtWi9ub2M2UUFyb25hT2sxeXRDOGx5?= =?utf-8?B?ZkdtNW9yM3J5SzRBL1VGN2RmcW1NRU8zaW1HMnJUaWgwQlJZWmREYm8zVHV6?= =?utf-8?B?ejlLaFJOcm40OHFyM1JJdHdMUEZWbVMyd0hVaVlJcUZidkRFU1I1OEJQS2ti?= =?utf-8?B?aU5ocDhKZ1FiMERROS9mMW9UbEw0QWF6VFBjVlQrVWZrUUhvVWJPc0l2OTFz?= =?utf-8?B?a2p4aWROdTRuVzhnVEEycGtkYUZhSnR3MjRKNTRWMWFyYnpEQ3dmdzJsR3di?= =?utf-8?B?OFZvS1RCQnRYV3FscHNscTR5aUZPUzRjaDh1ek5sMG56S1dnS2NWNnZJdlJm?= =?utf-8?B?cFR5RHo3ME11SUpxZEpyaUVOUkhmYkZ3YzRIcHdNWmFVK0lGNWJKeVRwZkhC?= =?utf-8?B?SzcvOFZDdFJ2OEFJMHRUaFhwOGprQ09aNXF0ZFVuaUNhY2E0UHRSdnNNQ25r?= =?utf-8?B?R0ErSmRTY2YrTmNlaU5IMUd2Snh4eUhjS3M1eEhNczVSTFFBbzkwVXlEYkRX?= =?utf-8?B?SEYwZzZPNHFrTnE0aFdraUZDcXVxWVRZQUNXRU9XZUFyYVU2YmdIVFhnV0xH?= =?utf-8?Q?YS7U=3D?=
X-Microsoft-Exchange-Diagnostics: 1; DB6PR07MB3430; 6:K4FE9jwOLc+bnkWJVa6UJ8bhkIYmqC9IFPe+3ifZqeaq9XaoJdJsTTKoyERJJhmp3oDDadE5GEL8jCD+xLSdK+GT8Aygzp62wf1VhnoCPNyflyAlmpxqPIkJkkv68Jsc+OYCP0sLfUhTAwnKa4Vx4SXjyQxafjNyBG/SIDgiSMPHq4SM4r8TA0UQASIA2BkaZPDkK0R3bI5/5RyN2bRCi6PAfCmbQL8lF30j+YlQkghKQ3D9AkQWzOyPY6mAs4eCaudbBBM9tKHXivmUxzLlgyWwxjYUM65FTyIC5WhmB04fn9sPIEemsLsZHYzm0vXtBE8szilcEPXQYzjIgjB+uKMJpa1vCVuKlA2PzIP2ORI=; 5:ntEZJ6O/YX0oFQHaEKVJVXXGsmNXS5iIa1PbbRGdOWeF45VdqQ5DdcRIF7WXP4ZuZPsJBZwivh/YbQRqJ7bDEp/0XNSTlOqOUWKTgH3xM7HGthBMwAu5ZSk5F+gZqmmtWrgWVuicOzDdW/eXELlm/S44yhOVDhiqYsDTBBpI3uA=; 24:4Gp6Jo1PFeIpy68DgLVvR3EWBfaEzsdwBAEBhH5Jt8l1rVQQEFVMUXrBkqM6FSDpZ12bEcIXSL9Hx8+uMYKFlNsqJ3UDLWwpnrN2dSU9GU4=; 7:ZZk/1czLs3pRmNsHP0us5VfoTG8J1hnOff4dcUbppFxo+e/hAIUzzS3KH3qZH0kqDlfSDMafPPu46jFmYR26I5VnPeYaXUrLbDkZmsOBWQopo8W0I97tAafm1WQ/E1AEp0sMfDzvf1tW7FlRd2qV9yxtNZm7cad3iFz+096MoBlG5w9Cfz+f1OuiLLToKCiwkTK3o6pS0iQPLilNFEbduwIzB3HkwAdT96qI/93JIpoMMB4G+ibUq1b7rOXdyZHt
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 12 Feb 2018 14:09:18.6426 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 5c0bff7f-80dd-4f56-170f-08d57222352d
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: 92e84ceb-fbfd-47ab-be52-080c6b87953f
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DB6PR07MB3430
X-OriginatorOrg: ericsson.com
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrLIsWRmVeSWpSXmKPExsUyM2K7t67AgsYog6kvlC3mX2xkdWD0WLLk J1MAYxSXTUpqTmZZapG+XQJXRsvsZewFT1grrl6zb2DcztLFyMkhIWAisfzvOvYuRi4OIYHD jBLbP29kgXBOMEo8OvwezGER+MQksbhnCzNIC6NAnMTONQtZQWwhgQ4mid99WSC2sEC1xOT+ X2wgtoiAusTMnevZICZdYJG4vPAbE0iCTcBIYmr/ebDdvAL2Er9WHwYbxCKgKrHr6nSwGlGB GImpHzeyQtQISpyc+QSsnlPAWuJW13RGEJtZwEJi5vzzULa8xPa3c5ghbHGJW0/mM0H8piRx 6cs0sA8kBCYzStzeu5EN4moNiYcX/rJCFMlKHD07BxoYvhJ7dnWzQzTsZ5Q4euUBI4TTwC7R /LaBGaJKS+LLuR9MEIkfbBLTts0CSnAAOdkSP1Y4QNRYSbz+9R2quZ9Z4vvz1+wQCRmJty8n QDVvYQOG0m/WCYzas5D8OgvJf7OQ/DcLyX8LGFlWMYoWpxYX56YbGemlFmUmFxfn5+nlpZZs YgQmioNbflvtYDz43PEQowAHoxIPr01bY5QQa2JZcWXuIUYJDmYlEd4/zUAh3pTEyqrUovz4 otKc1OJDjNIcLErivE5pFlFCAumJJanZqakFqUUwWSYOTqkGRjXT5oqotgnWMl7SL7fPTT3+ sm9e7y6RYOPSE5q7nN9H3A3tOq4aHijTFrBpUVukKuvVFE/lG+y17uE7GaXmfD++uSHk9I5f BgY/Lxxj/x///atdvHfsp+VWSh7GVX0zZ8avad8Vtj9SyzXqmo5G5tPK/bd6tnxjWlKrcDFo u12IQb34rJ4KJZbijERDLeai4kQABhTlLxADAAA=
Archived-At: 
Subject: Re: [netmod] Datastore metadata: Re: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 14:09:24 -0000

Hello Jurgen,

What would be your preference? How should we specify datastore? Could 
you please provide some description.

regards Balazs


On 2/12/2018 2:15 PM, Juergen Schoenwaelder wrote:
> On Mon, Feb 12, 2018 at 01:51:30PM +0100, Balazs Lengyel wrote:
>> Hello Jurgen,
>> OK, I will add some text about:
>>
>> datastore selection, default being running/operational for config true/false
>> data, mentioning NMDA.
>>
> Once again, this is ambiguous.
>
>> I will add a ida:datastore metadata that can placed on any any data-node (?)
> On any data node???

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


From nobody Mon Feb 12 06:26:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AAA812895E for ; Mon, 12 Feb 2018 06:26:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.03
X-Spam-Level: 
X-Spam-Status: No, score=-7.03 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O_AOkrtQ8Svf for ; Mon, 12 Feb 2018 06:26:33 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [217.31.204.67]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7446C126C2F for ; Mon, 12 Feb 2018 06:26:33 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:e4c8:9fff:fe6e:9de7]) by mail.nic.cz (Postfix) with ESMTPSA id B7F8A608F4; Mon, 12 Feb 2018 15:26:31 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1518445591; bh=5p0F8YKA8g4ArmUPBYRSMRwhuP1Hi3SgfsJkNqtIWDw=; h=From:To:Date; b=tsLUN4pES+EmmYKrelMMJYHMLhGXVZYA4wPpu8n9F1W0se7AavomQz6V6OK+VIOC7 7trocN9S61l15sxfBLarwnz5vjRRvYVAs9bjfrCedACjpFwC5GjC61a9fgpE7FoiVD txt1OHE4gPDrHYiMmyMYXiaHy7100XjCljYa0AJs=
Message-ID: <1518445591.13433.81.camel@nic.cz>
From: Ladislav Lhotka 
To: Martin Bjorklund 
Cc: netmod@ietf.org
Date: Mon, 12 Feb 2018 15:26:31 +0100
In-Reply-To: <20180212.130212.2080346646041413993.mbj@tail-f.com>
References: <87fu6axobc.fsf@nic.cz> <20180212.130212.2080346646041413993.mbj@tail-f.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 14:26:37 -0000

On Mon, 2018-02-12 at 13:02 +0100, Martin Bjorklund wrote:
> Hi,
> 
> Thank you for this review.  Comments inline.
> 
> Ladislav Lhotka  wrote:
> > Hi,
> > 
> > here is my review of the rfc7895bis document:
> > 
> > *** General comments
> >     - This revision is a significant improvement necessary for
> >       supporting NMDA. However, it is also flexible enough in that it
> >       allows for implementing the NMDA rules in an effective way but
> >       doesn't preclude the use of other datastores and datastore
> >       architectures.
> > 
> >     - Another benefit is that the new YANG library schema can be
> >       easily integrated with schema mount information.
> > 
> > *** Specific comments
> > 
> > **** Sec. 1 - backward compatibility
> > 
> >      Given that the old YANG library schema is carried over as a
> >      deprecated subtree, how can a server implementor actually cater
> >      for backward compatibility of e.g. RESTCONF clients supporting
> >      only RFC 8040?  Could the same YANG modules that comprise NMDA
> >      datastore schemas be advertized also via the old YANG library? Or
> >      is it necessary to also have pre-NMDA versions of all modules?
> > 
> >      Some more explanation might be useful here.
> 
> The text says:
> 
>   The recommended approach to populate /modules-state is to
>   report the schema for YANG modules that are configurable via
>   conventional datastores and for which config false data nodes are
>   returned via a NETCONF  operation, or equivalent.
> 
> Do you think that more guidance is needed?
> My opinion is that a server that wasnt to be backwards compatible
> probably advertise exactly what it used to advertise (in
> /modules-state), even if new NMDA-compatible models are added and
> advertised in /yang-library for new clients.
> 
> In general it is of course not possible to advertise everything that
> is availabile in /yang-library also in /modules-state - if this was
> possible we wouldn't have done YLbis.

Yes, I guess the question here is what "backward-compatible" means (given that
it is a SHOULD). One interpretation could be that it is sufficient to make sure
that, e.g., all resources required by RFC 8040 are present. So a lazy
implementor could just use an (almost) empty "modules-state" list. Does this
qualify as backward-compatible?

> 
> I don't think this document should provide recommendations on whether
> to implement pre-NMDA versions or not; this will be up to each server
> implementor to decide.

So it means that (in RESTCONF) /modules-state is bound to the legacy resource

{+restconf}/data

and /yang-library to the new datastore resources as defined in draft-ietf-
netconf-nmda-restconf, and these two are basically unrelated?

> > **** Sec. 1 - YANG library stability
> > 
> >      The text basically says that the YANG library information can
> >      change at any time. This has been recently discussed but I
> >      haven't seen any conclusion yet. I understand it is difficult to
> >      enumerate all the situations when this information can change,
> >      but it should also be emphasized that YL info is not just another
> >      subtree of state data and that it should not change haphazardly.
> 
> I agree, but I think that YANG library's job is to report what the
> server implements.  If the server dynamically changes its set of
> loaded modules, then YL should adapt.
> 
> I welcome more discussion on this topic, but I don't think it has to
> be documented in this draft.

What about this?

OLD
   The YANG library information can be different on every server and it
   can change at runtime or across a server reboot.  If a server
   implements multiple network management protocols to access the
   server's datastores, then each such protocol may have its own
   conceptual instantiation of the YANG library.

NEW
   The YANG library information represents a management API for a given server, 
   and should therefore be as stable as possible. The circumstances under which 
   this information can change are outside the scope of this document but it is 
   advisable to consider potential impact on clients.
    
> 
> >      It is like with database schemas, REST APIs and the like. Of
> >      course, these can change as well, but everybody has to understand
> >      that doing so means transition problems, broken clients etc.
> > 
> >      For this reason, it might be useful to set YL and schema mount
> >      data aside and call them metadata or schema information - even if
> >      we continue modelling them with YANG.
> 
> Do you have some concrete proposal for where to introduce this term?

In RESTCONF it could be a separate well-known resource outside all datastores.

> 
> > **** Sec. 3 - semantic versioning
> > 
> >      Some placeholders for future inclusion of semantic versions in
> >      YANG library information might be useful. To this end, I would
> >      suggest to introduce a new choice node and make "revision" (or,
> >      even better, "revision-date") its only case. This way, other
> >      versioning schemes such as semver could be easily added via
> >      augmentation.
> 
> When revision is used as a list key, we can't have a choice.

So it means that revision dates statements will have to be retained in the
modules and properly updated.

> 
> And when it is not a key, it is an optional leaf, so adding a 'semver'
> optional leaf in the future is also ok.
> 
> The proposal I have seen adds semver as an addition to revision, so
> using a choice would not be correct in this case.

OK

> 
> 
> > **** Sec. 4 - checksum
> > 
> >      I think it would be very useful (even if not immediately) to
> >      standardize the procedure for computing the checksum. What I
> >      envision are systems that construct and process YANG schemas
> >      (such as the YANG Catalog). They could benefit from having a
> >      universal hash string as a characteristic of any particular
> >      schema. Just consider how useful the universal hashes are e.g. in
> >      git.
> 
> Ok.  It would be interesting to see such a scheme.  But I agree it is
> not needed immediately for this document.

Checksums are mandatory, so every implementation has to invent some scheme.

Actually, it might be useful to have checksums also on module-sets, schemas and
datastores so that the client can easily localize the changes and retrieve again
only necessary data.

> 
> > **** Nits
> > 
> >      - sec 1. paragraph 2: s/informaton/information/
> 
> Fixed.

I just came across another:

    - sec. 1 paragraph 3: s/compatability/compatibility/

Lada

> 
> 
> /martin
> 
> 
> > 
> > Lada
> > 
> > -- 
> > Ladislav Lhotka
> > Head, CZ.NIC Labs
> > PGP Key ID: 0xB8F92B08A9F76C67
> > 
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> > 
> >
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Feb 12 06:26:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A74BB129BBF for ; Mon, 12 Feb 2018 06:26:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 1gFcovSUoPNP for ; Mon, 12 Feb 2018 06:26:43 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 85AF0126C2F for ; Mon, 12 Feb 2018 06:26:43 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 554516BA; Mon, 12 Feb 2018 15:26:42 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id FyfimFA0ryDc; Mon, 12 Feb 2018 15:26:39 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Feb 2018 15:26:42 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 328F92014B; Mon, 12 Feb 2018 15:26:42 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id W_joDhmoPxr7; Mon, 12 Feb 2018 15:26:41 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0E5D12014E; Mon, 12 Feb 2018 15:26:41 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id F1364424375B; Mon, 12 Feb 2018 15:26:40 +0100 (CET)
Date: Mon, 12 Feb 2018 15:26:40 +0100
From: Juergen Schoenwaelder 
To: Balazs Lengyel 
Cc: "netmod@ietf.org" 
Message-ID: <20180212142640.jupjqfes3hhy2cc7@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Balazs Lengyel , "netmod@ietf.org" 
References: <20180208092408.ir25jwkorxozq6gr@elstar.local> <75c8a52b-0c38-17b9-3102-2936c663fe61@ericsson.com> <20180209162526.5siyzlqgiru73nsb@elstar.local>  <20180212104720.cydwwzeo5htxvibl@elstar.local> <2af89159-7fa3-1017-3105-59675ca1f62e@ericsson.com> <20180212114058.w7tmwzimfjipoyk2@elstar.local>  <20180212131529.h6whdwwprbdruza7@elstar.local> <134cc8b0-21cb-1bc7-122c-15a79037d93e@ericsson.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <134cc8b0-21cb-1bc7-122c-15a79037d93e@ericsson.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Datastore metadata: Re: New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 14:26:49 -0000

Since you already have several attributes for the instance-data
element (ida:instance-data-set, ida:revision, ida:description,
ida:contact), adding ida:datastore may do the work (but not on a per
node basis, it needs to be restricted to be used only on the
instance-data element.

Note that some of these attributes are not well defined. I do not
understand "The annotation SHALL only be used on the top level 
element in RFC XXXX defined YANG Instance Data files." Perhaps you
want to restrict them to be only used on instance-data? (Which
namespace does this live in if any?) It is kind of unclear why you
define the attributes listed above in YANG but you do not define
instance-data itself in YANG. It seems you either define everything
about this format in YANG or nothing. But yes, this is a -00 so I
assume all of this can be improved.

/js

On Mon, Feb 12, 2018 at 03:09:08PM +0100, Balazs Lengyel wrote:
> Hello Jurgen,
> 
> What would be your preference? How should we specify datastore? Could you
> please provide some description.
> 
> regards Balazs
> 
> 
> On 2/12/2018 2:15 PM, Juergen Schoenwaelder wrote:
> > On Mon, Feb 12, 2018 at 01:51:30PM +0100, Balazs Lengyel wrote:
> > > Hello Jurgen,
> > > OK, I will add some text about:
> > > 
> > > datastore selection, default being running/operational for config true/false
> > > data, mentioning NMDA.
> > > 
> > Once again, this is ambiguous.
> > 
> > > I will add a ida:datastore metadata that can placed on any any data-node (?)
> > On any data node???
> 
> -- 
> Balazs Lengyel                       Ericsson Hungary Ltd.
> Senior Specialist
> Mobile: +36-70-330-7909              email: Balazs.Lengyel@ericsson.com
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

-- 
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 Feb 12 06:37:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7C361129516 for ; Mon, 12 Feb 2018 06:37:54 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cl0rQnaUcKXR for ; Mon, 12 Feb 2018 06:37:53 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A5B08126C2F for ; Mon, 12 Feb 2018 06:37:52 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 6FB8CB7A; Mon, 12 Feb 2018 15:37:51 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id X4zdY_me4UXo; Mon, 12 Feb 2018 15:37:48 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Feb 2018 15:37:51 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 541A02014B; Mon, 12 Feb 2018 15:37:51 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id pnImyoV48Ttj; Mon, 12 Feb 2018 15:37:50 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 626372014E; Mon, 12 Feb 2018 15:37:50 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id B7BB64243864; Mon, 12 Feb 2018 15:37:49 +0100 (CET)
Date: Mon, 12 Feb 2018 15:37:49 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Cc: Martin Bjorklund , netmod@ietf.org
Message-ID: <20180212143749.vmjwgtx2lgxxgbcw@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <87fu6axobc.fsf@nic.cz> <20180212.130212.2080346646041413993.mbj@tail-f.com> <1518445591.13433.81.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1518445591.13433.81.camel@nic.cz>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 14:37:54 -0000

On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
 
> > > **** Sec. 1 - YANG library stability
> > > 
> > >      The text basically says that the YANG library information can
> > >      change at any time. This has been recently discussed but I
> > >      haven't seen any conclusion yet. I understand it is difficult to
> > >      enumerate all the situations when this information can change,
> > >      but it should also be emphasized that YL info is not just another
> > >      subtree of state data and that it should not change haphazardly.
> > 
> > I agree, but I think that YANG library's job is to report what the
> > server implements.  If the server dynamically changes its set of
> > loaded modules, then YL should adapt.
> > 
> > I welcome more discussion on this topic, but I don't think it has to
> > be documented in this draft.
> 
> What about this?
> 
> OLD
>    The YANG library information can be different on every server and it
>    can change at runtime or across a server reboot.  If a server
>    implements multiple network management protocols to access the
>    server's datastores, then each such protocol may have its own
>    conceptual instantiation of the YANG library.
> 
> NEW
>    The YANG library information represents a management API for a given server, 
>    and should therefore be as stable as possible. The circumstances under which 
>    this information can change are outside the scope of this document but it is 
>    advisable to consider potential impact on clients.

I like the old text because it tells the client clearly that this data
can change. And the statement has been in RFC 7895 in the exact same
wording. If you want to add a statement that servers should not change
the YANG library without reason I could live with that but any attempt
to write text that makes the server somewhat guilty when a client is
not prepared to handle a YANG library change is IMHO a fundamental
change from what RFC 7895 said.

> > >      It is like with database schemas, REST APIs and the like. Of
> > >      course, these can change as well, but everybody has to understand
> > >      that doing so means transition problems, broken clients etc.
> > > 
> > >      For this reason, it might be useful to set YL and schema mount
> > >      data aside and call them metadata or schema information - even if
> > >      we continue modelling them with YANG.
> > 
> > Do you have some concrete proposal for where to introduce this term?
> 
> In RESTCONF it could be a separate well-known resource outside all datastores.

Putting the data into a different place does not change the impact of
the data changing. So I do not understand which problem introducing
yet another datastore solves.

> > > **** Sec. 4 - checksum
> > > 
> > >      I think it would be very useful (even if not immediately) to
> > >      standardize the procedure for computing the checksum. What I
> > >      envision are systems that construct and process YANG schemas
> > >      (such as the YANG Catalog). They could benefit from having a
> > >      universal hash string as a characteristic of any particular
> > >      schema. Just consider how useful the universal hashes are e.g. in
> > >      git.
> > 
> > Ok.  It would be interesting to see such a scheme.  But I agree it is
> > not needed immediately for this document.
> 
> Checksums are mandatory, so every implementation has to invent some scheme.
> 
> Actually, it might be useful to have checksums also on module-sets, schemas and
> datastores so that the client can easily localize the changes and retrieve again
> only necessary data.

With RESTCONF, you can use etags and conditional requests. NETCONF
lacks a similar generic mechanism to support caching. Instead of
adding checksum everywhere into our data models, it seems a better
solution would be to add something like etags to NETCONF. Hence, we
reduced this to a single checksum which is needed as it is carried in
the hello message.

/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 Feb 12 07:14:36 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 583AC12D775 for ; Mon, 12 Feb 2018 07:14:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HyZdrHLV0z1q for ; Mon, 12 Feb 2018 07:14:32 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A70E126CB6 for ; Mon, 12 Feb 2018 07:14:31 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:e4c8:9fff:fe6e:9de7]) by mail.nic.cz (Postfix) with ESMTPSA id 57F3E62119; Mon, 12 Feb 2018 16:14:29 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1518448469; bh=kg+e7mvsR/ZebTpH0jsONOgMlwpnsTMB45+3KkM5Eiw=; h=From:To:Date; b=HyFjoBcPgptwDtfUMqUgb0LFIb0PrvsBraRBanpAEqITVS8QCZK48ndRaOjp7/V/S xjcB/HiZK/f/VW3KfVGPAcQmFAJDaxfNMlx3CWxzwjgbJVxwGUwBCLESe7cxly5jCw t+uJCsSmJBwWTYffYhNjR/1CCEZjbbd76ZBtuN0k=
Message-ID: <1518448469.13433.104.camel@nic.cz>
From: Ladislav Lhotka 
To: Juergen Schoenwaelder 
Cc: Martin Bjorklund , netmod@ietf.org
Date: Mon, 12 Feb 2018 16:14:29 +0100
In-Reply-To: <20180212143749.vmjwgtx2lgxxgbcw@elstar.local>
References: <87fu6axobc.fsf@nic.cz> <20180212.130212.2080346646041413993.mbj@tail-f.com> <1518445591.13433.81.camel@nic.cz> <20180212143749.vmjwgtx2lgxxgbcw@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 15:14:34 -0000

On Mon, 2018-02-12 at 15:37 +0100, Juergen Schoenwaelder wrote:
> On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
>  
> > > > **** Sec. 1 - YANG library stability
> > > > 
> > > >      The text basically says that the YANG library information can
> > > >      change at any time. This has been recently discussed but I
> > > >      haven't seen any conclusion yet. I understand it is difficult to
> > > >      enumerate all the situations when this information can change,
> > > >      but it should also be emphasized that YL info is not just another
> > > >      subtree of state data and that it should not change haphazardly.
> > > 
> > > I agree, but I think that YANG library's job is to report what the
> > > server implements.  If the server dynamically changes its set of
> > > loaded modules, then YL should adapt.
> > > 
> > > I welcome more discussion on this topic, but I don't think it has to
> > > be documented in this draft.
> > 
> > What about this?
> > 
> > OLD
> >    The YANG library information can be different on every server and it
> >    can change at runtime or across a server reboot.  If a server
> >    implements multiple network management protocols to access the
> >    server's datastores, then each such protocol may have its own
> >    conceptual instantiation of the YANG library.
> > 
> > NEW
> >    The YANG library information represents a management API for a given
> > server, 
> >    and should therefore be as stable as possible. The circumstances under
> > which 
> >    this information can change are outside the scope of this document but it
> > is 
> >    advisable to consider potential impact on clients.
> 
> I like the old text because it tells the client clearly that this data
> can change. And the statement has been in RFC 7895 in the exact same

My problem with the current text is that it seems to make no difference between
YANG library and any other state data.

> wording. If you want to add a statement that servers should not change
> the YANG library without reason I could live with that but any attempt
> to write text that makes the server somewhat guilty when a client is

Not guilty but careful. There is no requirement that clients check YANG library
between every two operations, and notifications are optional.

> not prepared to handle a YANG library change is IMHO a fundamental
> change from what RFC 7895 said.
> 
> > > >      It is like with database schemas, REST APIs and the like. Of
> > > >      course, these can change as well, but everybody has to understand
> > > >      that doing so means transition problems, broken clients etc.
> > > > 
> > > >      For this reason, it might be useful to set YL and schema mount
> > > >      data aside and call them metadata or schema information - even if
> > > >      we continue modelling them with YANG.
> > > 
> > > Do you have some concrete proposal for where to introduce this term?
> > 
> > In RESTCONF it could be a separate well-known resource outside all
> > datastores.
> 
> Putting the data into a different place does not change the impact of
> the data changing. So I do not understand which problem introducing
> yet another datastore solves.

Nothing except emphasizing the difference between data and metadata, which is
IMO an important one.

> 
> > > > **** Sec. 4 - checksum
> > > > 
> > > >      I think it would be very useful (even if not immediately) to
> > > >      standardize the procedure for computing the checksum. What I
> > > >      envision are systems that construct and process YANG schemas
> > > >      (such as the YANG Catalog). They could benefit from having a
> > > >      universal hash string as a characteristic of any particular
> > > >      schema. Just consider how useful the universal hashes are e.g. in
> > > >      git.
> > > 
> > > Ok.  It would be interesting to see such a scheme.  But I agree it is
> > > not needed immediately for this document.
> > 
> > Checksums are mandatory, so every implementation has to invent some scheme.
> > 
> > Actually, it might be useful to have checksums also on module-sets, schemas
> > and
> > datastores so that the client can easily localize the changes and retrieve
> > again
> > only necessary data.
> 
> With RESTCONF, you can use etags and conditional requests. NETCONF
> lacks a similar generic mechanism to support caching. Instead of
> adding checksum everywhere into our data models, it seems a better
> solution would be to add something like etags to NETCONF. Hence, we
> reduced this to a single checksum which is needed as it is carried in
> the hello message.

Etags work, but my point here is to have the checksum as a globally unique
identifier of a given data model, schema or module set. For example, it would
allow for checking that multiple servers use the same data model.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Feb 12 07:35:38 2018
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 1176212D7E9; Mon, 12 Feb 2018 07:35:26 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, The IESG , netmod@ietf.org, joelja@gmail.com, bclaise@cisco.com, rfc-editor@rfc-editor.org, Joel Jaeggli , draft-ietf-netmod-yang-tree-diagrams@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151844972606.6018.3667307043606568331.idtracker@ietfa.amsl.com>
Date: Mon, 12 Feb 2018 07:35:26 -0800
Archived-At: 
Subject: [netmod] Protocol Action: 'YANG Tree Diagrams' to Best Current Practice (draft-ietf-netmod-yang-tree-diagrams-06.txt)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 15:35:26 -0000

The IESG has approved the following document:
- 'YANG Tree Diagrams'
  (draft-ietf-netmod-yang-tree-diagrams-06.txt) as Best Current Practice

This document is the product of the Network Modeling Working Group.

The IESG contact persons are Warren Kumari and Benoit Claise.

A URL of this Internet Draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-tree-diagrams/




Technical Summary

   This document captures the current syntax used in YANG module Tree
   Diagrams.  The purpose of the document is to provide a single
   location for this definition.  This syntax may be updated from time
   to time based on the evolution of the YANG language.

Working Group Summary

   Yang tree diagrams are perhaps unusually for yang not 
   intended specifically to be machine readable, but rather  
   to display with  maximum legibility spinlified graphical 
   representations of modules. the dicussion that led to the 
   current formulation is therefore somewhat unusual territory
   for netmod. Nevertheless, the current approach has broad
   working-group support.

Document Quality

   There are known implementations of yang tree-diagram 
   rendering which produce results consistent with this document.

Personnel

   Joel Jaeggli is the document shepherd. 
   Benoit Claise is the responsible area director.


From nobody Mon Feb 12 09:21:04 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DF43D12D866; Mon, 12 Feb 2018 09:20:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wX7hLq8zhnZp; Mon, 12 Feb 2018 09:20:54 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 51B9812D864; Mon, 12 Feb 2018 09:20:54 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1CHIwKQ009796; Mon, 12 Feb 2018 09:20:51 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=gR059zqFokpB55F4F9ym6fw4//TBwQO+aydE+i8FSEM=; b=qFBrA6of7Dle6E9LgFVGaDXb6lfL+c6bUsEiRaut0nqnS9HNDoSDFPW9qnQWkMSTOMeQ /ViUa8QF/3D9oD+QMHW5olE3n6iETegeOkYq7TbmU/voDBfWw0KklCiVXCkL0rJwCglc A3zB6tAgYod4B6A0silXLBsPgz7vfADv1c7ylK650vWAJ1MD35ikT81WNbXlVn0iu75A rjShIivJGxFZJxlXRVsLty/PDGRtv5ORDmkv5PBqaPut8h8hfoRPDAxypsBQTh+tO9tk GUBDYjC/azDYdE4kii50/C8jS1qMd3G1dDGOFXRd0eQVN26vS06M0fUlsdctuMp7ZGK0 gQ== 
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0055.outbound.protection.outlook.com [216.32.180.55]) by mx0b-00273201.pphosted.com with ESMTP id 2g3eey82pf-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Feb 2018 09:20:50 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3196.namprd05.prod.outlook.com (10.173.219.142) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Mon, 12 Feb 2018 17:20:48 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747%13]) with mapi id 15.20.0506.013; Mon, 12 Feb 2018 17:20:48 +0000
From: Kent Watsen 
To: Balazs Lengyel , "netmod@ietf.org" , "netconf@ietf.org" 
Thread-Topic: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
Thread-Index: AQHToL2thWcJ1c3u0k60yCgwjzlx8KOgtlSA
Date: Mon, 12 Feb 2018 17:20:48 +0000
Message-ID: 
References: <151802453050.4811.17681759233520578672.idtracker@ietfa.amsl.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3196; 7:9XcUmMJfEytU7xfJGtjMU0QuE495IIo4DiQvTjSUO0FWSuNFEOU8xWSCOLQ+d9FLXD4nzzzjDm9OO4okqxxofZz6+/i6/yCD4CWbikdZh9ZrPjzDEKUXIsNPA05ztQt8c+1NOwOtPj3hXlhRwKpRL+8c2m+5PVcVNnEtu4aKGj1C9/1DLRzXNTmJB5cleD7nAI5xCQJnqseOHb2uxWxkLhIxE7h+qUE4HoN7ckNFZmS6lPH5wXAOcg4R0Sj4tZGo
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b5bdf117-7b9a-4f0f-76f0-08d5723cf55b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3196; 
x-ms-traffictypediagnostic: DM5PR05MB3196:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(158342451672863)(10436049006162)(120809045254105)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(3231101)(2400082)(944501161)(10201501046)(93006095)(93001095)(3002001)(6055026)(6041288)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR05MB3196; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3196; 
x-forefront-prvs: 0581B5AB35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(39380400002)(376002)(366004)(396003)(39860400002)(189003)(199004)(377424004)(252514010)(5250100002)(110136005)(6246003)(33656002)(2501003)(2900100001)(6436002)(36756003)(966005)(7736002)(316002)(478600001)(83716003)(6486002)(58126008)(186003)(82746002)(236005)(606006)(3280700002)(83506002)(53936002)(106356001)(6512007)(54896002)(2906002)(97736004)(6306002)(99286004)(8936002)(229853002)(81166006)(66066001)(102836004)(68736007)(8676002)(105586002)(7110500001)(2950100002)(2201001)(81156014)(14454004)(3660700001)(6506007)(76176011)(9326002)(26005)(3846002)(6116002)(25786009)(5660300001)(86362001)(15650500001)(59450400001)(2420400007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3196; H:DM5PR05MB3484.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)
x-microsoft-antispam-message-info: YgbI9AxqecyBpWWdgdgWlnQ+4OloNJcbdbvAmCVNaLCk1//liqPdz/6Emd8MnaTIxYEWp3aRHE5U+cIvDXQzvA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CDAB1B4E4A4F4B84B03FEC3EC4049CAAjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b5bdf117-7b9a-4f0f-76f0-08d5723cf55b
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2018 17:20:48.2340 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3196
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-12_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802120222
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 17:20:58 -0000

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

SGkgQmFsYXpzLA0KDQpJJ20gdW5jbGVhciBhYm91dCB0aGUgc2NvcGUgb2YgdGhlIHByb2JsZW0u
ICBJcyBpdCBsaW1pdGVkIHRvIHNlcnZlciBjYXBhYmlsaXRpZXM/ICAgIEl0IHNlZW1zIHRoYXQg
dGhlIGlkZWEgaXMgdG8gbW92ZSBmcm9tIGhhdmluZyBhIHN0YXRlZnVsIGNvbm5lY3Rpb24gdG8g
YSBsaXZlIHNlcnZlciB0byBoYXZpbmcgYSB3YXkgdG8gcGFzcyB0aGUgZXF1aXZhbGVudCBzdGF0
ZSBldmVuIHdoZW4gbm90IGNvbm5lY3RlZCB0byB0aGUgc2VydmVyLg0KDQpSZWxhdGVkLCBidXQg
cHJvYmFibHkgbm90IHdoYXQgeW91J3JlIGFuZ2xpbmcgZm9yLCBJJ3ZlIGJlZW4gaGF2aW5nIGlz
c3VlcyB3aXRoIHZhbGlkYXRpbmcgUkVTVENPTkYgZXhhbXBsZXMuICBUaGUgaXNzdWUgaXMgdGhh
dCB0aGUgUkVTVENPTkYgZG9jdW1lbnRzIGFyZSBjb250ZXh0IHNwZWNpZmljLiAgRm9yIGluc3Rh
bmNlLCBHRVQgL3dpZGdldHMvIHJldHVybnMgYSBkb2N1bWVudCB0aGF0IG1pZ2h0IGhhdmUgYW4g
b3V0ZXJtb3N0IGVsZW1lbnQgY2FsbGVkICJ3aWRnZXRzIiwgd2hlcmVhcyBHRVQgL3dpZGdldHMv
d2lkZ2V0PWZvbyByZXR1cm5zIGEgZG9jdW1lbnQgdGhhdCBtaWdodCBoYXZlIGFuIG91dGVybW9z
dCBlbGVtZW50IGNhbGxlZCAid2lkZ2V0Ii4gICBJbiBvcmRlciB0byB2YWxpZGF0ZSB0aGUgc2Vj
b25kIGRvY3VtZW50LCBteSBjb2RlIGZpcnN0IHdyYXBzIHRoZSAid2lkZ2V0IiBlbGVtZW50IHdp
dGggYSAid2lkZ2V0cyIgZWxlbWVudCwgYW5kIHRoZW4gdGhlIHZhbGlkYXRpb24gdG9vbHMgd29y
ay4NCg0KUGVyaGFwcyBhIG1vcmUgZ2VuZXJhbGl6ZWQgaW5zdGFuY2UgZGF0YSBtZWNoYW5pc20g
Y291bGQgaW5jbHVkZSB3aGVyZSBpbiB0aGUgdHJlZSB0aGUgZGF0YSBpcyBzaXR1YXRlZD8gICBG
b3IgZXhhbXBsZSwgaXQgd291bGQgYmUgaGVscGZ1bCBpZiBhbiBhY3Rpb24ncyBpbnN0YW5jZSBk
YXRhIGNvdWxkIHByb3ZpZGUgbW9yZSBjb250ZXh0IChlLmcuLCB0aGUgaW5wdXQvb3V0cHV0IGRv
Y3VtZW50cyBjb3VsZCBpbmRpY2F0ZSB0aGUgbmFtZSBvZiB0aGUgYWN0aW9uLCB0aGUgb2JqZWN0
IHRoYXQgdGhlIGFjdGlvbiB3YXMgaW52b2tlZCBvbiwgZXRjLikuDQoNCkdlbmVyYWxseSwgdGhl
cmUgaXMgc29tZSBzdGF0ZSBiZWluZyBoZWxkIGJ5IHRoZSBwcm90b2NvbHMgdGhhdCBjb21wbGlj
YXRlcyBleGFtaW5pbmcgaW5zdGFuY2UgZGF0YSBvdXRzaWRlIG9mIHRoZSBwcm90b2NvbCwgYXMg
ZXh0cmEgYml0cyBvZiBzdGF0ZSBuZWVkIHRvIGJlIHBhc3NlZCBhcm91bmQgc2VwYXJhdGVseS4g
IEl0IHdvdWxkIGJlIG5pY2UgaWYgdGhlIGRvY3VtZW50cyB3ZXJlIChvciBhdCBsZWFzdCBjb3Vs
ZCBiZSkgbW9yZSBzZWxmLWNvbnRhaW5lZC4NCg0KS2VudCAvLyBjb250cmlidXRvcg0KDQoNCk9u
IDIvOC8xOCwgNDoxNyBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgQmFsYXpzIExlbmd5ZWwiIDxu
ZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9u
IGJlaGFsZiBvZiBiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb208bWFpbHRvOmJhbGF6cy5sZW5n
eWVsQGVyaWNzc29uLmNvbT4+IHdyb3RlOg0KDQoNCkhlbGxvLA0KDQpXaXRoIEJlbm9pdCBJIHBy
ZXBhcmVkIGEgZHJhZnQgYWJvdXQgaG93IHRvIGRvY3VtZW50IGFuZCB1c2UgWUFORyBkZWZpbmVk
IGluc3RhbmNlIGRhdGEuIEl0IGNvdWxkIGJlIHVzZWZ1bCBmb3IgZG9jdW1lbnRpbmcgIHNlcnZl
ciBjYXBhYmlsaXRpZXMgb3IgcHJlbG9hZGluZyBkYXRhIGRlZmluZWQgaW4gaW1wbGVtZW50YXRp
b24gdGltZSBhbmQgcHJvYmFibHkgZm9yIG90aGVyIHB1cnBvc2VzIGFzIHdlbGwuDQoNCnJlZ2Fy
ZHMgQmFsYXpzDQoNCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tDQpTdWJqZWN0
Og0KDQpOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24gZm9yIGRyYWZ0LWxlbmd5ZWwtbmV0bW9kLXlh
bmctaW5zdGFuY2UtZGF0YS0wMC50eHQNCg0KRGF0ZToNCg0KV2VkLCA3IEZlYiAyMDE4IDA5OjI4
OjUwIC0wODAwDQoNCkZyb206DQoNCmludGVybmV0LWRyYWZ0c0BpZXRmLm9yZzxtYWlsdG86aW50
ZXJuZXQtZHJhZnRzQGlldGYub3JnPg0KDQpUbzoNCg0KQmVub2l0IENsYWlzZSA8YmNsYWlzZUBj
aXNjby5jb20+PG1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbT4sIEJhbGF6cyBMZW5neWVsIDxiYWxh
enMubGVuZ3llbEBlcmljc3Nvbi5jb20+PG1haWx0bzpiYWxhenMubGVuZ3llbEBlcmljc3Nvbi5j
b20+DQoNCg0KDQpBIG5ldyB2ZXJzaW9uIG9mIEktRCwgZHJhZnQtbGVuZ3llbC1uZXRtb2QteWFu
Zy1pbnN0YW5jZS1kYXRhLTAwLnR4dA0KDQpoYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVk
IGJ5IEJhbGF6cyBMZW5neWVsIGFuZCBwb3N0ZWQgdG8gdGhlDQoNCklFVEYgcmVwb3NpdG9yeS4N
Cg0KDQoNCk5hbWU6ICAgICAgICAgIGRyYWZ0LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2Ut
ZGF0YQ0KDQpSZXZpc2lvbjogICAgICAwMA0KDQpUaXRsZTogICAgICAgICBZQU5HIEluc3RhbmNl
IERhdGEgRmlsZXMgYW5kIHRoZWlyIHVzZSBmb3IgRG9jdW1lbnRpbmcgU2VydmVyIENhcGFiaWxp
dGllcw0KDQpEb2N1bWVudCBkYXRlOiAyMDE4LTAyLTA2DQoNCkdyb3VwOiAgICAgICAgIEluZGl2
aWR1YWwgU3VibWlzc2lvbg0KDQpQYWdlczogICAgICAgICAxMA0KDQpVUkw6ICAgICAgICAgICAg
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxlbmd5ZWwtbmV0bW9k
LXlhbmctaW5zdGFuY2UtZGF0YS0wMC50eHQ8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQu
Y29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaW50ZXJuZXQtMkRkcmFmdHNfZHJh
ZnQtMkRsZW5neWVsLTJEbmV0bW9kLTJEeWFuZy0yRGluc3RhbmNlLTJEZGF0YS0yRDAwLnR4dCZk
PUR3TURhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05
emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09aG5VOS1MTHBhSXpX
b3daZWZCeFlmcmN2YUVJTEQ4QnoybjZnU1RISTVXUSZzPS1jeDNTZ1l4Zm1JbFJXWXozUkxiODFC
RENvSlp5MlZpcUlBSThDcTBkbGsmZT0+DQoNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1sZW5neWVsLW5ldG1vZC15YW5nLWluc3RhbmNlLWRh
dGEvPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
ZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2RyYWZ0LTJEbGVuZ3llbC0yRG5ldG1vZC0yRHlhbmct
MkRpbnN0YW5jZS0yRGRhdGFfJmQ9RHdNRGFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L
LW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xh
SmRjWm8mbT1oblU5LUxMcGFJeldvd1plZkJ4WWZyY3ZhRUlMRDhCejJuNmdTVEhJNVdRJnM9dmVD
SktmWVpzOFY5a3JaT0labE1SMUhTNmptbU8wbms1RkNYd1llbmdTUSZlPT4NCg0KSHRtbGl6ZWQ6
ICAgICAgIGh0dHBzOi8vdG9vbHMuaWV0Zi5vcmcvaHRtbC9kcmFmdC1sZW5neWVsLW5ldG1vZC15
YW5nLWluc3RhbmNlLWRhdGEtMDA8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3Yy
L3VybD91PWh0dHBzLTNBX190b29scy5pZXRmLm9yZ19odG1sX2RyYWZ0LTJEbGVuZ3llbC0yRG5l
dG1vZC0yRHlhbmctMkRpbnN0YW5jZS0yRGRhdGEtMkQwMCZkPUR3TURhUSZjPUhBa1l1aDYzcnN1
aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1lo
cW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09aG5VOS1MTHBhSXpXb3daZWZCeFlmcmN2YUVJTEQ4Qnoy
bjZnU1RISTVXUSZzPVJvMEx6cjMtQ01MajAza2pxMldWY1pDVWJCQlVxcldQbHMxWkVTMEdiblkm
ZT0+DQoNCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9o
dG1sL2RyYWZ0LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2UtZGF0YS0wMDxodHRwczovL3Vy
bGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmll
dGYub3JnX2RvY19odG1sX2RyYWZ0LTJEbGVuZ3llbC0yRG5ldG1vZC0yRHlhbmctMkRpbnN0YW5j
ZS0yRGRhdGEtMkQwMCZkPUR3TURhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIz
dm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pv
Jm09aG5VOS1MTHBhSXpXb3daZWZCeFlmcmN2YUVJTEQ4QnoybjZnU1RISTVXUSZzPVBUUVRfTzFZ
cDlXR1lhMmFvZGtPZlZlNWwwREZQa0tmZW9kajR5NXB0SDAmZT0+DQoNCg0KDQoNCg0KQWJzdHJh
Y3Q6DQoNCiAgIFRoaXMgZG9jdW1lbnQgc3BlY2lmaWVzIGEgc3RhbmRhcmQgZmlsZSBmb3JtYXQg
Zm9yIFlBTkcgaW5zdGFuY2UNCg0KICAgZGF0YSwgdGhhdCBpcyBkYXRhIHRoYXQgY291bGQgYmUg
c3RvcmVkIGluIGEgZGF0YXN0b3JlIGFuZCB3aG9zZQ0KDQogICBzeW50YXggYW5kIHNlbWFudGlj
cyBpcyBkZWZpbmVkIGJ5IFlBTkcgbW9kZWxzLiAgSW5zdGFuY2UgZGF0YSBmaWxlcw0KDQogICBj
YW4gYmUgdXNlZCB0byBwcm92aWRlIGluZm9ybWF0aW9uIHRoYXQgaXMgZGVmaW5lZCBpbiBkZXNp
Z24gdGltZS4NCg0KICAgVGhlcmUgaXMgYSBuZWVkIHRvIGRvY3VtZW50IFNlcnZlciBjYXBhYmls
aXRpZXMgKHdoaWNoIGFyZSBvZnRlbg0KDQogICBzcGVjaWZpZWQgaW4gZGVzaWduIHRpbWUpLCB3
aGljaCBzaG91bGQgYmUgZG9uZSB1c2luZyBpbnN0YW5jZSBkYXRhDQoNCiAgIGZpbGVzLg0KDQoN
Cg0KDQoNCg0KDQoNCg0KUGxlYXNlIG5vdGUgdGhhdCBpdCBtYXkgdGFrZSBhIGNvdXBsZSBvZiBt
aW51dGVzIGZyb20gdGhlIHRpbWUgb2Ygc3VibWlzc2lvbg0KDQp1bnRpbCB0aGUgaHRtbGl6ZWQg
dmVyc2lvbiBhbmQgZGlmZiBhcmUgYXZhaWxhYmxlIGF0IHRvb2xzLmlldGYub3JnLg0KDQoNCg0K
VGhlIElFVEYgU2VjcmV0YXJpYXQNCg0KDQoNCi0tDQoNCkJhbGF6cyBMZW5neWVsICAgICAgICAg
ICAgICAgICAgICAgICBFcmljc3NvbiBIdW5nYXJ5IEx0ZC4NCg0KU2VuaW9yIFNwZWNpYWxpc3QN
Cg0KTW9iaWxlOiArMzYtNzAtMzMwLTc5MDkgICAgICAgICAgICAgIGVtYWlsOiBCYWxhenMuTGVu
Z3llbEBlcmljc3Nvbi5jb208bWFpbHRvOkJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbT4NCg==

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls
ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb3Vy
aWVyO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5
Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50
Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29y
YXRpb246bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNvSW5z
DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRl
eHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0K
CXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdl
IFdvcmRTZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4g
MS4waW4gMS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQot
LT48L3N0eWxlPg0KPC9oZWFkPg0KPGJvZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBs
aW5rPSJibHVlIiB2bGluaz0icHVycGxlIj4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+SGkg
QmFsYXpzLDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+
SSdtIHVuY2xlYXIgYWJvdXQgdGhlIHNjb3BlIG9mIHRoZSBwcm9ibGVtLiZuYnNwOyBJcyBpdCBs
aW1pdGVkIHRvIHNlcnZlciBjYXBhYmlsaXRpZXM/Jm5ic3A7Jm5ic3A7ICZuYnNwO0l0IHNlZW1z
IHRoYXQgdGhlIGlkZWEgaXMgdG8gbW92ZSBmcm9tIGhhdmluZyBhIHN0YXRlZnVsIGNvbm5lY3Rp
b24gdG8gYSBsaXZlIHNlcnZlciB0byBoYXZpbmcgYSB3YXkgdG8gcGFzcyB0aGUgZXF1aXZhbGVu
dA0KIHN0YXRlIGV2ZW4gd2hlbiBub3QgY29ubmVjdGVkIHRvIHRoZSBzZXJ2ZXIuPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5SZWxhdGVkLCBidXQgcHJv
YmFibHkgbm90IHdoYXQgeW91J3JlIGFuZ2xpbmcgZm9yLCBJJ3ZlIGJlZW4gaGF2aW5nIGlzc3Vl
cyB3aXRoIHZhbGlkYXRpbmcgUkVTVENPTkYgZXhhbXBsZXMuJm5ic3A7IFRoZSBpc3N1ZSBpcyB0
aGF0IHRoZSBSRVNUQ09ORiBkb2N1bWVudHMgYXJlIGNvbnRleHQgc3BlY2lmaWMuJm5ic3A7IEZv
ciBpbnN0YW5jZSwgR0VUIC93aWRnZXRzLw0KIHJldHVybnMgYSBkb2N1bWVudCB0aGF0IG1pZ2h0
IGhhdmUgYW4gb3V0ZXJtb3N0IGVsZW1lbnQgY2FsbGVkICZxdW90O3dpZGdldHMmcXVvdDssIHdo
ZXJlYXMgR0VUIC93aWRnZXRzL3dpZGdldD1mb28gcmV0dXJucyBhIGRvY3VtZW50IHRoYXQgbWln
aHQgaGF2ZSBhbiBvdXRlcm1vc3QgZWxlbWVudCBjYWxsZWQgJnF1b3Q7d2lkZ2V0JnF1b3Q7LiZu
YnNwOyZuYnNwOyBJbiBvcmRlciB0byB2YWxpZGF0ZSB0aGUgc2Vjb25kIGRvY3VtZW50LCBteSBj
b2RlIGZpcnN0IHdyYXBzIHRoZSAmcXVvdDt3aWRnZXQmcXVvdDsNCiBlbGVtZW50IHdpdGggYSAm
cXVvdDt3aWRnZXRzJnF1b3Q7IGVsZW1lbnQsIGFuZCB0aGVuIHRoZSB2YWxpZGF0aW9uIHRvb2xz
IHdvcmsuJm5ic3A7Jm5ic3A7IDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6Q2FsaWJyaSI+UGVyaGFwcyBhIG1vcmUgZ2VuZXJhbGl6ZWQgaW5zdGFuY2UgZGF0YSBtZWNo
YW5pc20gY291bGQgaW5jbHVkZSB3aGVyZSBpbiB0aGUgdHJlZSB0aGUgZGF0YSBpcyBzaXR1YXRl
ZD8mbmJzcDsmbmJzcDsgRm9yIGV4YW1wbGUsIGl0IHdvdWxkIGJlIGhlbHBmdWwgaWYgYW4gYWN0
aW9uJ3MgaW5zdGFuY2UgZGF0YSBjb3VsZCBwcm92aWRlIG1vcmUgY29udGV4dCAoZS5nLiwNCiB0
aGUgaW5wdXQvb3V0cHV0IGRvY3VtZW50cyBjb3VsZCBpbmRpY2F0ZSB0aGUgbmFtZSBvZiB0aGUg
YWN0aW9uLCB0aGUgb2JqZWN0IHRoYXQgdGhlIGFjdGlvbiB3YXMgaW52b2tlZCBvbiwgZXRjLiku
Jm5ic3A7Jm5ic3A7DQo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh
bGlicmkiPkdlbmVyYWxseSwgdGhlcmUgaXMgc29tZSBzdGF0ZSBiZWluZyBoZWxkIGJ5IHRoZSBw
cm90b2NvbHMgdGhhdCBjb21wbGljYXRlcyBleGFtaW5pbmcgaW5zdGFuY2UgZGF0YSBvdXRzaWRl
IG9mIHRoZSBwcm90b2NvbCwgYXMgZXh0cmEgYml0cyBvZiBzdGF0ZSBuZWVkIHRvIGJlIHBhc3Nl
ZCBhcm91bmQgc2VwYXJhdGVseS4mbmJzcDsgSXQgd291bGQgYmUgbmljZQ0KIGlmIHRoZSBkb2N1
bWVudHMgd2VyZSAob3IgYXQgbGVhc3QgY291bGQgYmUpIG1vcmUgc2VsZi1jb250YWluZWQuPG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5LZW50IC8vIGNv
bnRyaWJ1dG9yPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk9uIDIvOC8xOCwgNDoxNyBBTSwgJnF1b3Q7bmV0bW9kIG9uIGJlaGFsZiBvZiBC
YWxhenMgTGVuZ3llbCZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGll
dGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVm
PSJtYWlsdG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29tIj5iYWxhenMubGVuZ3llbEBlcmlj
c3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxwPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPHA+V2l0aCBCZW5vaXQgSSBwcmVwYXJlZCBhIGRy
YWZ0IGFib3V0IGhvdyB0byBkb2N1bWVudCBhbmQgdXNlIFlBTkcgZGVmaW5lZCBpbnN0YW5jZSBk
YXRhLiBJdCBjb3VsZCBiZSB1c2VmdWwgZm9yIGRvY3VtZW50aW5nJm5ic3A7IHNlcnZlciBjYXBh
YmlsaXRpZXMgb3IgcHJlbG9hZGluZyBkYXRhIGRlZmluZWQgaW4gaW1wbGVtZW50YXRpb24gdGlt
ZSBhbmQgcHJvYmFibHkgZm9yIG90aGVyIHB1cnBvc2VzIGFzIHdlbGwuPG86cD48L286cD48L3A+
DQo8cD5yZWdhcmRzIEJhbGF6czxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxicj4NCi0tLS0tLS0tIEZvcndhcmRlZCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9v
OnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3JtYWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3Bh
Y2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRib2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2
YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9InRleHQtYWxpZ246cmlnaHQiPjxiPlN1Ympl
Y3Q6IDxvOnA+PC9vOnA+PC9iPjwvcD4NCjwvdGQ+DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBp
biAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlv
biBmb3IgZHJhZnQtbGVuZ3llbC1uZXRtb2QteWFuZy1pbnN0YW5jZS1kYXRhLTAwLnR4dDxvOnA+
PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9w
IiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIg
YWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGlnbjpyaWdodCI+PGI+RGF0ZTogPG86cD48L286
cD48L2I+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+V2VkLCA3IEZlYiAyMDE4IDA5OjI4OjUwIC0wODAwPG86cD48
L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3Ai
IHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBh
bGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5Gcm9tOiA8bzpwPjwvbzpw
PjwvYj48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJtYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYu
b3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0K
PC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBp
biAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxl
PSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5UbzogPG86cD48L286cD48L2I+PC9wPg0KPC90ZD4NCjx0
ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
QmVub2l0IENsYWlzZSA8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iPiZsdDtiY2xh
aXNlQGNpc2NvLmNvbSZndDs8L2E+LCBCYWxhenMgTGVuZ3llbA0KPGEgaHJlZj0ibWFpbHRvOmJh
bGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSI+Jmx0O2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNv
bSZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxl
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjxwcmU+QSBuZXcgdmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxlbmd5
ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2UtZGF0YS0wMC50eHQ8bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0dGVkIGJ5IEJhbGF6cyBMZW5neWVsIGFuZCBw
b3N0ZWQgdG8gdGhlPG86cD48L286cD48L3ByZT4NCjxwcmU+SUVURiByZXBvc2l0b3J5LjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPk5hbWU6Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0
LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2UtZGF0YTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJl
PlJldmlzaW9uOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAwMDxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPlRpdGxlOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBZQU5HIEluc3RhbmNlIERhdGEgRmlsZXMgYW5kIHRoZWlyIHVzZSBmb3IgRG9jdW1l
bnRpbmcgU2VydmVyIENhcGFiaWxpdGllczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkRvY3VtZW50
IGRhdGU6IDIwMTgtMDItMDY8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Hcm91cDombmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNz
aW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+UGFnZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEwPG86cD48L286cD48L3ByZT4NCjxwcmU+VVJMOiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs
P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19pbnRlcm5ldC0yRGRyYWZ0c19kcmFmdC0yRGxlbmd5
ZWwtMkRuZXRtb2QtMkR5YW5nLTJEaW5zdGFuY2UtMkRkYXRhLTJEMDAudHh0JmFtcDtkPUR3TURh
USZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDty
PTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209aG5VOS1M
THBhSXpXb3daZWZCeFlmcmN2YUVJTEQ4QnoybjZnU1RISTVXUSZhbXA7cz0tY3gzU2dZeGZtSWxS
V1l6M1JMYjgxQkRDb0paeTJWaXFJQUk4Q3EwZGxrJmFtcDtlPSI+aHR0cHM6Ly93d3cuaWV0Zi5v
cmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2UtZGF0
YS0wMC50eHQ8L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+U3RhdHVzOiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRl
ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYu
b3JnX2RvY19kcmFmdC0yRGxlbmd5ZWwtMkRuZXRtb2QtMkR5YW5nLTJEaW5zdGFuY2UtMkRkYXRh
XyZhbXA7ZD1Ed01EYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RU
WGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pv
JmFtcDttPWhuVTktTExwYUl6V293WmVmQnhZZnJjdmFFSUxEOEJ6Mm42Z1NUSEk1V1EmYW1wO3M9
dmVDSktmWVpzOFY5a3JaT0labE1SMUhTNmptbU8wbms1RkNYd1llbmdTUSZhbXA7ZT0iPmh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5z
dGFuY2UtZGF0YS88L2E+PG86cD48L286cD48L3ByZT4NCjxwcmU+SHRtbGl6ZWQ6Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5w
cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFm
dC0yRGxlbmd5ZWwtMkRuZXRtb2QtMkR5YW5nLTJEaW5zdGFuY2UtMkRkYXRhLTJEMDAmYW1wO2Q9
RHdNRGFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0km
YW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1o
blU5LUxMcGFJeldvd1plZkJ4WWZyY3ZhRUlMRDhCejJuNmdTVEhJNVdRJmFtcDtzPVJvMEx6cjMt
Q01MajAza2pxMldWY1pDVWJCQlVxcldQbHMxWkVTMEdiblkmYW1wO2U9Ij5odHRwczovL3Rvb2xz
LmlldGYub3JnL2h0bWwvZHJhZnQtbGVuZ3llbC1uZXRtb2QteWFuZy1pbnN0YW5jZS1kYXRhLTAw
PC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkh0bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5j
b20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19odG1sX2RyYWZ0
LTJEbGVuZ3llbC0yRG5ldG1vZC0yRHlhbmctMkRpbnN0YW5jZS0yRGRhdGEtMkQwMCZhbXA7ZD1E
d01EYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZh
bXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPWhu
VTktTExwYUl6V293WmVmQnhZZnJjdmFFSUxEOEJ6Mm42Z1NUSEk1V1EmYW1wO3M9UFRRVF9PMVlw
OVdHWWEyYW9ka09mVmU1bDBERlBrS2Zlb2RqNHk1cHRIMCZhbXA7ZT0iPmh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGVuZ3llbC1uZXRtb2QteWFuZy1pbnN0YW5j
ZS1kYXRhLTAwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPkFic3RyYWN0OjxvOnA+PC9v
OnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBUaGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHN0
YW5kYXJkIGZpbGUgZm9ybWF0IGZvciBZQU5HIGluc3RhbmNlPG86cD48L286cD48L3ByZT4NCjxw
cmU+Jm5ic3A7Jm5ic3A7IGRhdGEsIHRoYXQgaXMgZGF0YSB0aGF0IGNvdWxkIGJlIHN0b3JlZCBp
biBhIGRhdGFzdG9yZSBhbmQgd2hvc2U8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJz
cDsgc3ludGF4IGFuZCBzZW1hbnRpY3MgaXMgZGVmaW5lZCBieSBZQU5HIG1vZGVscy4mbmJzcDsg
SW5zdGFuY2UgZGF0YSBmaWxlczxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBj
YW4gYmUgdXNlZCB0byBwcm92aWRlIGluZm9ybWF0aW9uIHRoYXQgaXMgZGVmaW5lZCBpbiBkZXNp
Z24gdGltZS48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgVGhlcmUgaXMgYSBu
ZWVkIHRvIGRvY3VtZW50IFNlcnZlciBjYXBhYmlsaXRpZXMgKHdoaWNoIGFyZSBvZnRlbjxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBzcGVjaWZpZWQgaW4gZGVzaWduIHRpbWUp
LCB3aGljaCBzaG91bGQgYmUgZG9uZSB1c2luZyBpbnN0YW5jZSBkYXRhPG86cD48L286cD48L3By
ZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGZpbGVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT48bzpw
PiZuYnNwOzwvbzpwPjwvcHJlPg0KPHByZT5QbGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEg
Y291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGltZSBvZiBzdWJtaXNzaW9uPG86cD48L286cD48
L3ByZT4NCjxwcmU+dW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWls
YWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpwPjwvbzpwPjwvcHJlPg0KPHByZT48bzpwPiZuYnNw
OzwvbzpwPjwvcHJlPg0KPHByZT5UaGUgSUVURiBTZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9wcmU+DQo8L2Rpdj4NCjxwcmU+LS0gPG86cD48L286
cD48L3ByZT4NCjxwcmU+QmFsYXpzIExlbmd5ZWwmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgRXJpY3Nzb24g
SHVuZ2FyeSBMdGQuPG86cD48L286cD48L3ByZT4NCjxwcmU+U2VuaW9yIFNwZWNpYWxpc3Q8bzpw
PjwvbzpwPjwvcHJlPg0KPHByZT5Nb2JpbGU6ICYjNDM7MzYtNzAtMzMwLTc5MDkmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsgZW1haWw6IDxhIGhyZWY9Im1haWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nv
bi5jb20iPkJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNvbTwvYT4gPG86cD48L286cD48L3ByZT4N
CjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_CDAB1B4E4A4F4B84B03FEC3EC4049CAAjunipernet_--


From nobody Mon Feb 12 09:23:03 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9976A12D86B for ; Mon, 12 Feb 2018 09:23:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.711
X-Spam-Level: 
X-Spam-Status: No, score=-0.711 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, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6W6HuofRD5UW for ; Mon, 12 Feb 2018 09:22:58 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 D618712D864 for ; Mon, 12 Feb 2018 09:22:58 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1CHJ4be027228; Mon, 12 Feb 2018 09:22:56 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : content-type : mime-version; s=PPS1017; bh=5e7tZQgkN5RCGeexhjswxHLUTDTztBw8ymXmvEYx1tc=; b=ir6h99Sp6JtU/53EgRTUVbAz8d+2OKXqu/Ppw5FopjBzZ/ki8SqVT5SaJQU6ePTXEVHM wbDvDJsZIymQ0T9nSMS/yRHfAlhYNiuOyLBlNbv/8qGDVqODHWAtq1ZuVIhRpLpBTf06 uPt5xfK6g8CL9QqUKDdhGPVqM1jVVfu+MneBo4wECP3izKF/33CVtupBAPOidVdIH4Ip 8GuSZBOoSFKWNPcQBPcZTqz4LGVx9/AwkdH56Pmc6I/lYxpiZlstPa5IqLXKtDflqM09 tJNcqAC61AG09912ll6hUfVEuNVH6Wi0SEgEMnuWHogU2mab9HT5aFnq766Z6tMvu84c rA== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0085.outbound.protection.outlook.com [207.46.163.85]) by mx0a-00273201.pphosted.com with ESMTP id 2g39150p1b-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Mon, 12 Feb 2018 09:22:56 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3676.namprd05.prod.outlook.com (10.174.190.161) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Mon, 12 Feb 2018 17:22:53 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747%13]) with mapi id 15.20.0506.013; Mon, 12 Feb 2018 17:22:53 +0000
From: Kent Watsen 
To: Balazs Lengyel , "netmod@ietf.org" 
Thread-Topic: [Netconf] [netmod] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
Thread-Index: AQHTpCYdVWSDEED4Lk27V9UCuItRvg==
Date: Mon, 12 Feb 2018 17:22:53 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3676; 7:z355rEHfMEL/LmQpmCjWlYEjhckWiJMJKjHFs2u/9F32aDkhZbnEY5FcuP7EbmDtqMnIqdVPu4DIlSCpDH1543Q1C6U+Rv+V75iu+wMZiaUogFnzafZ681CIYMqhZOhfT0AE0u2fRBRGDrE0zT85PD9soiqk9gniIWhDx9LTtbaKI38SR2F/uEn2u21zMaHm5OcX9EWaIdPQuPl/m6OZBJLHOd2oC+1G7K3DeHd2wnVi1c0r5FBqP3wDbhxdyFV1
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 1d2d5b31-f644-4ee4-c2c6-08d5723d4030
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3676; 
x-ms-traffictypediagnostic: DM5PR05MB3676:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(37575265505322)(28532068793085)(158342451672863)(10436049006162)(120809045254105)(138986009662008)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231101)(944501161)(3002001)(93006095)(93001095)(6055026)(6041288)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123558120)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR05MB3676; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3676; 
x-forefront-prvs: 0581B5AB35
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(396003)(39380400002)(366004)(39860400002)(376002)(189003)(199004)(377424004)(252514010)(106356001)(6486002)(54896002)(6512007)(6436002)(82746002)(966005)(14454004)(53936002)(33656002)(236005)(6306002)(478600001)(6246003)(7736002)(86362001)(229853002)(8936002)(6116002)(3846002)(81166006)(2906002)(81156014)(3280700002)(105586002)(8676002)(36756003)(2501003)(59450400001)(53546011)(83716003)(99286004)(97736004)(83506002)(5250100002)(102836004)(6346003)(25786009)(316002)(68736007)(6506007)(58126008)(186003)(5660300001)(26005)(66066001)(15650500001)(606006)(3660700001)(110136005)(2420400007)(2900100001)(7110500001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3676; H:DM5PR05MB3484.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)
x-microsoft-antispam-message-info: M0qk6A2qSxbl4D/F78j5q3B6ySFSWl/2HcgbOrSa7s9D1DftxMckw+pkG3x7U+EsMFPeZyMobS0PPu4uctHHjA==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_A2DF7961BF614F36A0C1032A4BC5EAFCjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 1d2d5b31-f644-4ee4-c2c6-08d5723d4030
X-MS-Exchange-CrossTenant-originalarrivaltime: 12 Feb 2018 17:22:53.7989 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3676
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-12_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802120222
Archived-At: 
Subject: Re: [netmod] [Netconf] New Version Notification for draft-lengyel-netmod-yang-instance-data-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 17:23:01 -0000

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

W3JlbW92aW5nIG5ldGNvbmZdDQoNCg0KT24gMi8xMi8xOCwgMTI6MjAgUE0sICJOZXRjb25mIG9u
IGJlaGFsZiBvZiBLZW50IFdhdHNlbiIgPG5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86
bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5pcGVyLm5l
dDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KDQpIaSBCYWxhenMsDQoNCkkn
bSB1bmNsZWFyIGFib3V0IHRoZSBzY29wZSBvZiB0aGUgcHJvYmxlbS4gIElzIGl0IGxpbWl0ZWQg
dG8gc2VydmVyIGNhcGFiaWxpdGllcz8gICAgSXQgc2VlbXMgdGhhdCB0aGUgaWRlYSBpcyB0byBt
b3ZlIGZyb20gaGF2aW5nIGEgc3RhdGVmdWwgY29ubmVjdGlvbiB0byBhIGxpdmUgc2VydmVyIHRv
IGhhdmluZyBhIHdheSB0byBwYXNzIHRoZSBlcXVpdmFsZW50IHN0YXRlIGV2ZW4gd2hlbiBub3Qg
Y29ubmVjdGVkIHRvIHRoZSBzZXJ2ZXIuDQoNClJlbGF0ZWQsIGJ1dCBwcm9iYWJseSBub3Qgd2hh
dCB5b3UncmUgYW5nbGluZyBmb3IsIEkndmUgYmVlbiBoYXZpbmcgaXNzdWVzIHdpdGggdmFsaWRh
dGluZyBSRVNUQ09ORiBleGFtcGxlcy4gIFRoZSBpc3N1ZSBpcyB0aGF0IHRoZSBSRVNUQ09ORiBk
b2N1bWVudHMgYXJlIGNvbnRleHQgc3BlY2lmaWMuICBGb3IgaW5zdGFuY2UsIEdFVCAvd2lkZ2V0
cy8gcmV0dXJucyBhIGRvY3VtZW50IHRoYXQgbWlnaHQgaGF2ZSBhbiBvdXRlcm1vc3QgZWxlbWVu
dCBjYWxsZWQgIndpZGdldHMiLCB3aGVyZWFzIEdFVCAvd2lkZ2V0cy93aWRnZXQ9Zm9vIHJldHVy
bnMgYSBkb2N1bWVudCB0aGF0IG1pZ2h0IGhhdmUgYW4gb3V0ZXJtb3N0IGVsZW1lbnQgY2FsbGVk
ICJ3aWRnZXQiLiAgIEluIG9yZGVyIHRvIHZhbGlkYXRlIHRoZSBzZWNvbmQgZG9jdW1lbnQsIG15
IGNvZGUgZmlyc3Qgd3JhcHMgdGhlICJ3aWRnZXQiIGVsZW1lbnQgd2l0aCBhICJ3aWRnZXRzIiBl
bGVtZW50LCBhbmQgdGhlbiB0aGUgdmFsaWRhdGlvbiB0b29scyB3b3JrLg0KDQpQZXJoYXBzIGEg
bW9yZSBnZW5lcmFsaXplZCBpbnN0YW5jZSBkYXRhIG1lY2hhbmlzbSBjb3VsZCBpbmNsdWRlIHdo
ZXJlIGluIHRoZSB0cmVlIHRoZSBkYXRhIGlzIHNpdHVhdGVkPyAgIEZvciBleGFtcGxlLCBpdCB3
b3VsZCBiZSBoZWxwZnVsIGlmIGFuIGFjdGlvbidzIGluc3RhbmNlIGRhdGEgY291bGQgcHJvdmlk
ZSBtb3JlIGNvbnRleHQgKGUuZy4sIHRoZSBpbnB1dC9vdXRwdXQgZG9jdW1lbnRzIGNvdWxkIGlu
ZGljYXRlIHRoZSBuYW1lIG9mIHRoZSBhY3Rpb24sIHRoZSBvYmplY3QgdGhhdCB0aGUgYWN0aW9u
IHdhcyBpbnZva2VkIG9uLCBldGMuKS4NCg0KR2VuZXJhbGx5LCB0aGVyZSBpcyBzb21lIHN0YXRl
IGJlaW5nIGhlbGQgYnkgdGhlIHByb3RvY29scyB0aGF0IGNvbXBsaWNhdGVzIGV4YW1pbmluZyBp
bnN0YW5jZSBkYXRhIG91dHNpZGUgb2YgdGhlIHByb3RvY29sLCBhcyBleHRyYSBiaXRzIG9mIHN0
YXRlIG5lZWQgdG8gYmUgcGFzc2VkIGFyb3VuZCBzZXBhcmF0ZWx5LiAgSXQgd291bGQgYmUgbmlj
ZSBpZiB0aGUgZG9jdW1lbnRzIHdlcmUgKG9yIGF0IGxlYXN0IGNvdWxkIGJlKSBtb3JlIHNlbGYt
Y29udGFpbmVkLg0KDQpLZW50IC8vIGNvbnRyaWJ1dG9yDQoNCg0KT24gMi84LzE4LCA0OjE3IEFN
LCAibmV0bW9kIG9uIGJlaGFsZiBvZiBCYWxhenMgTGVuZ3llbCIgPG5ldG1vZC1ib3VuY2VzQGll
dGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mIGJhbGF6
cy5sZW5neWVsQGVyaWNzc29uLmNvbTxtYWlsdG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nzb24uY29t
Pj4gd3JvdGU6DQoNCg0KSGVsbG8sDQoNCldpdGggQmVub2l0IEkgcHJlcGFyZWQgYSBkcmFmdCBh
Ym91dCBob3cgdG8gZG9jdW1lbnQgYW5kIHVzZSBZQU5HIGRlZmluZWQgaW5zdGFuY2UgZGF0YS4g
SXQgY291bGQgYmUgdXNlZnVsIGZvciBkb2N1bWVudGluZyAgc2VydmVyIGNhcGFiaWxpdGllcyBv
ciBwcmVsb2FkaW5nIGRhdGEgZGVmaW5lZCBpbiBpbXBsZW1lbnRhdGlvbiB0aW1lIGFuZCBwcm9i
YWJseSBmb3Igb3RoZXIgcHVycG9zZXMgYXMgd2VsbC4NCg0KcmVnYXJkcyBCYWxhenMNCg0KLS0t
LS0tLS0gRm9yd2FyZGVkIE1lc3NhZ2UgLS0tLS0tLS0NClN1YmplY3Q6DQoNCk5ldyBWZXJzaW9u
IE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGVuZ3llbC1uZXRtb2QteWFuZy1pbnN0YW5jZS1kYXRh
LTAwLnR4dA0KDQpEYXRlOg0KDQpXZWQsIDcgRmViIDIwMTggMDk6Mjg6NTAgLTA4MDANCg0KRnJv
bToNCg0KaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnPG1haWx0bzppbnRlcm5ldC1kcmFmdHNAaWV0
Zi5vcmc+DQoNClRvOg0KDQpCZW5vaXQgQ2xhaXNlIDxiY2xhaXNlQGNpc2NvLmNvbT48bWFpbHRv
OmJjbGFpc2VAY2lzY28uY29tPiwgQmFsYXpzIExlbmd5ZWwgPGJhbGF6cy5sZW5neWVsQGVyaWNz
c29uLmNvbT48bWFpbHRvOmJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbT4NCg0KDQoNCkEgbmV3
IHZlcnNpb24gb2YgSS1ELCBkcmFmdC1sZW5neWVsLW5ldG1vZC15YW5nLWluc3RhbmNlLWRhdGEt
MDAudHh0DQoNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkgQmFsYXpzIExlbmd5
ZWwgYW5kIHBvc3RlZCB0byB0aGUNCg0KSUVURiByZXBvc2l0b3J5Lg0KDQoNCg0KTmFtZTogICAg
ICAgICAgZHJhZnQtbGVuZ3llbC1uZXRtb2QteWFuZy1pbnN0YW5jZS1kYXRhDQoNClJldmlzaW9u
OiAgICAgIDAwDQoNClRpdGxlOiAgICAgICAgIFlBTkcgSW5zdGFuY2UgRGF0YSBGaWxlcyBhbmQg
dGhlaXIgdXNlIGZvciBEb2N1bWVudGluZyBTZXJ2ZXIgQ2FwYWJpbGl0aWVzDQoNCkRvY3VtZW50
IGRhdGU6IDIwMTgtMDItMDYNCg0KR3JvdXA6ICAgICAgICAgSW5kaXZpZHVhbCBTdWJtaXNzaW9u
DQoNClBhZ2VzOiAgICAgICAgIDEwDQoNClVSTDogICAgICAgICAgICBodHRwczovL3d3dy5pZXRm
Lm9yZy9pbnRlcm5ldC1kcmFmdHMvZHJhZnQtbGVuZ3llbC1uZXRtb2QteWFuZy1pbnN0YW5jZS1k
YXRhLTAwLnR4dDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0
cHMtM0FfX3d3dy5pZXRmLm9yZ19pbnRlcm5ldC0yRGRyYWZ0c19kcmFmdC0yRGxlbmd5ZWwtMkRu
ZXRtb2QtMkR5YW5nLTJEaW5zdGFuY2UtMkRkYXRhLTJEMDAudHh0JmQ9RHdNRGFRJmM9SEFrWXVo
NjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBv
T0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1oblU5LUxMcGFJeldvd1plZkJ4WWZyY3ZhRUlM
RDhCejJuNmdTVEhJNVdRJnM9LWN4M1NnWXhmbUlsUldZejNSTGI4MUJEQ29KWnkyVmlxSUFJOENx
MGRsayZlPT4NCg0KU3RhdHVzOiAgICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcv
ZG9jL2RyYWZ0LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2UtZGF0YS88aHR0cHM6Ly91cmxk
ZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX19kYXRhdHJhY2tlci5pZXRm
Lm9yZ19kb2NfZHJhZnQtMkRsZW5neWVsLTJEbmV0bW9kLTJEeWFuZy0yRGluc3RhbmNlLTJEZGF0
YV8mZD1Ed01EYVEmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJ
JnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPWhuVTktTExw
YUl6V293WmVmQnhZZnJjdmFFSUxEOEJ6Mm42Z1NUSEk1V1Emcz12ZUNKS2ZZWnM4VjlrclpPSVps
TVIxSFM2am1tTzBuazVGQ1h3WWVuZ1NRJmU9Pg0KDQpIdG1saXplZDogICAgICAgaHR0cHM6Ly90
b29scy5pZXRmLm9yZy9odG1sL2RyYWZ0LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2UtZGF0
YS0wMDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff
X3Rvb2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRsZW5neWVsLTJEbmV0bW9kLTJEeWFuZy0yRGlu
c3RhbmNlLTJEZGF0YS0yRDAwJmQ9RHdNRGFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L
LW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xh
SmRjWm8mbT1oblU5LUxMcGFJeldvd1plZkJ4WWZyY3ZhRUlMRDhCejJuNmdTVEhJNVdRJnM9Um8w
THpyMy1DTUxqMDNranEyV1ZjWkNVYkJCVXFyV1BsczFaRVMwR2JuWSZlPT4NCg0KSHRtbGl6ZWQ6
ICAgICAgIGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQtbGVuZ3ll
bC1uZXRtb2QteWFuZy1pbnN0YW5jZS1kYXRhLTAwPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv
aW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fZGF0YXRyYWNrZXIuaWV0Zi5vcmdfZG9jX2h0bWxf
ZHJhZnQtMkRsZW5neWVsLTJEbmV0bW9kLTJEeWFuZy0yRGluc3RhbmNlLTJEZGF0YS0yRDAwJmQ9
RHdNRGFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6
a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1oblU5LUxMcGFJeldv
d1plZkJ4WWZyY3ZhRUlMRDhCejJuNmdTVEhJNVdRJnM9UFRRVF9PMVlwOVdHWWEyYW9ka09mVmU1
bDBERlBrS2Zlb2RqNHk1cHRIMCZlPT4NCg0KDQoNCg0KDQpBYnN0cmFjdDoNCg0KICAgVGhpcyBk
b2N1bWVudCBzcGVjaWZpZXMgYSBzdGFuZGFyZCBmaWxlIGZvcm1hdCBmb3IgWUFORyBpbnN0YW5j
ZQ0KDQogICBkYXRhLCB0aGF0IGlzIGRhdGEgdGhhdCBjb3VsZCBiZSBzdG9yZWQgaW4gYSBkYXRh
c3RvcmUgYW5kIHdob3NlDQoNCiAgIHN5bnRheCBhbmQgc2VtYW50aWNzIGlzIGRlZmluZWQgYnkg
WUFORyBtb2RlbHMuICBJbnN0YW5jZSBkYXRhIGZpbGVzDQoNCiAgIGNhbiBiZSB1c2VkIHRvIHBy
b3ZpZGUgaW5mb3JtYXRpb24gdGhhdCBpcyBkZWZpbmVkIGluIGRlc2lnbiB0aW1lLg0KDQogICBU
aGVyZSBpcyBhIG5lZWQgdG8gZG9jdW1lbnQgU2VydmVyIGNhcGFiaWxpdGllcyAod2hpY2ggYXJl
IG9mdGVuDQoNCiAgIHNwZWNpZmllZCBpbiBkZXNpZ24gdGltZSksIHdoaWNoIHNob3VsZCBiZSBk
b25lIHVzaW5nIGluc3RhbmNlIGRhdGENCg0KICAgZmlsZXMuDQoNCg0KDQoNCg0KDQoNCg0KDQpQ
bGVhc2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUg
dGltZSBvZiBzdWJtaXNzaW9uDQoNCnVudGlsIHRoZSBodG1saXplZCB2ZXJzaW9uIGFuZCBkaWZm
IGFyZSBhdmFpbGFibGUgYXQgdG9vbHMuaWV0Zi5vcmcuDQoNCg0KDQpUaGUgSUVURiBTZWNyZXRh
cmlhdA0KDQoNCg0KLS0NCg0KQmFsYXpzIExlbmd5ZWwgICAgICAgICAgICAgICAgICAgICAgIEVy
aWNzc29uIEh1bmdhcnkgTHRkLg0KDQpTZW5pb3IgU3BlY2lhbGlzdA0KDQpNb2JpbGU6ICszNi03
MC0zMzAtNzkwOSAgICAgICAgICAgICAgZW1haWw6IEJhbGF6cy5MZW5neWVsQGVyaWNzc29uLmNv
bTxtYWlsdG86QmFsYXpzLkxlbmd5ZWxAZXJpY3Nzb24uY29tPg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgltc28tbWFy
Z2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6MGluOw0KCW1zby1tYXJnaW4tYm90dG9t
LWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBpbjsNCglmb250LXNpemU6MTIuMHB0Ow0KCWZvbnQt
ZmFtaWx5OiJUaW1lcyBOZXcgUm9tYW4iO30NCnByZQ0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIENoYXIiOw0KCW1hcmdpbjowaW47
DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7DQoJZm9udC1mYW1p
bHk6IkNvdXJpZXIgTmV3Ijt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHls
ZS1uYW1lOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7
DQoJbXNvLXN0eWxlLWxpbms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseTpDb3Vy
aWVyO30NCnNwYW4uRW1haWxTdHlsZTIwDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsOw0KCWZv
bnQtZmFtaWx5OkNhbGlicmk7DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNv
bG9yOndpbmRvd3RleHQ7DQoJdGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246
bm9uZSBub25lOw0KCXZlcnRpY2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4uRW1haWxTdHlsZTIx
DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQtZmFtaWx5OkNhbGlicmk7
DQoJZm9udC12YXJpYW50Om5vcm1hbCAhaW1wb3J0YW50Ow0KCWNvbG9yOndpbmRvd3RleHQ7DQoJ
dGV4dC10cmFuc2Zvcm06bm9uZTsNCgl0ZXh0LWRlY29yYXRpb246bm9uZSBub25lOw0KCXZlcnRp
Y2FsLWFsaWduOmJhc2VsaW5lO30NCnNwYW4ubXNvSW5zDQoJe21zby1zdHlsZS10eXBlOmV4cG9y
dC1vbmx5Ow0KCW1zby1zdHlsZS1uYW1lOiIiOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7
DQoJY29sb3I6dGVhbDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQt
b25seTsNCglmb250LXNpemU6MTAuMHB0O30NCkBwYWdlIFdvcmRTZWN0aW9uMQ0KCXtzaXplOjgu
NWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4gMS4waW47fQ0KZGl2LldvcmRT
ZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0eWxlPg0KPC9oZWFkPg0KPGJv
ZHkgYmdjb2xvcj0id2hpdGUiIGxhbmc9IkVOLVVTIiBsaW5rPSJibHVlIiB2bGluaz0icHVycGxl
Ij4NCjxkaXYgY2xhc3M9IldvcmRTZWN0aW9uMSI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+W3JlbW92aW5nIG5ldGNvbmZdPG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpw
Pjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIvMTIv
MTgsIDEyOjIwIFBNLCAmcXVvdDtOZXRjb25mIG9uIGJlaGFsZiBvZiBLZW50IFdhdHNlbiZxdW90
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5ldGNvbmYtYm91bmNlc0BpZXRmLm9yZyI+bmV0Y29uZi1i
b3VuY2VzQGlldGYub3JnPC9hPiBvbiBiZWhhbGYgb2YNCjxhIGhyZWY9Im1haWx0bzprd2F0c2Vu
QGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+
Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+SGkgQmFsYXpzLDwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4m
bmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+SSdtIHVuY2xlYXIgYWJvdXQgdGhlIHNjb3BlIG9m
IHRoZSBwcm9ibGVtLiZuYnNwOyBJcyBpdCBsaW1pdGVkIHRvIHNlcnZlciBjYXBhYmlsaXRpZXM/
Jm5ic3A7Jm5ic3A7ICZuYnNwO0l0IHNlZW1zIHRoYXQgdGhlIGlkZWEgaXMgdG8gbW92ZSBmcm9t
IGhhdmluZyBhIHN0YXRlZnVsIGNvbm5lY3Rpb24gdG8gYSBsaXZlIHNlcnZlciB0byBoYXZpbmcg
YSB3YXkgdG8gcGFzcyB0aGUgZXF1aXZhbGVudA0KIHN0YXRlIGV2ZW4gd2hlbiBub3QgY29ubmVj
dGVkIHRvIHRoZSBzZXJ2ZXIuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpIj5SZWxhdGVkLCBidXQgcHJvYmFibHkgbm90IHdoYXQgeW91J3JlIGFuZ2xpbmcg
Zm9yLCBJJ3ZlIGJlZW4gaGF2aW5nIGlzc3VlcyB3aXRoIHZhbGlkYXRpbmcgUkVTVENPTkYgZXhh
bXBsZXMuJm5ic3A7IFRoZSBpc3N1ZSBpcyB0aGF0IHRoZSBSRVNUQ09ORiBkb2N1bWVudHMgYXJl
IGNvbnRleHQgc3BlY2lmaWMuJm5ic3A7IEZvciBpbnN0YW5jZSwgR0VUIC93aWRnZXRzLw0KIHJl
dHVybnMgYSBkb2N1bWVudCB0aGF0IG1pZ2h0IGhhdmUgYW4gb3V0ZXJtb3N0IGVsZW1lbnQgY2Fs
bGVkICZxdW90O3dpZGdldHMmcXVvdDssIHdoZXJlYXMgR0VUIC93aWRnZXRzL3dpZGdldD1mb28g
cmV0dXJucyBhIGRvY3VtZW50IHRoYXQgbWlnaHQgaGF2ZSBhbiBvdXRlcm1vc3QgZWxlbWVudCBj
YWxsZWQgJnF1b3Q7d2lkZ2V0JnF1b3Q7LiZuYnNwOyZuYnNwOyBJbiBvcmRlciB0byB2YWxpZGF0
ZSB0aGUgc2Vjb25kIGRvY3VtZW50LCBteSBjb2RlIGZpcnN0IHdyYXBzIHRoZSAmcXVvdDt3aWRn
ZXQmcXVvdDsNCiBlbGVtZW50IHdpdGggYSAmcXVvdDt3aWRnZXRzJnF1b3Q7IGVsZW1lbnQsIGFu
ZCB0aGVuIHRoZSB2YWxpZGF0aW9uIHRvb2xzIHdvcmsuJm5ic3A7Jm5ic3A7IDwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+UGVyaGFwcyBhIG1vcmUgZ2Vu
ZXJhbGl6ZWQgaW5zdGFuY2UgZGF0YSBtZWNoYW5pc20gY291bGQgaW5jbHVkZSB3aGVyZSBpbiB0
aGUgdHJlZSB0aGUgZGF0YSBpcyBzaXR1YXRlZD8mbmJzcDsmbmJzcDsgRm9yIGV4YW1wbGUsIGl0
IHdvdWxkIGJlIGhlbHBmdWwgaWYgYW4gYWN0aW9uJ3MgaW5zdGFuY2UgZGF0YSBjb3VsZCBwcm92
aWRlIG1vcmUgY29udGV4dCAoZS5nLiwNCiB0aGUgaW5wdXQvb3V0cHV0IGRvY3VtZW50cyBjb3Vs
ZCBpbmRpY2F0ZSB0aGUgbmFtZSBvZiB0aGUgYWN0aW9uLCB0aGUgb2JqZWN0IHRoYXQgdGhlIGFj
dGlvbiB3YXMgaW52b2tlZCBvbiwgZXRjLikuJm5ic3A7Jm5ic3A7DQo8L3NwYW4+PG86cD48L286
cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs
aWJyaSI+Jm5ic3A7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkdlbmVyYWxseSwgdGhlcmUgaXMgc29t
ZSBzdGF0ZSBiZWluZyBoZWxkIGJ5IHRoZSBwcm90b2NvbHMgdGhhdCBjb21wbGljYXRlcyBleGFt
aW5pbmcgaW5zdGFuY2UgZGF0YSBvdXRzaWRlIG9mIHRoZSBwcm90b2NvbCwgYXMgZXh0cmEgYml0
cyBvZiBzdGF0ZSBuZWVkIHRvIGJlIHBhc3NlZCBhcm91bmQgc2VwYXJhdGVseS4mbmJzcDsgSXQg
d291bGQgYmUgbmljZQ0KIGlmIHRoZSBkb2N1bWVudHMgd2VyZSAob3IgYXQgbGVhc3QgY291bGQg
YmUpIG1vcmUgc2VsZi1jb250YWluZWQuPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpDYWxpYnJpIj5LZW50IC8vIGNvbnRyaWJ1dG9yPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmki
PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8L3NwYW4+PG86cD48L286cD48L3A+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIvOC8xOCwgNDoxNyBBTSwg
JnF1b3Q7bmV0bW9kIG9uIGJlaGFsZiBvZiBCYWxhenMgTGVuZ3llbCZxdW90OyAmbHQ7PGEgaHJl
Zj0ibWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9y
ZzwvYT4gb24gYmVoYWxmIG9mDQo8YSBocmVmPSJtYWlsdG86YmFsYXpzLmxlbmd5ZWxAZXJpY3Nz
b24uY29tIj5iYWxhenMubGVuZ3llbEBlcmljc3Nvbi5jb208L2E+Jmd0OyB3cm90ZTo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jm5i
c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwPkhlbGxvLDxvOnA+PC9vOnA+PC9wPg0KPHA+
V2l0aCBCZW5vaXQgSSBwcmVwYXJlZCBhIGRyYWZ0IGFib3V0IGhvdyB0byBkb2N1bWVudCBhbmQg
dXNlIFlBTkcgZGVmaW5lZCBpbnN0YW5jZSBkYXRhLiBJdCBjb3VsZCBiZSB1c2VmdWwgZm9yIGRv
Y3VtZW50aW5nJm5ic3A7IHNlcnZlciBjYXBhYmlsaXRpZXMgb3IgcHJlbG9hZGluZyBkYXRhIGRl
ZmluZWQgaW4gaW1wbGVtZW50YXRpb24gdGltZSBhbmQgcHJvYmFibHkgZm9yIG90aGVyIHB1cnBv
c2VzIGFzIHdlbGwuPG86cD48L286cD48L3A+DQo8cD5yZWdhcmRzIEJhbGF6czxvOnA+PC9vOnA+
PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCi0tLS0tLS0tIEZvcndhcmRl
ZCBNZXNzYWdlIC0tLS0tLS0tIDxvOnA+PC9vOnA+PC9wPg0KPHRhYmxlIGNsYXNzPSJNc29Ob3Jt
YWxUYWJsZSIgYm9yZGVyPSIwIiBjZWxsc3BhY2luZz0iMCIgY2VsbHBhZGRpbmc9IjAiPg0KPHRi
b2R5Pg0KPHRyPg0KPHRkIG5vd3JhcD0iIiB2YWxpZ249InRvcCIgc3R5bGU9InBhZGRpbmc6MGlu
IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIGFsaWduPSJyaWdodCIgc3R5bGU9
InRleHQtYWxpZ246cmlnaHQiPjxiPlN1YmplY3Q6IDwvYj48bzpwPjwvbzpwPjwvcD4NCjwvdGQ+
DQo8dGQgc3R5bGU9InBhZGRpbmc6MGluIDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPk5ldyBWZXJzaW9uIE5vdGlmaWNhdGlvbiBmb3IgZHJhZnQtbGVuZ3llbC1uZXRtb2QteWFu
Zy1pbnN0YW5jZS1kYXRhLTAwLnR4dDxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjwvdHI+DQo8dHI+
DQo8dGQgbm93cmFwPSIiIHZhbGlnbj0idG9wIiBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAw
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgYWxpZ249InJpZ2h0IiBzdHlsZT0idGV4dC1hbGln
bjpyaWdodCI+PGI+RGF0ZTogPC9iPjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0i
cGFkZGluZzowaW4gMGluIDBpbiAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2VkLCA3IEZl
YiAyMDE4IDA5OjI4OjUwIC0wODAwPG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4N
Cjx0ZCBub3dyYXA9IiIgdmFsaWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBp
biI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWdu
OnJpZ2h0Ij48Yj5Gcm9tOiA8L2I+PG86cD48L286cD48L3A+DQo8L3RkPg0KPHRkIHN0eWxlPSJw
YWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJt
YWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIj5pbnRlcm5ldC1kcmFmdHNAaWV0Zi5vcmc8
L2E+PG86cD48L286cD48L3A+DQo8L3RkPg0KPC90cj4NCjx0cj4NCjx0ZCBub3dyYXA9IiIgdmFs
aWduPSJ0b3AiIHN0eWxlPSJwYWRkaW5nOjBpbiAwaW4gMGluIDBpbiI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIiBhbGlnbj0icmlnaHQiIHN0eWxlPSJ0ZXh0LWFsaWduOnJpZ2h0Ij48Yj5UbzogPC9i
PjxvOnA+PC9vOnA+PC9wPg0KPC90ZD4NCjx0ZCBzdHlsZT0icGFkZGluZzowaW4gMGluIDBpbiAw
aW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QmVub2l0IENsYWlzZSA8YSBocmVmPSJtYWlsdG86
YmNsYWlzZUBjaXNjby5jb20iPiZsdDtiY2xhaXNlQGNpc2NvLmNvbSZndDs8L2E+LCBCYWxhenMg
TGVuZ3llbA0KPGEgaHJlZj0ibWFpbHRvOmJhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSI+Jmx0
O2JhbGF6cy5sZW5neWVsQGVyaWNzc29uLmNvbSZndDs8L2E+PG86cD48L286cD48L3A+DQo8L3Rk
Pg0KPC90cj4NCjwvdGJvZHk+DQo8L3RhYmxlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9
Im1hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxwcmU+QSBuZXcg
dmVyc2lvbiBvZiBJLUQsIGRyYWZ0LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2UtZGF0YS0w
MC50eHQ8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5oYXMgYmVlbiBzdWNjZXNzZnVsbHkgc3VibWl0
dGVkIGJ5IEJhbGF6cyBMZW5neWVsIGFuZCBwb3N0ZWQgdG8gdGhlPG86cD48L286cD48L3ByZT4N
CjxwcmU+SUVURiByZXBvc2l0b3J5LjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPk5hbWU6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IGRyYWZ0LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2Ut
ZGF0YTxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlJldmlzaW9uOiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyAwMDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPlRpdGxlOiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyBZQU5HIEluc3RhbmNlIERhdGEgRmls
ZXMgYW5kIHRoZWlyIHVzZSBmb3IgRG9jdW1lbnRpbmcgU2VydmVyIENhcGFiaWxpdGllczxvOnA+
PC9vOnA+PC9wcmU+DQo8cHJlPkRvY3VtZW50IGRhdGU6IDIwMTgtMDItMDY8bzpwPjwvbzpwPjwv
cHJlPg0KPHByZT5Hcm91cDombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsgSW5kaXZpZHVhbCBTdWJtaXNzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+UGFn
ZXM6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDEwPG86
cD48L286cD48L3ByZT4NCjxwcmU+VVJMOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRwczovL3VybGRl
ZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19pbnRl
cm5ldC0yRGRyYWZ0c19kcmFmdC0yRGxlbmd5ZWwtMkRuZXRtb2QtMkR5YW5nLTJEaW5zdGFuY2Ut
MkRkYXRhLTJEMDAudHh0JmFtcDtkPUR3TURhUSZhbXA7Yz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVq
QlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ
YUdUdmpJU2xhSmRjWm8mYW1wO209aG5VOS1MTHBhSXpXb3daZWZCeFlmcmN2YUVJTEQ4QnoybjZn
U1RISTVXUSZhbXA7cz0tY3gzU2dZeGZtSWxSV1l6M1JMYjgxQkRDb0paeTJWaXFJQUk4Q3EwZGxr
JmFtcDtlPSI+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzL2RyYWZ0LWxlbmd5
ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2UtZGF0YS0wMC50eHQ8L2E+PG86cD48L286cD48L3ByZT4N
CjxwcmU+U3RhdHVzOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyA8YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9
aHR0cHMtM0FfX2RhdGF0cmFja2VyLmlldGYub3JnX2RvY19kcmFmdC0yRGxlbmd5ZWwtMkRuZXRt
b2QtMkR5YW5nLTJEaW5zdGFuY2UtMkRkYXRhXyZhbXA7ZD1Ed01EYVEmYW1wO2M9SEFrWXVoNjNy
c3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQ
b09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPWhuVTktTExwYUl6V293WmVmQnhZZnJj
dmFFSUxEOEJ6Mm42Z1NUSEk1V1EmYW1wO3M9dmVDSktmWVpzOFY5a3JaT0labE1SMUhTNmptbU8w
bms1RkNYd1llbmdTUSZhbXA7ZT0iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWxlbmd5ZWwtbmV0bW9kLXlhbmctaW5zdGFuY2UtZGF0YS88L2E+PG86cD48L286cD48L3By
ZT4NCjxwcmU+SHRtbGl6ZWQ6Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7IDxh
IGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0z
QV9fdG9vbHMuaWV0Zi5vcmdfaHRtbF9kcmFmdC0yRGxlbmd5ZWwtMkRuZXRtb2QtMkR5YW5nLTJE
aW5zdGFuY2UtMkRkYXRhLTJEMDAmYW1wO2Q9RHdNRGFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2Ni
ZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFu
MmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT1oblU5LUxMcGFJeldvd1plZkJ4WWZyY3ZhRUlMRDhC
ejJuNmdTVEhJNVdRJmFtcDtzPVJvMEx6cjMtQ01MajAza2pxMldWY1pDVWJCQlVxcldQbHMxWkVT
MEdiblkmYW1wO2U9Ij5odHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtbGVuZ3llbC1u
ZXRtb2QteWFuZy1pbnN0YW5jZS1kYXRhLTAwPC9hPjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPkh0
bWxpemVkOiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyA8YSBocmVmPSJodHRw
czovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX2RhdGF0cmFj
a2VyLmlldGYub3JnX2RvY19odG1sX2RyYWZ0LTJEbGVuZ3llbC0yRG5ldG1vZC0yRHlhbmctMkRp
bnN0YW5jZS0yRGRhdGEtMkQwMCZhbXA7ZD1Ed01EYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2Jm
aDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4y
Z3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPWhuVTktTExwYUl6V293WmVmQnhZZnJjdmFFSUxEOEJ6
Mm42Z1NUSEk1V1EmYW1wO3M9UFRRVF9PMVlwOVdHWWEyYW9ka09mVmU1bDBERlBrS2Zlb2RqNHk1
cHRIMCZhbXA7ZT0iPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2h0bWwvZHJhZnQt
bGVuZ3llbC1uZXRtb2QteWFuZy1pbnN0YW5jZS1kYXRhLTAwPC9hPjxvOnA+PC9vOnA+PC9wcmU+
DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9w
cmU+DQo8cHJlPkFic3RyYWN0OjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBU
aGlzIGRvY3VtZW50IHNwZWNpZmllcyBhIHN0YW5kYXJkIGZpbGUgZm9ybWF0IGZvciBZQU5HIGlu
c3RhbmNlPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGRhdGEsIHRoYXQgaXMg
ZGF0YSB0aGF0IGNvdWxkIGJlIHN0b3JlZCBpbiBhIGRhdGFzdG9yZSBhbmQgd2hvc2U8bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDsmbmJzcDsgc3ludGF4IGFuZCBzZW1hbnRpY3MgaXMgZGVm
aW5lZCBieSBZQU5HIG1vZGVscy4mbmJzcDsgSW5zdGFuY2UgZGF0YSBmaWxlczxvOnA+PC9vOnA+
PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNwOyBjYW4gYmUgdXNlZCB0byBwcm92aWRlIGluZm9ybWF0
aW9uIHRoYXQgaXMgZGVmaW5lZCBpbiBkZXNpZ24gdGltZS48bzpwPjwvbzpwPjwvcHJlPg0KPHBy
ZT4mbmJzcDsmbmJzcDsgVGhlcmUgaXMgYSBuZWVkIHRvIGRvY3VtZW50IFNlcnZlciBjYXBhYmls
aXRpZXMgKHdoaWNoIGFyZSBvZnRlbjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOyZuYnNw
OyBzcGVjaWZpZWQgaW4gZGVzaWduIHRpbWUpLCB3aGljaCBzaG91bGQgYmUgZG9uZSB1c2luZyBp
bnN0YW5jZSBkYXRhPG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7IGZpbGVzLjxv
OnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8
bzpwPjwvbzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5QbGVh
c2Ugbm90ZSB0aGF0IGl0IG1heSB0YWtlIGEgY291cGxlIG9mIG1pbnV0ZXMgZnJvbSB0aGUgdGlt
ZSBvZiBzdWJtaXNzaW9uPG86cD48L286cD48L3ByZT4NCjxwcmU+dW50aWwgdGhlIGh0bWxpemVk
IHZlcnNpb24gYW5kIGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy48bzpwPjwv
bzpwPjwvcHJlPg0KPHByZT4mbmJzcDs8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5UaGUgSUVURiBT
ZWNyZXRhcmlhdDxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPiZuYnNwOzxvOnA+PC9vOnA+PC9wcmU+
DQo8L2Rpdj4NCjxwcmU+LS0gPG86cD48L286cD48L3ByZT4NCjxwcmU+QmFsYXpzIExlbmd5ZWwm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsgRXJpY3Nzb24gSHVuZ2FyeSBMdGQuPG86cD48L286cD48L3ByZT4N
CjxwcmU+U2VuaW9yIFNwZWNpYWxpc3Q8bzpwPjwvbzpwPjwvcHJlPg0KPHByZT5Nb2JpbGU6ICYj
NDM7MzYtNzAtMzMwLTc5MDkmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgZW1haWw6IDxhIGhyZWY9Im1h
aWx0bzpCYWxhenMuTGVuZ3llbEBlcmljc3Nvbi5jb20iPkJhbGF6cy5MZW5neWVsQGVyaWNzc29u
LmNvbTwvYT4gPG86cD48L286cD48L3ByZT4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9odG1sPg0K

--_000_A2DF7961BF614F36A0C1032A4BC5EAFCjunipernet_--


From nobody Mon Feb 12 09:29:43 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D609B12D870 for ; Mon, 12 Feb 2018 09:29:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y2UqQT2m9knx for ; Mon, 12 Feb 2018 09:29:39 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 32D6612D864 for ; Mon, 12 Feb 2018 09:29:39 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 01DBE675; Mon, 12 Feb 2018 18:29:38 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id dbkmgLfHCV9Z; Mon, 12 Feb 2018 18:29:35 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Mon, 12 Feb 2018 18:29:37 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id B073A2014E; Mon, 12 Feb 2018 18:29:37 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id e7OIg2qu2W66; Mon, 12 Feb 2018 18:29:36 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 970DF2014B; Mon, 12 Feb 2018 18:29:36 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 7E1B54243CEA; Mon, 12 Feb 2018 18:29:36 +0100 (CET)
Date: Mon, 12 Feb 2018 18:29:36 +0100
From: Juergen Schoenwaelder 
To: Ladislav Lhotka 
Cc: Martin Bjorklund , netmod@ietf.org
Message-ID: <20180212172936.lt2stijpxgk6o3ug@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Ladislav Lhotka , Martin Bjorklund , netmod@ietf.org
References: <87fu6axobc.fsf@nic.cz> <20180212.130212.2080346646041413993.mbj@tail-f.com> <1518445591.13433.81.camel@nic.cz> <20180212143749.vmjwgtx2lgxxgbcw@elstar.local> <1518448469.13433.104.camel@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1518448469.13433.104.camel@nic.cz>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 17:29:43 -0000

On Mon, Feb 12, 2018 at 04:14:29PM +0100, Ladislav Lhotka wrote:
> On Mon, 2018-02-12 at 15:37 +0100, Juergen Schoenwaelder wrote:
> > On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
> >  
> > > > > **** Sec. 1 - YANG library stability
> > > > > 
> > > > >      The text basically says that the YANG library information can
> > > > >      change at any time. This has been recently discussed but I
> > > > >      haven't seen any conclusion yet. I understand it is difficult to
> > > > >      enumerate all the situations when this information can change,
> > > > >      but it should also be emphasized that YL info is not just another
> > > > >      subtree of state data and that it should not change haphazardly.
> > > > 
> > > > I agree, but I think that YANG library's job is to report what the
> > > > server implements.  If the server dynamically changes its set of
> > > > loaded modules, then YL should adapt.
> > > > 
> > > > I welcome more discussion on this topic, but I don't think it has to
> > > > be documented in this draft.
> > > 
> > > What about this?
> > > 
> > > OLD
> > >    The YANG library information can be different on every server and it
> > >    can change at runtime or across a server reboot.  If a server
> > >    implements multiple network management protocols to access the
> > >    server's datastores, then each such protocol may have its own
> > >    conceptual instantiation of the YANG library.
> > > 
> > > NEW
> > >    The YANG library information represents a management API for a given
> > > server, 
> > >    and should therefore be as stable as possible. The circumstances under
> > > which 
> > >    this information can change are outside the scope of this document but it
> > > is 
> > >    advisable to consider potential impact on clients.
> > 
> > I like the old text because it tells the client clearly that this data
> > can change. And the statement has been in RFC 7895 in the exact same
> 
> My problem with the current text is that it seems to make no difference between
> YANG library and any other state data.

The sentence starts with 'The YANG library information' and what
follows is all scoped to 'YANG library information'.
 
> > wording. If you want to add a statement that servers should not change
> > the YANG library without reason I could live with that but any attempt
> > to write text that makes the server somewhat guilty when a client is
> 
> Not guilty but careful. There is no requirement that clients check YANG library
> between every two operations, and notifications are optional.


So let me try to make an alternate proposal. (I only added the second
sentence.)

NEW:

   The YANG library information can be different on every server and
   it can change at runtime or across a server reboot. Servers may
   schedule YANG library changes in way that minimizes the impact on
   active clients. If a server implements multiple network management
   protocols to access the server's datastores, then each such
   protocol may have its own conceptual instantiation of the YANG
   library.
 
> > not prepared to handle a YANG library change is IMHO a fundamental
> > change from what RFC 7895 said.
> > 
> > > > >      It is like with database schemas, REST APIs and the like. Of
> > > > >      course, these can change as well, but everybody has to understand
> > > > >      that doing so means transition problems, broken clients etc.
> > > > > 
> > > > >      For this reason, it might be useful to set YL and schema mount
> > > > >      data aside and call them metadata or schema information - even if
> > > > >      we continue modelling them with YANG.
> > > > 
> > > > Do you have some concrete proposal for where to introduce this term?
> > > 
> > > In RESTCONF it could be a separate well-known resource outside all
> > > datastores.
> > 
> > Putting the data into a different place does not change the impact of
> > the data changing. So I do not understand which problem introducing
> > yet another datastore solves.
> 
> Nothing except emphasizing the difference between data and metadata, which is
> IMO an important one.

So its a different topic - one that we closed before I thought.
 
> > > > > **** Sec. 4 - checksum
> > > > > 
> > > > >      I think it would be very useful (even if not immediately) to
> > > > >      standardize the procedure for computing the checksum. What I
> > > > >      envision are systems that construct and process YANG schemas
> > > > >      (such as the YANG Catalog). They could benefit from having a
> > > > >      universal hash string as a characteristic of any particular
> > > > >      schema. Just consider how useful the universal hashes are e.g. in
> > > > >      git.
> > > > 
> > > > Ok.  It would be interesting to see such a scheme.  But I agree it is
> > > > not needed immediately for this document.
> > > 
> > > Checksums are mandatory, so every implementation has to invent some scheme.
> > > 
> > > Actually, it might be useful to have checksums also on module-sets, schemas
> > > and
> > > datastores so that the client can easily localize the changes and retrieve
> > > again
> > > only necessary data.
> > 
> > With RESTCONF, you can use etags and conditional requests. NETCONF
> > lacks a similar generic mechanism to support caching. Instead of
> > adding checksum everywhere into our data models, it seems a better
> > solution would be to add something like etags to NETCONF. Hence, we
> > reduced this to a single checksum which is needed as it is carried in
> > the hello message.
> 
> Etags work, but my point here is to have the checksum as a globally unique
> identifier of a given data model, schema or module set. For example, it would
> allow for checking that multiple servers use the same data model.

I was commenting on your proposal to have multiple checksums.

Concering your other proposal, namely to specify a detailed algorithm
how to calculate these checksums, I have reservations as well but for
other reasons. First, RFC 7895 does not specify this. Second, for the
usage in the NC hello exchange, it is not necessary that there is a
common way to calculate the checksum. Third, the current definition in
RFC 7895 (which has not been changed by the update) allows efficient
implementations since the number is essentially a version number.
Fourth, I have not seen a proposal for a robust algorithm that easily
produces the exact same checksum across a number of equivalent
configurations (the root problem is that the notion YANG library
equivalence is nowhere really defined - you can't simply serialize
YANG library data and checksum the result since there are only limited
serialization ordering requirements).

/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 Feb 12 11:39:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0838712D942 for ; Mon, 12 Feb 2018 11:39:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TJlG4M9ZUyog for ; Mon, 12 Feb 2018 11:39:53 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CB6EC126C0F for ; Mon, 12 Feb 2018 11:39:52 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id c188so6075200lfc.11 for ; Mon, 12 Feb 2018 11:39:52 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=J6TkTWqWzjobaktVCCx+/5Za2dFIysOamLj7WsY03NM=; b=H5OD8CTfVA5AtueVn3QRfV0W45YGbDBDgWortVlJPUvZSh/6RnUzKB8epPdBY61xGY 0kryv3J0fac9wc+MyC5oSiLw2EEA2pXSHyXsff7gsV+j3ln0rlImjE8NEs7hMxHKtem1 RvpWDdb+5XlRbXWtKuXSavzFQSxfoJl+PuUQ3+mJ7CiX8GyN8KeGdCxUku5R/wT3xQ1W 8sZSHtgAA2Em097QS1p3SkzdiUs1YQpKEBgJ8Vt3v61fAbv1FVI8VWyPM9mpmeKwtzDL Y4P3nCmmETbfS23dtbSNEaslXlo0wArSHpHarBNygrLLFQ7gf7uil3tk/ygu0Ur2DXe0 8R0g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=J6TkTWqWzjobaktVCCx+/5Za2dFIysOamLj7WsY03NM=; b=U67yfaKpAOGcfbIcXu8ZkbZDL6UxJc7Lq99a3ye2EjUC3bMzL1XxD0Zy5Yw9m7MIaq onsEzkhkbXja7vCFRnKoxToHnXVdRzA9ZRW7iIyw30JDOMAJzjTr+dkE4otXh9jclYb6 7uwKQKw2amNJ6OdMP4W+l1KDme0eQUoTKJqDXusaruIM8/lIXhNxfVEOY3RDRm7WtnrS MZrNeuH8ta+LWB0tLqk+2K6fMtRKvozJz/Fg6Q89nMMTy/rnGgBKMcuEWhk7D4Po9ot6 wKb733IGDrmpG2bgDF5a0sgDQyqo3dmLDEkA1RBMeAMKBPI6EueyIArQ9rHXELeihCw0 TTlA==
X-Gm-Message-State: APf1xPCHNk97Qqgz7/NzTZLv3kTkYM+reEdxlJtMDrdxdzHlaKGBCVoJ Gm8FlGoVF7Cbgzynr/60gPmZOPz7vpYuZ/XU331lMA==
X-Google-Smtp-Source: AH8x226FF1bfRCzMKiyd5PppUdIET+y0Qii7SvGoaqP78t5a0Vk2Cy+/5bsiprCAUiUdwg/dJKtj5lq2SmpB2fmMrmg=
X-Received: by 10.46.80.27 with SMTP id e27mr3628971ljb.5.1518464390922; Mon, 12 Feb 2018 11:39:50 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Mon, 12 Feb 2018 11:39:50 -0800 (PST)
In-Reply-To: <20180212143749.vmjwgtx2lgxxgbcw@elstar.local>
References: <87fu6axobc.fsf@nic.cz> <20180212.130212.2080346646041413993.mbj@tail-f.com> <1518445591.13433.81.camel@nic.cz> <20180212143749.vmjwgtx2lgxxgbcw@elstar.local>
From: Andy Bierman 
Date: Mon, 12 Feb 2018 11:39:50 -0800
Message-ID: 
To: Juergen Schoenwaelder , Ladislav Lhotka ,  Martin Bjorklund , NetMod WG 
Content-Type: multipart/alternative; boundary="f403045fc0caa01be80565090a81"
Archived-At: 
Subject: Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 19:39:56 -0000

--f403045fc0caa01be80565090a81
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 12, 2018 at 6:37 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
>
> > > > **** Sec. 1 - YANG library stability
> > > >
> > > >      The text basically says that the YANG library information can
> > > >      change at any time. This has been recently discussed but I
> > > >      haven't seen any conclusion yet. I understand it is difficult to
> > > >      enumerate all the situations when this information can change,
> > > >      but it should also be emphasized that YL info is not just
> another
> > > >      subtree of state data and that it should not change haphazardly.
> > >
> > > I agree, but I think that YANG library's job is to report what the
> > > server implements.  If the server dynamically changes its set of
> > > loaded modules, then YL should adapt.
> > >
> > > I welcome more discussion on this topic, but I don't think it has to
> > > be documented in this draft.
> >
> > What about this?
> >
> > OLD
> >    The YANG library information can be different on every server and it
> >    can change at runtime or across a server reboot.  If a server
> >    implements multiple network management protocols to access the
> >    server's datastores, then each such protocol may have its own
> >    conceptual instantiation of the YANG library.
> >
> > NEW
> >    The YANG library information represents a management API for a given
> server,
> >    and should therefore be as stable as possible. The circumstances
> under which
> >    this information can change are outside the scope of this document
> but it is
> >    advisable to consider potential impact on clients.
>
> I like the old text because it tells the client clearly that this data
> can change. And the statement has been in RFC 7895 in the exact same
> wording. If you want to add a statement that servers should not change
> the YANG library without reason I could live with that but any attempt
> to write text that makes the server somewhat guilty when a client is
> not prepared to handle a YANG library change is IMHO a fundamental
> change from what RFC 7895 said.
>
>
I strongly oppose changing this text.
Any server that can load or unload modules at run-time can change
the YANG library at run-time.


Andy


> > > >      It is like with database schemas, REST APIs and the like. Of
> > > >      course, these can change as well, but everybody has to
> understand
> > > >      that doing so means transition problems, broken clients etc.
> > > >
> > > >      For this reason, it might be useful to set YL and schema mount
> > > >      data aside and call them metadata or schema information - even
> if
> > > >      we continue modelling them with YANG.
> > >
> > > Do you have some concrete proposal for where to introduce this term?
> >
> > In RESTCONF it could be a separate well-known resource outside all
> datastores.
>
> Putting the data into a different place does not change the impact of
> the data changing. So I do not understand which problem introducing
> yet another datastore solves.
>
> > > > **** Sec. 4 - checksum
> > > >
> > > >      I think it would be very useful (even if not immediately) to
> > > >      standardize the procedure for computing the checksum. What I
> > > >      envision are systems that construct and process YANG schemas
> > > >      (such as the YANG Catalog). They could benefit from having a
> > > >      universal hash string as a characteristic of any particular
> > > >      schema. Just consider how useful the universal hashes are e.g.
> in
> > > >      git.
> > >
> > > Ok.  It would be interesting to see such a scheme.  But I agree it is
> > > not needed immediately for this document.
> >
> > Checksums are mandatory, so every implementation has to invent some
> scheme.
> >
> > Actually, it might be useful to have checksums also on module-sets,
> schemas and
> > datastores so that the client can easily localize the changes and
> retrieve again
> > only necessary data.
>
> With RESTCONF, you can use etags and conditional requests. NETCONF
> lacks a similar generic mechanism to support caching. Instead of
> adding checksum everywhere into our data models, it seems a better
> solution would be to add something like etags to NETCONF. Hence, we
> reduced this to a single checksum which is needed as it is carried in
> the hello message.
>
> /js
>
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>

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




On Mon, Feb 12, 2018 at 6:37 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav L=
hotka wrote:



> > > **** Sec. 1 - YANG library stability

> > >

> > >=C2=A0 =C2=A0 =C2=A0 The text basically says that the YANG li=
brary information can

> > >=C2=A0 =C2=A0 =C2=A0 change at any time. This has been recent=
ly discussed but I

> > >=C2=A0 =C2=A0 =C2=A0 haven't seen any conclusion yet. I u=
nderstand it is difficult to

> > >=C2=A0 =C2=A0 =C2=A0 enumerate all the situations when this i=
nformation can change,

> > >=C2=A0 =C2=A0 =C2=A0 but it should also be emphasized that YL=
 info is not just another

> > >=C2=A0 =C2=A0 =C2=A0 subtree of state data and that it should=
 not change haphazardly.

> >

> > I agree, but I think that YANG library's job is to report wha=
t the

> > server implements.=C2=A0 If the server dynamically changes its se=
t of

> > loaded modules, then YL should adapt.

> >

> > I welcome more discussion on this topic, but I don't think it=
 has to

> > be documented in this draft.

>

> What about this?

>

> OLD

>=C2=A0 =C2=A0 The YANG library information can be different on every se=
rver and it

>=C2=A0 =C2=A0 can change at runtime or across a server reboot.=C2=A0 If=
 a server

>=C2=A0 =C2=A0 implements multiple network management protocols to acces=
s the

>=C2=A0 =C2=A0 server's datastores, then each such protocol may have=
 its own

>=C2=A0 =C2=A0 conceptual instantiation of the YANG library.

>

> NEW

>=C2=A0 =C2=A0 The YANG library information represents a management API =
for a given server,

>=C2=A0 =C2=A0 and should therefore be as stable as possible. The circum=
stances under which

>=C2=A0 =C2=A0 this information can change are outside the scope of this=
 document but it is

>=C2=A0 =C2=A0 advisable to consider potential impact on clients.



I like the old text because it tells the client clearly that this data

can change. And the statement has been in RFC 7895 in the exact same

wording. If you want to add a statement that servers should not change

the YANG library without reason I could live with that but any attempt

to write text that makes the server somewhat guilty when a client is

not prepared to handle a YANG library change is IMHO a fundamental

change from what RFC 7895 said.



I strongly oppose changing this text.<=
/div>
Any server that can load or unload modules at run-time can change=

the YANG library at run-time.


Andy
=C2=A0

> > >=C2=A0 =C2=A0 =C2=A0 It is like with database schemas, REST A=
PIs and the like. Of

> > >=C2=A0 =C2=A0 =C2=A0 course, these can change as well, but ev=
erybody has to understand

> > >=C2=A0 =C2=A0 =C2=A0 that doing so means transition problems,=
 broken clients etc.

> > >

> > >=C2=A0 =C2=A0 =C2=A0 For this reason, it might be useful to s=
et YL and schema mount

> > >=C2=A0 =C2=A0 =C2=A0 data aside and call them metadata or sch=
ema information - even if

> > >=C2=A0 =C2=A0 =C2=A0 we continue modelling them with YANG.
> >

> > Do you have some concrete proposal for where to introduce this te=
rm?

>

> In RESTCONF it could be a separate well-known resource outside all dat=
astores.



Putting the data into a different place does not change the impact of

the data changing. So I do not understand which problem introducing

yet another datastore solves.



> > > **** Sec. 4 - checksum

> > >

> > >=C2=A0 =C2=A0 =C2=A0 I think it would be very useful (even if=
 not immediately) to

> > >=C2=A0 =C2=A0 =C2=A0 standardize the procedure for computing =
the checksum. What I

> > >=C2=A0 =C2=A0 =C2=A0 envision are systems that construct and =
process YANG schemas

> > >=C2=A0 =C2=A0 =C2=A0 (such as the YANG Catalog). They could b=
enefit from having a

> > >=C2=A0 =C2=A0 =C2=A0 universal hash string as a characteristi=
c of any particular

> > >=C2=A0 =C2=A0 =C2=A0 schema. Just consider how useful the uni=
versal hashes are e.g. in

> > >=C2=A0 =C2=A0 =C2=A0 git.

> >

> > Ok.=C2=A0 It would be interesting to see such a scheme.=C2=A0 But=
 I agree it is

> > not needed immediately for this document.

>

> Checksums are mandatory, so every implementation has to invent some sc=
heme.

>

> Actually, it might be useful to have checksums also on module-sets, sc=
hemas and

> datastores so that the client can easily localize the changes and retr=
ieve again

> only necessary data.



With RESTCONF, you can use etags and conditional requests. NETCONF

lacks a similar generic mechanism to support caching. Instead of

adding checksum everywhere into our data models, it seems a better

solution would be to add something like etags to NETCONF. Hence, we

reduced this to a single checksum which is needed as it is carried in

the hello message.



/js



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

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

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--f403045fc0caa01be80565090a81--


From nobody Mon Feb 12 11:44:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 94F1C1200F1 for ; Mon, 12 Feb 2018 11:44:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ryo45Q3wKbiX for ; Mon, 12 Feb 2018 11:44:44 -0800 (PST)
Received: from mail-lf0-x22e.google.com (mail-lf0-x22e.google.com [IPv6:2a00:1450:4010:c07::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 455871274D2 for ; Mon, 12 Feb 2018 11:44:44 -0800 (PST)
Received: by mail-lf0-x22e.google.com with SMTP id q194so21969405lfe.13 for ; Mon, 12 Feb 2018 11:44:44 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=vYIGgyE1rRMk4FnCzn/JXpAFlss1THHmDMqZQBbFEkQ=; b=ULpv5dEmXjLn1RygCvjnuBuaTZ5myCJMwdwhS4L0ORJHOXOctdmG4Px4rXEGorRHo1 a4tRxxIOMR8NQ7dFxbvsUeLPMnQYCSQ5hVzL61pNST3feDw7zX+2QNOj/NoZmCT/Wbmo 3qoVUmkAU5Hen7nT1JVCBxUiTgwXkibD9zBzOYnc9jkBb7DEHSLARD5aOoOUWmpbp8WL TwSwXQufKA4pBXtL/re4eafKzHclPwNhZyFmmaKtgX0crTX+faChjbSSod51zwWNDGr2 xuuLVm9Q7a/e277nr7uNdALlPVMf4CEvvrv+lwZBguWdjH80+aeV/fofcR5Rui5JFFjR hmEQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=vYIGgyE1rRMk4FnCzn/JXpAFlss1THHmDMqZQBbFEkQ=; b=p14UE2jstO3w6jYwGSYGw02eE2Om7D3tWq5DBEGvMBKZuPpwkHWvmruQPXTgqjG7uu qmSXwiUbIPkoEtKIKdMcYuVqywojA65MGTQS8Ieu9kv3ar/dcMCJ8XxWFBjuW8x51aik KHZu1EOScZjQ3tG9Tm1ymTYLafmZ0fre/sZ6BDXQf1svwzPSMu6V7/mPhL5LE9aiTp8Q 2EN89ZCkq01lcnnbp6ytVN8ZTOv6aq6BA5bvkXOSUHXnb9qG2fW9Sw77K8x//4Bm/hF3 CIy0x/bZ2cWt6HxDOci3CnaGiic4gav8LSBkNSGk9Wd2A9pxBc1Kx3luWtK3Mu1TCGcw TTfQ==
X-Gm-Message-State: APf1xPDezSL+7zCme2RHMuscbzWXQR0IAd0UjLWis1/3vClpoiAqV2bB kxfaqpRDr7aUEM79Mk/7CiumaqKy6pvTKBo+/hlLgQ==
X-Google-Smtp-Source: AH8x226Dnc+ESIoow4YAri4VcfEKfQyht7LR3kwd3VzEPozEVCEBlaQ9KKcVlzR2hP1Hnb+/M911GWQ8RE+br3o1Yhw=
X-Received: by 10.46.83.4 with SMTP id h4mr8464225ljb.47.1518464682430; Mon, 12 Feb 2018 11:44:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Mon, 12 Feb 2018 11:44:41 -0800 (PST)
In-Reply-To: <20180212172936.lt2stijpxgk6o3ug@elstar.local>
References: <87fu6axobc.fsf@nic.cz> <20180212.130212.2080346646041413993.mbj@tail-f.com> <1518445591.13433.81.camel@nic.cz> <20180212143749.vmjwgtx2lgxxgbcw@elstar.local> <1518448469.13433.104.camel@nic.cz> <20180212172936.lt2stijpxgk6o3ug@elstar.local>
From: Andy Bierman 
Date: Mon, 12 Feb 2018 11:44:41 -0800
Message-ID: 
To: Juergen Schoenwaelder , Ladislav Lhotka ,  Martin Bjorklund , NetMod WG 
Content-Type: multipart/alternative; boundary="94eb2c1cfa4a0035cf0565091c22"
Archived-At: 
Subject: Re: [netmod] LL review of draft-ietf-netconf-rfc7895bis-04
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 19:44:47 -0000

--94eb2c1cfa4a0035cf0565091c22
Content-Type: text/plain; charset="UTF-8"

On Mon, Feb 12, 2018 at 9:29 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Mon, Feb 12, 2018 at 04:14:29PM +0100, Ladislav Lhotka wrote:
> > On Mon, 2018-02-12 at 15:37 +0100, Juergen Schoenwaelder wrote:
> > > On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:
> > >
> > > > > > **** Sec. 1 - YANG library stability
> > > > > >
> > > > > >      The text basically says that the YANG library information
> can
> > > > > >      change at any time. This has been recently discussed but I
> > > > > >      haven't seen any conclusion yet. I understand it is
> difficult to
> > > > > >      enumerate all the situations when this information can
> change,
> > > > > >      but it should also be emphasized that YL info is not just
> another
> > > > > >      subtree of state data and that it should not change
> haphazardly.
> > > > >
> > > > > I agree, but I think that YANG library's job is to report what the
> > > > > server implements.  If the server dynamically changes its set of
> > > > > loaded modules, then YL should adapt.
> > > > >
> > > > > I welcome more discussion on this topic, but I don't think it has
> to
> > > > > be documented in this draft.
> > > >
> > > > What about this?
> > > >
> > > > OLD
> > > >    The YANG library information can be different on every server and
> it
> > > >    can change at runtime or across a server reboot.  If a server
> > > >    implements multiple network management protocols to access the
> > > >    server's datastores, then each such protocol may have its own
> > > >    conceptual instantiation of the YANG library.
> > > >
> > > > NEW
> > > >    The YANG library information represents a management API for a
> given
> > > > server,
> > > >    and should therefore be as stable as possible. The circumstances
> under
> > > > which
> > > >    this information can change are outside the scope of this
> document but it
> > > > is
> > > >    advisable to consider potential impact on clients.
> > >
> > > I like the old text because it tells the client clearly that this data
> > > can change. And the statement has been in RFC 7895 in the exact same
> >
> > My problem with the current text is that it seems to make no difference
> between
> > YANG library and any other state data.
>
> The sentence starts with 'The YANG library information' and what
> follows is all scoped to 'YANG library information'.
>
> > > wording. If you want to add a statement that servers should not change
> > > the YANG library without reason I could live with that but any attempt
> > > to write text that makes the server somewhat guilty when a client is
> >
> > Not guilty but careful. There is no requirement that clients check YANG
> library
> > between every two operations, and notifications are optional.
>
>
> So let me try to make an alternate proposal. (I only added the second
> sentence.)
>
> NEW:
>
>    The YANG library information can be different on every server and
>    it can change at runtime or across a server reboot. Servers may
>    schedule YANG library changes in way that minimizes the impact on
>    active clients. If a server implements multiple network management
>    protocols to access the server's datastores, then each such
>    protocol may have its own conceptual instantiation of the YANG
>    library.
>
> > > not prepared to handle a YANG library change is IMHO a fundamental
> > > change from what RFC 7895 said.
> > >
> > > > > >      It is like with database schemas, REST APIs and the like. Of
> > > > > >      course, these can change as well, but everybody has to
> understand
> > > > > >      that doing so means transition problems, broken clients etc.
> > > > > >
> > > > > >      For this reason, it might be useful to set YL and schema
> mount
> > > > > >      data aside and call them metadata or schema information -
> even if
> > > > > >      we continue modelling them with YANG.
> > > > >
> > > > > Do you have some concrete proposal for where to introduce this
> term?
> > > >
> > > > In RESTCONF it could be a separate well-known resource outside all
> > > > datastores.
> > >
> > > Putting the data into a different place does not change the impact of
> > > the data changing. So I do not understand which problem introducing
> > > yet another datastore solves.
> >
> > Nothing except emphasizing the difference between data and metadata,
> which is
> > IMO an important one.
>
> So its a different topic - one that we closed before I thought.
>
> > > > > > **** Sec. 4 - checksum
> > > > > >
> > > > > >      I think it would be very useful (even if not immediately) to
> > > > > >      standardize the procedure for computing the checksum. What I
> > > > > >      envision are systems that construct and process YANG schemas
> > > > > >      (such as the YANG Catalog). They could benefit from having a
> > > > > >      universal hash string as a characteristic of any particular
> > > > > >      schema. Just consider how useful the universal hashes are
> e.g. in
> > > > > >      git.
> > > > >
> > > > > Ok.  It would be interesting to see such a scheme.  But I agree it
> is
> > > > > not needed immediately for this document.
> > > >
> > > > Checksums are mandatory, so every implementation has to invent some
> scheme.
> > > >
> > > > Actually, it might be useful to have checksums also on module-sets,
> schemas
> > > > and
> > > > datastores so that the client can easily localize the changes and
> retrieve
> > > > again
> > > > only necessary data.
> > >
> > > With RESTCONF, you can use etags and conditional requests. NETCONF
> > > lacks a similar generic mechanism to support caching. Instead of
> > > adding checksum everywhere into our data models, it seems a better
> > > solution would be to add something like etags to NETCONF. Hence, we
> > > reduced this to a single checksum which is needed as it is carried in
> > > the hello message.
> >
> > Etags work, but my point here is to have the checksum as a globally
> unique
> > identifier of a given data model, schema or module set. For example, it
> would
> > allow for checking that multiple servers use the same data model.
>
> I was commenting on your proposal to have multiple checksums.
>
> Concering your other proposal, namely to specify a detailed algorithm
> how to calculate these checksums, I have reservations as well but for
> other reasons. First, RFC 7895 does not specify this. Second, for the
> usage in the NC hello exchange, it is not necessary that there is a
> common way to calculate the checksum. Third, the current definition in
> RFC 7895 (which has not been changed by the update) allows efficient
> implementations since the number is essentially a version number.
> Fourth, I have not seen a proposal for a robust algorithm that easily
> produces the exact same checksum across a number of equivalent
> configurations (the root problem is that the notion YANG library
> equivalence is nowhere really defined - you can't simply serialize
> YANG library data and checksum the result since there are only limited
> serialization ordering requirements).
>
>
I agree that the YANG library should not mandate a checksum algorithm.
I do not even like calling this field checksum (or having multiple fields).


> /js
>
>
Andy


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

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




On Mon, Feb 12, 2018 at 9:29 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Mon, Feb 12, 2018 at 04:14:29PM +0100, Ladislav L=
hotka wrote:

> On Mon, 2018-02-12 at 15:37 +0100, Juergen Schoenwaelder wrote:

> > On Mon, Feb 12, 2018 at 03:26:31PM +0100, Ladislav Lhotka wrote:<=
br>
> >

> > > > > **** Sec. 1 - YANG library stability

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 The text basically says that t=
he YANG library information can

> > > > >=C2=A0 =C2=A0 =C2=A0 change at any time. This has b=
een recently discussed but I

> > > > >=C2=A0 =C2=A0 =C2=A0 haven't seen any conclusio=
n yet. I understand it is difficult to

> > > > >=C2=A0 =C2=A0 =C2=A0 enumerate all the situations w=
hen this information can change,

> > > > >=C2=A0 =C2=A0 =C2=A0 but it should also be emphasiz=
ed that YL info is not just another

> > > > >=C2=A0 =C2=A0 =C2=A0 subtree of state data and that=
 it should not change haphazardly.

> > > >

> > > > I agree, but I think that YANG library's job is to =
report what the

> > > > server implements.=C2=A0 If the server dynamically chan=
ges its set of

> > > > loaded modules, then YL should adapt.

> > > >

> > > > I welcome more discussion on this topic, but I don'=
t think it has to

> > > > be documented in this draft.

> > >

> > > What about this?

> > >

> > > OLD

> > >=C2=A0 =C2=A0 The YANG library information can be different o=
n every server and it

> > >=C2=A0 =C2=A0 can change at runtime or across a server reboot=
.=C2=A0 If a server

> > >=C2=A0 =C2=A0 implements multiple network management protocol=
s to access the

> > >=C2=A0 =C2=A0 server's datastores, then each such protoco=
l may have its own

> > >=C2=A0 =C2=A0 conceptual instantiation of the YANG library.
> > >

> > > NEW

> > >=C2=A0 =C2=A0 The YANG library information represents a manag=
ement API for a given

> > > server,

> > >=C2=A0 =C2=A0 and should therefore be as stable as possible. =
The circumstances under

> > > which

> > >=C2=A0 =C2=A0 this information can change are outside the sco=
pe of this document but it

> > > is

> > >=C2=A0 =C2=A0 advisable to consider potential impact on clien=
ts.

> >

> > I like the old text because it tells the client clearly that this=
 data

> > can change. And the statement has been in RFC 7895 in the exact s=
ame

>

> My problem with the current text is that it seems to make no differenc=
e between

> YANG library and any other state data.



The sentence starts with 'The YANG library information' and what
follows is all scoped to 'YANG library information'.



> > wording. If you want to add a statement that servers should not c=
hange

> > the YANG library without reason I could live with that but any at=
tempt

> > to write text that makes the server somewhat guilty when a client=
 is

>

> Not guilty but careful. There is no requirement that clients check YAN=
G library

> between every two operations, and notifications are optional.





So let me try to make an alternate proposal. (I only added the second

sentence.)



NEW:



=C2=A0 =C2=A0The YANG library information can be different on every server =
and

=C2=A0 =C2=A0it can change at runtime or across a server reboot. Servers ma=
y

=C2=A0 =C2=A0schedule YANG library changes in way that minimizes the impact=
 on

=C2=A0 =C2=A0active clients. If a server implements multiple network manage=
ment

=C2=A0 =C2=A0protocols to access the server's datastores, then each suc=
h

=C2=A0 =C2=A0protocol may have its own conceptual instantiation of the YANG=


=C2=A0 =C2=A0library.



> > not prepared to handle a YANG library change is IMHO a fundamenta=
l

> > change from what RFC 7895 said.

> >

> > > > >=C2=A0 =C2=A0 =C2=A0 It is like with database schem=
as, REST APIs and the like. Of

> > > > >=C2=A0 =C2=A0 =C2=A0 course, these can change as we=
ll, but everybody has to understand

> > > > >=C2=A0 =C2=A0 =C2=A0 that doing so means transition=
 problems, broken clients etc.

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 For this reason, it might be u=
seful to set YL and schema mount

> > > > >=C2=A0 =C2=A0 =C2=A0 data aside and call them metad=
ata or schema information - even if

> > > > >=C2=A0 =C2=A0 =C2=A0 we continue modelling them wit=
h YANG.

> > > >

> > > > Do you have some concrete proposal for where to introdu=
ce this term?

> > >

> > > In RESTCONF it could be a separate well-known resource outsi=
de all

> > > datastores.

> >

> > Putting the data into a different place does not change the impac=
t of

> > the data changing. So I do not understand which problem introduci=
ng

> > yet another datastore solves.

>

> Nothing except emphasizing the difference between data and metadata, w=
hich is

> IMO an important one.



So its a different topic - one that we closed before I thought.



> > > > > **** Sec. 4 - checksum

> > > > >

> > > > >=C2=A0 =C2=A0 =C2=A0 I think it would be very usefu=
l (even if not immediately) to

> > > > >=C2=A0 =C2=A0 =C2=A0 standardize the procedure for =
computing the checksum. What I

> > > > >=C2=A0 =C2=A0 =C2=A0 envision are systems that cons=
truct and process YANG schemas

> > > > >=C2=A0 =C2=A0 =C2=A0 (such as the YANG Catalog). Th=
ey could benefit from having a

> > > > >=C2=A0 =C2=A0 =C2=A0 universal hash string as a cha=
racteristic of any particular

> > > > >=C2=A0 =C2=A0 =C2=A0 schema. Just consider how usef=
ul the universal hashes are e.g. in

> > > > >=C2=A0 =C2=A0 =C2=A0 git.

> > > >

> > > > Ok.=C2=A0 It would be interesting to see such a scheme.=
=C2=A0 But I agree it is

> > > > not needed immediately for this document.

> > >

> > > Checksums are mandatory, so every implementation has to inve=
nt some scheme.

> > >

> > > Actually, it might be useful to have checksums also on modul=
e-sets, schemas

> > > and

> > > datastores so that the client can easily localize the change=
s and retrieve

> > > again

> > > only necessary data.

> >

> > With RESTCONF, you can use etags and conditional requests. NETCON=
F

> > lacks a similar generic mechanism to support caching. Instead of<=
br>
> > adding checksum everywhere into our data models, it seems a bette=
r

> > solution would be to add something like etags to NETCONF. Hence, =
we

> > reduced this to a single checksum which is needed as it is carrie=
d in

> > the hello message.

>

> Etags work, but my point here is to have the checksum as a globally un=
ique

> identifier of a given data model, schema or module set. For example, i=
t would

> allow for checking that multiple servers use the same data model.



I was commenting on your proposal to have multiple checksums.



Concering your other proposal, namely to specify a detailed algorithm

how to calculate these checksums, I have reservations as well but for

other reasons. First, RFC 7895 does not specify this. Second, for the

usage in the NC hello exchange, it is not necessary that there is a

common way to calculate the checksum. Third, the current definition in

RFC 7895 (which has not been changed by the update) allows efficient

implementations since the number is essentially a version number.

Fourth, I have not seen a proposal for a robust algorithm that easily

produces the exact same checksum across a number of equivalent

configurations (the root problem is that the notion YANG library

equivalence is nowhere really defined - you can't simply serialize

YANG library data and checksum the result since there are only limited

serialization ordering requirements).



I agree that the YANG library should not mandate a c=
hecksum algorithm.
I do not even like calling this field checksum=
 (or having multiple fields).
=C2=A0

/js



Andy
=C2=A0

--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

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

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c1cfa4a0035cf0565091c22--


From nobody Mon Feb 12 12:02:30 2018
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 6A59D12D95B; Mon, 12 Feb 2018 12:02:18 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Kent Watsen 
To: 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.1
Auto-Submitted: auto-generated
Precedence: bulk
Cc: netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org, Kent Watsen , iesg-secretary@ietf.org, Lou Berger 
Message-ID: <151846573843.5994.3024536782235957795.idtracker@ietfa.amsl.com>
Date: Mon, 12 Feb 2018 12:02:18 -0800
Archived-At: 
Subject: [netmod] Publication has been requested for draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 12 Feb 2018 20:02:18 -0000

Kent Watsen has requested publication of draft-ietf-netmod-syslog-model-20 as Proposed Standard on behalf of the NETMOD working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/


From nobody Mon Feb 12 22:13:25 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA4221205F0; Mon, 12 Feb 2018 22:13:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level: 
X-Spam-Status: No, score=-4.23 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S3-xr-6ZDeCe; Mon, 12 Feb 2018 22:13:23 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 3654612E058; Mon, 12 Feb 2018 22:13:23 -0800 (PST)
Received: from lhreml707-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id F0E28AC76DAD2; Tue, 13 Feb 2018 06:13:19 +0000 (GMT)
Received: from DGGEML402-HUB.china.huawei.com (10.3.17.38) by lhreml707-cah.china.huawei.com (10.201.108.48) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 13 Feb 2018 06:13:20 +0000
Received: from DGGEML504-MBS.china.huawei.com ([169.254.11.87]) by DGGEML402-HUB.china.huawei.com ([fe80::fca6:7568:4ee3:c776%31]) with mapi id 14.03.0361.001; Tue, 13 Feb 2018 14:13:14 +0800
From: wangzitao 
To: NETMOD Working Group , netconf 
Thread-Topic: New Version Notification for draft-wang-netmod-module-revision-management-00.txt
Thread-Index: AdOkkXM8BaqAUSAUQsmjaAcEIAWYUw==
Date: Tue, 13 Feb 2018 06:13:14 +0000
Message-ID: 
Accept-Language: en-US
Content-Language: zh-CN
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.136.78.152]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] New Version Notification for draft-wang-netmod-module-revision-management-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Feb 2018 06:13:25 -0000

RGVhciBXRywNCldlIHByZXBhcmVkIGEgZG9jdW1lbnQgdG8gaW50cm9kdWNlIGEgbWV0aG9kIGZv
ciBtb2R1bGUgcmV2aXNpb25zIG1hbmFnZW1lbnQuDQpJdCBjb3VsZCBiZSB1c2VmdWwgZm9yIGlu
ZGljYXRpbmcgdGhlIGRldGFpbHMgY2hhbmdlcyBvZiBkaWZmZXJlbnQgbW9kdWxlIHJldmlzaW9u
cywNCmFuZCBoZWxwaW5nIHRoZSB1c2VyIHRvIG1hbmFnZSBhbGwgdGhlIHJldmlzaW9ucyBvZiB0
aGF0IG1vZHVsZSBhbmQga2VlcCB0cmFjayBvZiBtb2R1bGUuIA0KDQpQbGVhc2UgcmV2aWV3IGl0
LiBDb21tZW50cywgc3VnZ2VzdGlvbnMgYXJlIHdlbGNvbWUhDQoNCkJlc3QgUmVnYXJkcyENCi1N
aWNoYWVsDQoNCi0tLS0t6YKu5Lu25Y6f5Lu2LS0tLS0NCuWPkeS7tuS6ujogaW50ZXJuZXQtZHJh
ZnRzQGlldGYub3JnIFttYWlsdG86aW50ZXJuZXQtZHJhZnRzQGlldGYub3JnXSANCuWPkemAgeaX
tumXtDogMjAxOOW5tDLmnIgxM+aXpSAxNDowOQ0K5pS25Lu25Lq6OiB3YW5neml0YW8gPHdhbmd6
aXRhb0BodWF3ZWkuY29tPjsgUWluIFd1IDxiaWxsLnd1QGh1YXdlaS5jb20+OyB3YW5neml0YW8g
PHdhbmd6aXRhb0BodWF3ZWkuY29tPg0K5Li76aKYOiBOZXcgVmVyc2lvbiBOb3RpZmljYXRpb24g
Zm9yIGRyYWZ0LXdhbmctbmV0bW9kLW1vZHVsZS1yZXZpc2lvbi1tYW5hZ2VtZW50LTAwLnR4dA0K
DQoNCkEgbmV3IHZlcnNpb24gb2YgSS1ELCBkcmFmdC13YW5nLW5ldG1vZC1tb2R1bGUtcmV2aXNp
b24tbWFuYWdlbWVudC0wMC50eHQNCmhhcyBiZWVuIHN1Y2Nlc3NmdWxseSBzdWJtaXR0ZWQgYnkg
TWljaGFlbCBXYW5nIGFuZCBwb3N0ZWQgdG8gdGhlIElFVEYgcmVwb3NpdG9yeS4NCg0KTmFtZToJ
CWRyYWZ0LXdhbmctbmV0bW9kLW1vZHVsZS1yZXZpc2lvbi1tYW5hZ2VtZW50DQpSZXZpc2lvbjoJ
MDANClRpdGxlOgkJQSBZQU5HIERhdGEgTW9kZWwgZm9yIG1vZHVsZSByZXZpc2lvbiBtYW5hZ2Vt
ZW50DQpEb2N1bWVudCBkYXRlOgkyMDE4LTAyLTEyDQpHcm91cDoJCUluZGl2aWR1YWwgU3VibWlz
c2lvbg0KUGFnZXM6CQkxOQ0KVVJMOiAgICAgICAgICAgIGh0dHBzOi8vd3d3LmlldGYub3JnL2lu
dGVybmV0LWRyYWZ0cy9kcmFmdC13YW5nLW5ldG1vZC1tb2R1bGUtcmV2aXNpb24tbWFuYWdlbWVu
dC0wMC50eHQNClN0YXR1czogICAgICAgICBodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC13YW5nLW5ldG1vZC1tb2R1bGUtcmV2aXNpb24tbWFuYWdlbWVudC8NCkh0bWxpemVk
OiAgICAgICBodHRwczovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtd2FuZy1uZXRtb2QtbW9k
dWxlLXJldmlzaW9uLW1hbmFnZW1lbnQtMDANCkh0bWxpemVkOiAgICAgICBodHRwczovL2RhdGF0
cmFja2VyLmlldGYub3JnL2RvYy9odG1sL2RyYWZ0LXdhbmctbmV0bW9kLW1vZHVsZS1yZXZpc2lv
bi1tYW5hZ2VtZW50LTAwDQoNCg0KQWJzdHJhY3Q6DQogICBUaGlzIGRvY3VtZW50IGRlZmluZXMg
YSBZQU5HIERhdGEgTW9kZWwgZm9yIG1vZHVsZSByZXZpc2lvbg0KICAgbWFuYWdlbWVudC4gIEl0
IGlzIGludGVuZGVkIHRoaXMgbW9kZWwgYmUgdXNlZCBieSB2ZW5kb3JzIHdobyBzdXBwb3J0DQog
ICBtdWx0aXBsZSByZXZpc2lvbnMgb2YgdGhlIHNhbWUgWUFORyBtb2R1bGUgaW4gdGhlaXIgc3lz
dGVtcyBidXQNCiAgIGltcGxlbWVudCBvbmUgcmV2aXNpb24gb2YgYSBtb2R1bGUuICBJbiBhZGRp
dGlvbiwgdGhpcyBkb2N1bWVudA0KICAgaW50cm9kdWNlcyBhIG5ldyBnZW5lcmljIG1lY2hhbmlz
bSBiYXNlZCBvbiBSUEMsIGRlbm90ZWQgYXMgbW9kdWxlLQ0KICAgcmV2aXNpb24tY2hhbmdlLCB0
aGF0IGFsbG93IHRvIHJlcG9ydCBkaXNjcmVwYW5jeSBpbmZvcm1hdGlvbiBvZiBhDQogICBZQU5H
IG1vZHVsZSB3aXRoIHR3byBvciBtdWx0aXBsZSByZXZpc2lvbnMgdGhhdCBpcyBkZWZpbmVkIGlu
IGRlc2lnbg0KICAgdGltZS4sIGUuZy4saWRlbnRpZmllcyBhIHBsYWNlIGluIHRoZSBub2RlIGhp
ZXJhcmNoeSB3aGVyZSBkYXRhIG5vZGUNCiAgIGdldHMgY2hhbmdlZCBvciBuZXcgZGF0YSBnZXRz
IGluc2VydGVkIGFuZCBpbmRpY2F0ZSB3aGV0aGVyIHRoZQ0KICAgY2hhbmdlIHRvIHRoZSBkYXRh
IG5vZGUgaXMgYmFja3dhcmQgY29tcGF0aWJsZS4NCg0KICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
IA0KDQoNClBsZWFzZSBub3RlIHRoYXQgaXQgbWF5IHRha2UgYSBjb3VwbGUgb2YgbWludXRlcyBm
cm9tIHRoZSB0aW1lIG9mIHN1Ym1pc3Npb24gdW50aWwgdGhlIGh0bWxpemVkIHZlcnNpb24gYW5k
IGRpZmYgYXJlIGF2YWlsYWJsZSBhdCB0b29scy5pZXRmLm9yZy4NCg0KVGhlIElFVEYgU2VjcmV0
YXJpYXQNCg0K


From nobody Tue Feb 13 11:38:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 980CB12D893; Tue, 13 Feb 2018 11:38:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.229
X-Spam-Level: 
X-Spam-Status: No, score=-4.229 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8bgyk4uxZmCy; Tue, 13 Feb 2018 11:38:39 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 5129F1241F3; Tue, 13 Feb 2018 11:38:39 -0800 (PST)
Received: from lhreml705-cah.china.huawei.com (unknown [172.18.7.106]) by Forcepoint Email with ESMTP id E88002B5D5365; Tue, 13 Feb 2018 19:38:35 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml705-cah.china.huawei.com (10.201.108.46) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 13 Feb 2018 19:38:37 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML701-CHM.china.huawei.com ([169.254.3.93]) with mapi id 14.03.0382.000; Tue, 13 Feb 2018 11:38:31 -0800
From: Alexander Clemm 
To: Mahesh Jethanandani , NETCONF WG 
CC: NETMOD WG 
Thread-Topic: [Netconf] LC on YANG Library (bis)
Thread-Index: AQHTm47nGQKkuQuITEyr+4DYs4MJdKOiyLPw
Date: Tue, 13 Feb 2018 19:38:31 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com>
References: 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.216.242]
Content-Type: multipart/alternative; boundary="_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CBsjceml521mbschi_"
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Feb 2018 19:38:41 -0000

--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CBsjceml521mbschi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I have taken a look at this document.

My main comment is that one aspect that is missing, that I believe should b=
e added, concerns the inclusion of certain metadata about the modules.  Spe=
cifically, in the context of YANG-Push we had a discussion about being able=
 to mark nodes that are notifiable on change.  This is just one particular =
use case of a more general issue; in YANG-Push after much debate the conclu=
sion was for now to simply make implementors aware of this issue and advise=
 that a solution to this must be provided, with the clear understanding tha=
t eventually a standard solution should be defined.

Since the goal of YANG-Library is to allow clients to find out what is actu=
ally supported on a given server, this is the right place to keep this info=
rmation.  One possible way to address this would be, for a given module, to=
 maintain a list of "meta-info", with a key "meta-tag", and a list with ref=
erences to the nodes to which the metadata applies.  In the case of notifia=
ble-on-change, you would have a list with one entry "notifiable-on-change",=
 and then the list with the node definitions to which this tag applies.

Editorial nit:
2nd paragraph Introduction: informaton --> information

Thanks
--- Alex

From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethana=
ndani
Sent: Thursday, February 01, 2018 11:00 AM
To: NETCONF WG 
Cc: NETMOD WG 
Subject: [Netconf] LC on YANG Library (bis)

WG,

The authors of rfc7895bis have indicated that they believe the document is =
ready for LC[1].

This starts a two week LC on the draft. The LC will end on February 15.

Please send your comments on this thread. Reviews of the document, and stat=
ement of support are particularly helpful to the authors. If you have conce=
rns about the document, please state those too.

Authors please indicate if you are aware of any IPR on the document.

Thanks.

[1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html

Mahesh & Kent


--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CBsjceml521mbschi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable











Hi,


 


I have taken a look at this document.=



 


My main comment is that one aspect th=
at is missing, that I believe should be added, concerns the inclusion of ce=
rtain metadata about the modules.  Specifically,
 in the context of YANG-Push we had a discussion about being able to mark n=
odes that are notifiable on change.  This is just one particular use c=
ase of a more general issue; in YANG-Push after much debate the conclusion =
was for now to simply make implementors
 aware of this issue and advise that a solution to this must be provided, w=
ith the clear understanding that eventually a standard solution should be d=
efined.  


 


Since the goal of YANG-Library is to =
allow clients to find out what is actually supported on a given server, thi=
s is the right place to keep this information.
  One possible way to address this would be, for a given module, to ma=
intain a list of “meta-info”, with a key “meta-tag”=
, and a list with references to the nodes to which the metadata applies. &n=
bsp;In the case of notifiable-on-change, you would have a list with
 one entry “notifiable-on-change”, and then the list with the n=
ode definitions to which this tag applies. 



 


Editorial nit:


2nd paragraph Introduction=
: informaton --> information


 


Thanks


--- Alex


 








From: Netconf [mailto:netconf-bounce=
s@ietf.org]
On Behalf Of Mahesh Jethanandani

Sent: Thursday, February 01, 2018 11:00 AM

To: NETCONF WG <netconf@ietf.org>

Cc: NETMOD WG <netmod@ietf.org>

Subject: [Netconf] LC on YANG Library (bis)






 


WG,




 






The authors of rfc7895bis have indicated that they b=
elieve the document is ready for LC[1].






 






This starts a two week LC on the draft. The L=
C will end on February 15. 






 






Please send your comments on this thread. Reviews of=
 the document, and statement of support are particularly helpful to the aut=
hors. If you have concerns about the document, please state those too.=







 






Authors please indicate if you are aware of any IPR =
on the document.






 






Thanks.






 







 






Mahesh & Kent






 










--_000_644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CBsjceml521mbschi_--


From nobody Tue Feb 13 11:48:36 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D51C1250B8; Tue, 13 Feb 2018 11:48:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Jj1Lz-wCMgBT; Tue, 13 Feb 2018 11:48:25 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B5677124235; Tue, 13 Feb 2018 11:48:24 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 81AF060; Tue, 13 Feb 2018 20:48:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id wCuYFeIwjA25; Tue, 13 Feb 2018 20:48:20 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Feb 2018 20:48:23 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 341B42014E; Tue, 13 Feb 2018 20:48:23 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id SuLPHe21L9Dh; Tue, 13 Feb 2018 20:48:22 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 450792014B; Tue, 13 Feb 2018 20:48:22 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 8883D4245CB8; Tue, 13 Feb 2018 20:48:21 +0100 (CET)
Date: Tue, 13 Feb 2018 20:48:21 +0100
From: Juergen Schoenwaelder 
To: Alexander Clemm 
Cc: Mahesh Jethanandani , NETCONF WG , NETMOD WG 
Message-ID: <20180213194821.cwbwwmy7bqhvkfsd@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Alexander Clemm , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
References:  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Feb 2018 19:48:30 -0000

Alexander,

I disagree. This YANG Library is mandatory for all implementations;
what you talk about seems to concern only implementations that support
YANG push. Hence, this is an extension that should go in its own
module.

/js

On Tue, Feb 13, 2018 at 07:38:31PM +0000, Alexander Clemm wrote:
> Hi,
> 
> I have taken a look at this document.
> 
> My main comment is that one aspect that is missing, that I believe should be added, concerns the inclusion of certain metadata about the modules.  Specifically, in the context of YANG-Push we had a discussion about being able to mark nodes that are notifiable on change.  This is just one particular use case of a more general issue; in YANG-Push after much debate the conclusion was for now to simply make implementors aware of this issue and advise that a solution to this must be provided, with the clear understanding that eventually a standard solution should be defined.
> 
> Since the goal of YANG-Library is to allow clients to find out what is actually supported on a given server, this is the right place to keep this information.  One possible way to address this would be, for a given module, to maintain a list of "meta-info", with a key "meta-tag", and a list with references to the nodes to which the metadata applies.  In the case of notifiable-on-change, you would have a list with one entry "notifiable-on-change", and then the list with the node definitions to which this tag applies.
> 
> Editorial nit:
> 2nd paragraph Introduction: informaton --> information
> 
> Thanks
> --- Alex
> 
> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh Jethanandani
> Sent: Thursday, February 01, 2018 11:00 AM
> To: NETCONF WG 
> Cc: NETMOD WG 
> Subject: [Netconf] LC on YANG Library (bis)
> 
> WG,
> 
> The authors of rfc7895bis have indicated that they believe the document is ready for LC[1].
> 
> This starts a two week LC on the draft. The LC will end on February 15.
> 
> Please send your comments on this thread. Reviews of the document, and statement of support are particularly helpful to the authors. If you have concerns about the document, please state those too.
> 
> Authors please indicate if you are aware of any IPR on the document.
> 
> Thanks.
> 
> [1] https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
> 
> Mahesh & Kent
> 

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


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


From nobody Tue Feb 13 11:58:51 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AE36612D87E; Tue, 13 Feb 2018 11:58:45 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level: 
X-Spam-Status: No, score=-4.23 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XW8bDpNIZ6CL; Tue, 13 Feb 2018 11:58:43 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 21C021200FC; Tue, 13 Feb 2018 11:58:43 -0800 (PST)
Received: from lhreml701-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 1DF9B8FC9BAE7; Tue, 13 Feb 2018 19:58:40 +0000 (GMT)
Received: from SJCEML703-CHM.china.huawei.com (10.208.112.39) by lhreml701-cah.china.huawei.com (10.201.108.42) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 13 Feb 2018 19:58:41 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML703-CHM.china.huawei.com ([169.254.5.179]) with mapi id 14.03.0382.000;  Tue, 13 Feb 2018 11:58:38 -0800
From: Alexander Clemm 
To: Juergen Schoenwaelder 
CC: Mahesh Jethanandani , NETCONF WG , NETMOD WG 
Thread-Topic: [netmod] [Netconf] LC on YANG Library (bis)
Thread-Index: AQHTm47nGQKkuQuITEyr+4DYs4MJdKOiyLPwgACNf4D//3uHkA==
Date: Tue, 13 Feb 2018 19:58:37 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com>
References:  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com> <20180213194821.cwbwwmy7bqhvkfsd@elstar.local>
In-Reply-To: <20180213194821.cwbwwmy7bqhvkfsd@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.216.242]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Feb 2018 19:58:46 -0000

Well, we need a general solution for that.  YANG-push is just one use case.=
  There are other cases where there will be "metadata" (that does not perta=
in to instance data)  and capabilities that clients want to discover.  YANG=
 library (in itself providing "metadata" about what a server supports and i=
s capable of) is an excellent place to maintain this information.  It also =
provides the opportunity to be systemic about it, as opposed to requiring e=
veryone to define their own little custom extensions. =20
--- Alex

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Tuesday, February 13, 2018 11:48 AM
> To: Alexander Clemm 
> Cc: Mahesh Jethanandani ; NETCONF WG
> ; NETMOD WG 
> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
>=20
> Alexander,
>=20
> I disagree. This YANG Library is mandatory for all implementations; what =
you talk
> about seems to concern only implementations that support YANG push. Hence=
,
> this is an extension that should go in its own module.
>=20
> /js
>=20
> On Tue, Feb 13, 2018 at 07:38:31PM +0000, Alexander Clemm wrote:
> > Hi,
> >
> > I have taken a look at this document.
> >
> > My main comment is that one aspect that is missing, that I believe shou=
ld be
> added, concerns the inclusion of certain metadata about the modules.
> Specifically, in the context of YANG-Push we had a discussion about being=
 able to
> mark nodes that are notifiable on change.  This is just one particular us=
e case of a
> more general issue; in YANG-Push after much debate the conclusion was for=
 now
> to simply make implementors aware of this issue and advise that a solutio=
n to
> this must be provided, with the clear understanding that eventually a sta=
ndard
> solution should be defined.
> >
> > Since the goal of YANG-Library is to allow clients to find out what is =
actually
> supported on a given server, this is the right place to keep this informa=
tion.  One
> possible way to address this would be, for a given module, to maintain a =
list of
> "meta-info", with a key "meta-tag", and a list with references to the nod=
es to
> which the metadata applies.  In the case of notifiable-on-change, you wou=
ld have
> a list with one entry "notifiable-on-change", and then the list with the =
node
> definitions to which this tag applies.
> >
> > Editorial nit:
> > 2nd paragraph Introduction: informaton --> information
> >
> > Thanks
> > --- Alex
> >
> > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh
> > Jethanandani
> > Sent: Thursday, February 01, 2018 11:00 AM
> > To: NETCONF WG 
> > Cc: NETMOD WG 
> > Subject: [Netconf] LC on YANG Library (bis)
> >
> > WG,
> >
> > The authors of rfc7895bis have indicated that they believe the document=
 is
> ready for LC[1].
> >
> > This starts a two week LC on the draft netconf-rfc7895bis-04>. The LC will end on February 15.
> >
> > Please send your comments on this thread. Reviews of the document, and
> statement of support are particularly helpful to the authors. If you have=
 concerns
> about the document, please state those too.
> >
> > Authors please indicate if you are aware of any IPR on the document.
> >
> > Thanks.
> >
> > [1]
> > https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
> >
> > Mahesh & Kent
> >
>=20
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
>=20
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         


From nobody Tue Feb 13 12:29:06 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2E76912EAB3; Tue, 13 Feb 2018 12:29:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SUDuJQmHPe9S; Tue, 13 Feb 2018 12:29:02 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7D8FB12EAAA; Tue, 13 Feb 2018 12:29:02 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 40ECC6AE; Tue, 13 Feb 2018 21:29:01 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id 5ak1UOOOXkQ8; Tue, 13 Feb 2018 21:28:58 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 13 Feb 2018 21:29:01 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 25DCF2014E; Tue, 13 Feb 2018 21:29:01 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id fjUymTENhbV6; Tue, 13 Feb 2018 21:29:00 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 3080D2014B; Tue, 13 Feb 2018 21:29:00 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id E10FF4245F0D; Tue, 13 Feb 2018 21:28:58 +0100 (CET)
Date: Tue, 13 Feb 2018 21:28:58 +0100
From: Juergen Schoenwaelder 
To: Alexander Clemm 
Cc: Mahesh Jethanandani , NETCONF WG , NETMOD WG 
Message-ID: <20180213202858.uvowmjtx2uk4snyz@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Alexander Clemm , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
References:  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com> <20180213194821.cwbwwmy7bqhvkfsd@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Feb 2018 20:29:05 -0000

I must have missed your actionable proposal that is relevant for _all_
NETCONF and RESTCONF implementations.

YANG data models are extensible so lets use that.

/js

On Tue, Feb 13, 2018 at 07:58:37PM +0000, Alexander Clemm wrote:
> Well, we need a general solution for that.  YANG-push is just one use case.  There are other cases where there will be "metadata" (that does not pertain to instance data)  and capabilities that clients want to discover.  YANG library (in itself providing "metadata" about what a server supports and is capable of) is an excellent place to maintain this information.  It also provides the opportunity to be systemic about it, as opposed to requiring everyone to define their own little custom extensions.  
> --- Alex
> 
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> > Sent: Tuesday, February 13, 2018 11:48 AM
> > To: Alexander Clemm 
> > Cc: Mahesh Jethanandani ; NETCONF WG
> > ; NETMOD WG 
> > Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> > 
> > Alexander,
> > 
> > I disagree. This YANG Library is mandatory for all implementations; what you talk
> > about seems to concern only implementations that support YANG push. Hence,
> > this is an extension that should go in its own module.
> > 
> > /js
> > 
> > On Tue, Feb 13, 2018 at 07:38:31PM +0000, Alexander Clemm wrote:
> > > Hi,
> > >
> > > I have taken a look at this document.
> > >
> > > My main comment is that one aspect that is missing, that I believe should be
> > added, concerns the inclusion of certain metadata about the modules.
> > Specifically, in the context of YANG-Push we had a discussion about being able to
> > mark nodes that are notifiable on change.  This is just one particular use case of a
> > more general issue; in YANG-Push after much debate the conclusion was for now
> > to simply make implementors aware of this issue and advise that a solution to
> > this must be provided, with the clear understanding that eventually a standard
> > solution should be defined.
> > >
> > > Since the goal of YANG-Library is to allow clients to find out what is actually
> > supported on a given server, this is the right place to keep this information.  One
> > possible way to address this would be, for a given module, to maintain a list of
> > "meta-info", with a key "meta-tag", and a list with references to the nodes to
> > which the metadata applies.  In the case of notifiable-on-change, you would have
> > a list with one entry "notifiable-on-change", and then the list with the node
> > definitions to which this tag applies.
> > >
> > > Editorial nit:
> > > 2nd paragraph Introduction: informaton --> information
> > >
> > > Thanks
> > > --- Alex
> > >
> > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of Mahesh
> > > Jethanandani
> > > Sent: Thursday, February 01, 2018 11:00 AM
> > > To: NETCONF WG 
> > > Cc: NETMOD WG 
> > > Subject: [Netconf] LC on YANG Library (bis)
> > >
> > > WG,
> > >
> > > The authors of rfc7895bis have indicated that they believe the document is
> > ready for LC[1].
> > >
> > > This starts a two week LC on the draft > netconf-rfc7895bis-04>. The LC will end on February 15.
> > >
> > > Please send your comments on this thread. Reviews of the document, and
> > statement of support are particularly helpful to the authors. If you have concerns
> > about the document, please state those too.
> > >
> > > Authors please indicate if you are aware of any IPR on the document.
> > >
> > > Thanks.
> > >
> > > [1]
> > > https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
> > >
> > > Mahesh & Kent
> > >
> > 
> > > _______________________________________________
> > > 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         

-- 
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 Feb 13 13:25:59 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 312CE126E01; Tue, 13 Feb 2018 13:25:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.23
X-Spam-Level: 
X-Spam-Status: No, score=-4.23 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, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gdr2tAuxB7Qb; Tue, 13 Feb 2018 13:25:55 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 6072D126B72; Tue, 13 Feb 2018 13:25:55 -0800 (PST)
Received: from lhreml704-cah.china.huawei.com (unknown [172.18.7.107]) by Forcepoint Email with ESMTP id 93B318EA3B49A; Tue, 13 Feb 2018 21:25:51 +0000 (GMT)
Received: from SJCEML701-CHM.china.huawei.com (10.208.112.40) by lhreml704-cah.china.huawei.com (10.201.108.45) with Microsoft SMTP Server (TLS) id 14.3.361.1; Tue, 13 Feb 2018 21:25:52 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML701-CHM.china.huawei.com ([169.254.3.93]) with mapi id 14.03.0382.000; Tue, 13 Feb 2018 13:25:46 -0800
From: Alexander Clemm 
To: Juergen Schoenwaelder 
CC: Mahesh Jethanandani , NETCONF WG , NETMOD WG 
Thread-Topic: [netmod] [Netconf] LC on YANG Library (bis)
Thread-Index: AQHTm47nGQKkuQuITEyr+4DYs4MJdKOiyLPwgACNf4D//3uHkIAAj9IA//+InpA=
Date: Tue, 13 Feb 2018 21:25:46 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE82BD@sjceml521-mbs.china.huawei.com>
References:  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com> <20180213194821.cwbwwmy7bqhvkfsd@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com> <20180213202858.uvowmjtx2uk4snyz@elstar.local>
In-Reply-To: <20180213202858.uvowmjtx2uk4snyz@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.216.242]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Feb 2018 21:25:58 -0000

My proposal is to add this to the YANG data model.  I think this logically =
belongs to YANG library which is why I would like to see it there.  I also =
think it will be useful to many implementations.  All, probably not, but th=
ey have also survived without YANG library for a while:-) Of course, it is =
always possible to write another draft or do a bisbis. =20
Cheers
--- Alex

> -----Original Message-----
> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
> Sent: Tuesday, February 13, 2018 12:29 PM
> To: Alexander Clemm 
> Cc: Mahesh Jethanandani ; NETCONF WG
> ; NETMOD WG 
> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
>=20
> I must have missed your actionable proposal that is relevant for _all_ NE=
TCONF
> and RESTCONF implementations.
>=20
> YANG data models are extensible so lets use that.
>=20
> /js
>=20
> On Tue, Feb 13, 2018 at 07:58:37PM +0000, Alexander Clemm wrote:
> > Well, we need a general solution for that.  YANG-push is just one use c=
ase.
> There are other cases where there will be "metadata" (that does not perta=
in to
> instance data)  and capabilities that clients want to discover.  YANG lib=
rary (in
> itself providing "metadata" about what a server supports and is capable o=
f) is an
> excellent place to maintain this information.  It also provides the oppor=
tunity to
> be systemic about it, as opposed to requiring everyone to define their ow=
n little
> custom extensions.
> > --- Alex
> >
> > > -----Original Message-----
> > > From: Juergen Schoenwaelder
> > > [mailto:j.schoenwaelder@jacobs-university.de]
> > > Sent: Tuesday, February 13, 2018 11:48 AM
> > > To: Alexander Clemm 
> > > Cc: Mahesh Jethanandani ; NETCONF WG
> > > ; NETMOD WG 
> > > Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> > >
> > > Alexander,
> > >
> > > I disagree. This YANG Library is mandatory for all implementations;
> > > what you talk about seems to concern only implementations that
> > > support YANG push. Hence, this is an extension that should go in its =
own
> module.
> > >
> > > /js
> > >
> > > On Tue, Feb 13, 2018 at 07:38:31PM +0000, Alexander Clemm wrote:
> > > > Hi,
> > > >
> > > > I have taken a look at this document.
> > > >
> > > > My main comment is that one aspect that is missing, that I believe
> > > > should be
> > > added, concerns the inclusion of certain metadata about the modules.
> > > Specifically, in the context of YANG-Push we had a discussion about
> > > being able to mark nodes that are notifiable on change.  This is
> > > just one particular use case of a more general issue; in YANG-Push
> > > after much debate the conclusion was for now to simply make
> > > implementors aware of this issue and advise that a solution to this
> > > must be provided, with the clear understanding that eventually a stan=
dard
> solution should be defined.
> > > >
> > > > Since the goal of YANG-Library is to allow clients to find out
> > > > what is actually
> > > supported on a given server, this is the right place to keep this
> > > information.  One possible way to address this would be, for a given
> > > module, to maintain a list of "meta-info", with a key "meta-tag",
> > > and a list with references to the nodes to which the metadata
> > > applies.  In the case of notifiable-on-change, you would have a list
> > > with one entry "notifiable-on-change", and then the list with the nod=
e
> definitions to which this tag applies.
> > > >
> > > > Editorial nit:
> > > > 2nd paragraph Introduction: informaton --> information
> > > >
> > > > Thanks
> > > > --- Alex
> > > >
> > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of
> > > > Mahesh Jethanandani
> > > > Sent: Thursday, February 01, 2018 11:00 AM
> > > > To: NETCONF WG 
> > > > Cc: NETMOD WG 
> > > > Subject: [Netconf] LC on YANG Library (bis)
> > > >
> > > > WG,
> > > >
> > > > The authors of rfc7895bis have indicated that they believe the
> > > > document is
> > > ready for LC[1].
> > > >
> > > > This starts a two week LC on the
> > > > draft > > netconf-rfc7895bis-04>. The LC will end on February 15.
> > > >
> > > > Please send your comments on this thread. Reviews of the document,
> > > > and
> > > statement of support are particularly helpful to the authors. If you
> > > have concerns about the document, please state those too.
> > > >
> > > > Authors please indicate if you are aware of any IPR on the document=
.
> > > >
> > > > Thanks.
> > > >
> > > > [1]
> > > > https://www.ietf.org/mail-archive/web/netconf/current/msg13980.htm
> > > > l
> > > >
> > > > Mahesh & Kent
> > > >
> > >
> > > > _______________________________________________
> > > > 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 | German=
y
> > > Fax:   +49 421 200 3103         
>=20
> --
> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
> Fax:   +49 421 200 3103         


From nobody Tue Feb 13 13:42:44 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CBC5012D947 for ; Tue, 13 Feb 2018 13:42:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0Rdf2DwCBT8W for ; Tue, 13 Feb 2018 13:42:39 -0800 (PST)
Received: from mail-lf0-x235.google.com (mail-lf0-x235.google.com [IPv6:2a00:1450:4010:c07::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 4A05212D946 for ; Tue, 13 Feb 2018 13:42:39 -0800 (PST)
Received: by mail-lf0-x235.google.com with SMTP id t79so27009293lfe.3 for ; Tue, 13 Feb 2018 13:42:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=E4ou3fyfWBM2NbEkQrkeilyREv61HtC2BgTxaqotERY=; b=joBVEHMygm52Qs21aST+qSussnUHPJ5IoNEasKxFCNyWL0GhUNclkxUG+eeLU8oHvW 9sEeM9/AaKM6DahxBaJo8/V5E15otldEt9nkjlsIG3ruMUNXU8K6kSbhOI3TCMKPgtkj +Z6g+o5VeCApshn4hQN0KkLrwyjc+zaM5XjkzN+TkvHatoFzNRORQhvrhWlBDkwfYrG9 WIhSVeS3QSsV7R0qKEzjfu5J+/FpDZFbuxARAqBieT+3LenlTSzCeYEPFLBhlu3cmMX9 eh0lzXYuLtczz0VdGvxozdIHfYQ54FsMxkg6tPGGkIuYyjra9vd41Habxa6U78cQO16Z /zMQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=E4ou3fyfWBM2NbEkQrkeilyREv61HtC2BgTxaqotERY=; b=i/uy8SE/WDSqGgLd+OZtDUpTvxKQ6DbvkIpseKMbuAZmPkjELKIEzH7xJBs5ll83+n 8SyaVjMZo9tglMyzXCJ6hOr8hIihYzn4tWPp7sWzNWzXVl2YZeZVHF3ogmVKHNtFj0jS KkBhKBXpCj6L1X21YvE+dWqgcSaLjmPaFYrXMV3MA5ZTW/QnVfi+fhXLPds31gEtD/KG +2enIvZKnos/tiE1KUIW7COQTUjzf2934EpMWZnKH6yqdSamC4pF8roBVVSaxrZKw74F tI2LZMEnUKw93qlkZCp1YFqNY64w/MSwPAhGSNjrUDuqSF5OtaiYmIAKvL9Kml4V4L4b fOdw==
X-Gm-Message-State: APf1xPD/PUldpTR6XTB7Ptk8HZKU6ZT2waUV1iJdD8uoBstPIEO1j7DM YGXwYj6jVczM2jPNv4Q5i6MwxlhhLlZ/MHKxa89plQ==
X-Google-Smtp-Source: AH8x225+lyeTeU16Jz1Dp5VwGhgXLWbGK094qYzEBlMnu+REDTMUONtwlVxswA+ICwiOXQGBNO9t3Lu1OdiCm6w3lzM=
X-Received: by 10.46.83.4 with SMTP id h4mr1902146ljb.47.1518558157419; Tue, 13 Feb 2018 13:42:37 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Tue, 13 Feb 2018 13:42:36 -0800 (PST)
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE82BD@sjceml521-mbs.china.huawei.com>
References:  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com> <20180213194821.cwbwwmy7bqhvkfsd@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com> <20180213202858.uvowmjtx2uk4snyz@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE82BD@sjceml521-mbs.china.huawei.com>
From: Andy Bierman 
Date: Tue, 13 Feb 2018 13:42:36 -0800
Message-ID: 
To: Alexander Clemm 
Cc: Juergen Schoenwaelder , NETCONF WG , NETMOD WG 
Content-Type: multipart/alternative; boundary="94eb2c1cfa4a8b4ec305651edfc7"
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Feb 2018 21:42:43 -0000

--94eb2c1cfa4a8b4ec305651edfc7
Content-Type: text/plain; charset="UTF-8"

On Tue, Feb 13, 2018 at 1:25 PM, Alexander Clemm  wrote:

> My proposal is to add this to the YANG data model.  I think this logically
> belongs to YANG library which is why I would like to see it there.  I also
> think it will be useful to many implementations.  All, probably not, but
> they have also survived without YANG library for a while:-) Of course, it
> is always possible to write another draft or do a bisbis.
>

Or the IETF can learn about the augment-stmt and create additional objects
without
constantly rewriting the base modules.


Cheers
> --- Alex
>

Andy


>
> > -----Original Message-----
> > From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de
> ]
> > Sent: Tuesday, February 13, 2018 12:29 PM
> > To: Alexander Clemm 
> > Cc: Mahesh Jethanandani ; NETCONF WG
> > ; NETMOD WG 
> > Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> >
> > I must have missed your actionable proposal that is relevant for _all_
> NETCONF
> > and RESTCONF implementations.
> >
> > YANG data models are extensible so lets use that.
> >
> > /js
> >
> > On Tue, Feb 13, 2018 at 07:58:37PM +0000, Alexander Clemm wrote:
> > > Well, we need a general solution for that.  YANG-push is just one use
> case.
> > There are other cases where there will be "metadata" (that does not
> pertain to
> > instance data)  and capabilities that clients want to discover.  YANG
> library (in
> > itself providing "metadata" about what a server supports and is capable
> of) is an
> > excellent place to maintain this information.  It also provides the
> opportunity to
> > be systemic about it, as opposed to requiring everyone to define their
> own little
> > custom extensions.
> > > --- Alex
> > >
> > > > -----Original Message-----
> > > > From: Juergen Schoenwaelder
> > > > [mailto:j.schoenwaelder@jacobs-university.de]
> > > > Sent: Tuesday, February 13, 2018 11:48 AM
> > > > To: Alexander Clemm 
> > > > Cc: Mahesh Jethanandani ; NETCONF WG
> > > > ; NETMOD WG 
> > > > Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
> > > >
> > > > Alexander,
> > > >
> > > > I disagree. This YANG Library is mandatory for all implementations;
> > > > what you talk about seems to concern only implementations that
> > > > support YANG push. Hence, this is an extension that should go in its
> own
> > module.
> > > >
> > > > /js
> > > >
> > > > On Tue, Feb 13, 2018 at 07:38:31PM +0000, Alexander Clemm wrote:
> > > > > Hi,
> > > > >
> > > > > I have taken a look at this document.
> > > > >
> > > > > My main comment is that one aspect that is missing, that I believe
> > > > > should be
> > > > added, concerns the inclusion of certain metadata about the modules.
> > > > Specifically, in the context of YANG-Push we had a discussion about
> > > > being able to mark nodes that are notifiable on change.  This is
> > > > just one particular use case of a more general issue; in YANG-Push
> > > > after much debate the conclusion was for now to simply make
> > > > implementors aware of this issue and advise that a solution to this
> > > > must be provided, with the clear understanding that eventually a
> standard
> > solution should be defined.
> > > > >
> > > > > Since the goal of YANG-Library is to allow clients to find out
> > > > > what is actually
> > > > supported on a given server, this is the right place to keep this
> > > > information.  One possible way to address this would be, for a given
> > > > module, to maintain a list of "meta-info", with a key "meta-tag",
> > > > and a list with references to the nodes to which the metadata
> > > > applies.  In the case of notifiable-on-change, you would have a list
> > > > with one entry "notifiable-on-change", and then the list with the
> node
> > definitions to which this tag applies.
> > > > >
> > > > > Editorial nit:
> > > > > 2nd paragraph Introduction: informaton --> information
> > > > >
> > > > > Thanks
> > > > > --- Alex
> > > > >
> > > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of
> > > > > Mahesh Jethanandani
> > > > > Sent: Thursday, February 01, 2018 11:00 AM
> > > > > To: NETCONF WG 
> > > > > Cc: NETMOD WG 
> > > > > Subject: [Netconf] LC on YANG Library (bis)
> > > > >
> > > > > WG,
> > > > >
> > > > > The authors of rfc7895bis have indicated that they believe the
> > > > > document is
> > > > ready for LC[1].
> > > > >
> > > > > This starts a two week LC on the
> > > > > draft > > > netconf-rfc7895bis-04>. The LC will end on February 15.
> > > > >
> > > > > Please send your comments on this thread. Reviews of the document,
> > > > > and
> > > > statement of support are particularly helpful to the authors. If you
> > > > have concerns about the document, please state those too.
> > > > >
> > > > > Authors please indicate if you are aware of any IPR on the
> document.
> > > > >
> > > > > Thanks.
> > > > >
> > > > > [1]
> > > > > https://www.ietf.org/mail-archive/web/netconf/current/msg13980.htm
> > > > > l
> > > > >
> > > > > Mahesh & Kent
> > > > >
> > > >
> > > > > _______________________________________________
> > > > > 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         
> >
> > --
> > 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
>

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




On Tue, Feb 13, 2018 at 1:25 PM, Alexander Clemm <=
alexander.c=
lemm@huawei.com> wrote:
My =
proposal is to add this to the YANG data model.=C2=A0 I think this logicall=
y belongs to YANG library which is why I would like to see it there.=C2=A0 =
I also think it will be useful to many implementations.=C2=A0 All, probably=
 not, but they have also survived without YANG library for a while:-) Of co=
urse, it is always possible to write another draft or do a bisbis.

Or the IETF can learn about the augment-stmt an=
d create additional objects without
constantly rewriting the base=
 modules.



Cheers

--- Alex

Andy
=C2=A0



> -----Original Message-----

> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]

> Sent: Tuesday, February 13, 2018 12:29 PM

> To: Alexander Clemm <=
alexander.clemm@huawei.com>

> Cc: Mahesh Jethanandani <mjethanandani@gmail.com>; NETCONF WG

> <netconf@ietf.org>; NETM=
OD WG <netmod@ietf.org>

> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)

>

> I must have missed your actionable proposal that is relevant for _all_=
 NETCONF

> and RESTCONF implementations.

>

> YANG data models are extensible so lets use that.

>

> /js

>

> On Tue, Feb 13, 2018 at 07:58:37PM +0000, Alexander Clemm wrote:

> > Well, we need a general solution for that.=C2=A0 YANG-push is jus=
t one use case.

> There are other cases where there will be "metadata" (that d=
oes not pertain to

> instance data)=C2=A0 and capabilities that clients want to discover.=
=C2=A0 YANG library (in

> itself providing "metadata" about what a server supports and=
 is capable of) is an

> excellent place to maintain this information.=C2=A0 It also provides t=
he opportunity to

> be systemic about it, as opposed to requiring everyone to define their=
 own little

> custom extensions.

> > --- Alex

> >

> > > -----Original Message-----

> > > From: Juergen Schoenwaelder

> > > [mailto:j.schoenwaelder@jacobs-university.de]

> > > Sent: Tuesday, February 13, 2018 11:48 AM

> > > To: Alexander Clemm <alexander.clemm@huawei.com>

> > > Cc: Mahesh Jethanandani <mjethanandani@gmail.com>; NETCONF WG

> > > <netconf@ietf.org=
>; NETMOD WG <netmod@ietf.org&=
gt;

> > > Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)

> > >

> > > Alexander,

> > >

> > > I disagree. This YANG Library is mandatory for all implement=
ations;

> > > what you talk about seems to concern only implementations th=
at

> > > support YANG push. Hence, this is an extension that should g=
o in its own

> module.

> > >

> > > /js

> > >

> > > On Tue, Feb 13, 2018 at 07:38:31PM +0000, Alexander Clemm wr=
ote:

> > > > Hi,

> > > >

> > > > I have taken a look at this document.

> > > >

> > > > My main comment is that one aspect that is missing, tha=
t I believe

> > > > should be

> > > added, concerns the inclusion of certain metadata about the =
modules.

> > > Specifically, in the context of YANG-Push we had a discussio=
n about

> > > being able to mark nodes that are notifiable on change.=C2=
=A0 This is

> > > just one particular use case of a more general issue; in YAN=
G-Push

> > > after much debate the conclusion was for now to simply make<=
br>
> > > implementors aware of this issue and advise that a solution =
to this

> > > must be provided, with the clear understanding that eventual=
ly a standard

> solution should be defined.

> > > >

> > > > Since the goal of YANG-Library is to allow clients to f=
ind out

> > > > what is actually

> > > supported on a given server, this is the right place to keep=
 this

> > > information.=C2=A0 One possible way to address this would be=
, for a given

> > > module, to maintain a list of "meta-info", with a =
key "meta-tag",

> > > and a list with references to the nodes to which the metadat=
a

> > > applies.=C2=A0 In the case of notifiable-on-change, you woul=
d have a list

> > > with one entry "notifiable-on-change", and then th=
e list with the node

> definitions to which this tag applies.

> > > >

> > > > Editorial nit:

> > > > 2nd paragraph Introduction: informaton --> informati=
on

> > > >

> > > > Thanks

> > > > --- Alex

> > > >

> > > > From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of

> > > > Mahesh Jethanandani

> > > > Sent: Thursday, February 01, 2018 11:00 AM

> > > > To: NETCONF WG <=
netconf@ietf.org>

> > > > Cc: NETMOD WG <ne=
tmod@ietf.org>

> > > > Subject: [Netconf] LC on YANG Library (bis)

> > > >

> > > > WG,

> > > >

> > > > The authors of rfc7895bis have indicated that they beli=
eve the

> > > > document is

> > > ready for LC[1].

> > > >

> > > > This starts a two week LC on the

> > > > draft<https://tools.ietf.org/html=
/draft-ietf-

> > > netconf-rfc7895bis-04>. The LC will end on February 15.
> > > >

> > > > Please send your comments on this thread. Reviews of th=
e document,

> > > > and

> > > statement of support are particularly helpful to the authors=
. If you

> > > have concerns about the document, please state those too.
> > > >

> > > > Authors please indicate if you are aware of any IPR on =
the document.

> > > >

> > > > Thanks.

> > > >

> > > > [1]

> > > > https://www.ie=
tf.org/mail-archive/web/netconf/current/msg13980.htm

> > > > l

> > > >

> > > > Mahesh & Kent

> > > >

> > >

> > > > _______________________________________________
> > > > netmod mailing list

> > > > netmod@ietf.org<=
br>
> > > > https://www.ietf.org/mailman/li=
stinfo/netmod

> > >

> > >

> > > --

> > > 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=A0Cam=
pus Ring 1 | 28759 Bremen | Germany

> > > Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0=
 =C2=A0<https://www.jacobs-university.de/>

>

> --

> Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs U=
niversity 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<=
;https://www.jacobs-university.de/>



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--94eb2c1cfa4a8b4ec305651edfc7--


From nobody Tue Feb 13 14:31:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5514E12D95B; Tue, 13 Feb 2018 14:31:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DiWV_RHdiadO; Tue, 13 Feb 2018 14:31:01 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 AC98712D835; Tue, 13 Feb 2018 14:31:01 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1DMTEQW009520; Tue, 13 Feb 2018 14:31:01 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=QpdtEKlHwEHcoemozjCNiBycq/UrblmOhokG6q3Y0+A=; b=OgWyNlmv0IrgaEMaDTVR5q/N1j1NqRLOZ0FdQYe1cRpfzpBfp+lRhit5z57Nzw9rv3hd 7+46dcu2IbERVcHsUFkiZxIXUutxzp+OQI8bF6D2WxnLxC3E6WWio9VyumG0dwQEFpnP rPjsWXZTs36vxPhnVyo5eaURryU5zGTIBjXgtdpOTDLedi1Np2sW0NaMYmlbl5buX20k cddm8sGPWTz7+AQuZkU112/Hfl1CJCr+eizSEwcegNhVqe96+auK4eVgKbfk/MHXsevn u31a61hBxzQxMyx9dtF1rvDUj7os0AqSEXxcIBi+ODgbgtikTZOYqh1QgzWx8zTU5kj7 xg== 
Received: from nam01-bn3-obe.outbound.protection.outlook.com (mail-bn3nam01lp0183.outbound.protection.outlook.com [216.32.180.183]) by mx0a-00273201.pphosted.com with ESMTP id 2g48n081rq-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 13 Feb 2018 14:31:01 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3547.namprd05.prod.outlook.com (10.174.242.152) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Tue, 13 Feb 2018 22:30:59 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747%13]) with mapi id 15.20.0506.013; Tue, 13 Feb 2018 22:30:59 +0000
From: Kent Watsen 
To: "draft-ietf-netmod-acl-model@ietf.org" 
CC: "netmod@ietf.org" 
Thread-Topic: ACL draft issues found during shepherd writeup
Thread-Index: AQHTpRpSR0BIQpp1FUa5qmqsmhR9+Q==
Date: Tue, 13 Feb 2018 22:30:59 +0000
Message-ID: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.12]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3547; 7:Kzt0uqqFaYK+tQdYBdLtHKdQ+cfc6aIww/+p37vx3RKgqMFL5sWVjHPGXfFKThfDyEmcdLgnWOx2M2yiPohewpdX69tBVevDB10NzH8SPQtAO0OyWX+6/UVXkubjhYHRldRpVtQNiXSKiICJh4w2R61adsiKqjS04CmqZBFYyVEoOLolJKxcv86lwVWnhMeKBO9CUlEE11ZgOgy8nKjDZokSePSu0eeR+TY7Hb7U5C+88ovGlxISB64dQDIE6apR
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 35d1aa59-9ddb-433c-85c9-08d5733174b0
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3547; 
x-ms-traffictypediagnostic: DM5PR05MB3547:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162)(192374486261705)(788757137089); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(10201501046)(3231101)(944501161)(3002001)(93006095)(93001095)(6055026)(6041288)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123558120)(20161123562045)(6072148)(201708071742011); SRVR:DM5PR05MB3547; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3547; 
x-forefront-prvs: 0582641F53
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(346002)(39380400002)(366004)(376002)(377424004)(199004)(189003)(85644002)(82746002)(478600001)(6116002)(2906002)(8676002)(81166006)(8936002)(102836004)(81156014)(59450400001)(14454004)(7736002)(966005)(6506007)(186003)(26005)(86362001)(6486002)(6436002)(83716003)(3846002)(58126008)(97736004)(4326008)(305945005)(25786009)(450100002)(83506002)(575784001)(316002)(5640700003)(6916009)(5660300001)(2351001)(106356001)(105586002)(66066001)(3280700002)(53936002)(68736007)(6306002)(2501003)(3660700001)(6512007)(36756003)(33656002)(2900100001)(99286004)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3547; H:DM5PR05MB3484.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)
x-microsoft-antispam-message-info: /eWhJRskSRhqRTvvKCa5FVnk0oMY4DgLTygPxwBBfcoLTUGlF8lbfRWXgKXeMMyXrTGxgRfxQ1uAI6pGNHiLqw==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 35d1aa59-9ddb-433c-85c9-08d5733174b0
X-MS-Exchange-CrossTenant-originalarrivaltime: 13 Feb 2018 22:30:59.0329 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3547
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-13_11:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802130264
Archived-At: 
Subject: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 13 Feb 2018 22:31:04 -0000

W3NvcnJ5LCB3cm9uZyBXRywgbW92aW5nIG5ldGNvbmYgdG8gQkNDIV0NCg0KDQpBQ0wgQXV0aG9y
cywNCg0KQmVsb3cgYXJlIHNvbWUgaXNzdWVzIEkgZm91bmQgd2hpbGUgbG9va2luZyBhdCBkb2lu
ZyB0aGUgU2hlcGhlcmQNCndyaXRlLXVwIHRvZGF5LiAgUGxlYXNlIHRha2UgYSBsb29rLg0KDQpB
bHNvLCB3aXRoIHJlZ2FyZHMgdG8gdGhlIHJlcXVlc3QgZm9yIHRob3NlIGhhdmluZyBMYXN0IENh
bGwgY29tbWVudHMNCnRvIHBsZWFzZSB2ZXJpZnkgdGhhdCB0aGVpciBjb21tZW50cyB3ZXJlIGFk
ZHJlc3NlZCwgSSBvbmx5IHNhdyBvbmUNCnJlc3BvbnNlIGZyb20gS3Jpc3RpYW4sIGJ1dCBzaG91
bGQgd2UgYmUgZXhwZWN0aW5nIHJlc3Blb25zZXMgZnJvbQ0Kb3RoZXJzIHRvbywgcGVyaGFwcyBF
aW5hciBvciBFbGxpb3Q/DQoNCg0KMSBJRE5JVFMNCg0KICAtIHNvbWUgaXNzdWVzIGZvdW5kIGJ5
IGlkbml0cw0KICAtIHVzaW5nIGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX3Rvb2xzX2lkbml0c18mZD1Ed0lDQWcmYz1IQWtZ
dWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlF
UG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPTdCeDNoZ29mU0Z4dk5SVjdYejdGdWFKY0tL
ZnpFQjBzQkp6Tl9LT0N0U2cmcz1fNWYtbHhDb0pXMlRpZGNyaldfS2JEa2RQaGZ4TG9MNjdrbjFB
Mm9rZ3MwJmU9DQogIC0gd2l0aG91dCBzZWxlY3RpbmcgInZlcmJvc2Ugb3V0cHV0Ig0KDQoNCjEu
MQ0KDQogICoqIFRoZXJlIGFyZSA1IGluc3RhbmNlcyBvZiB0b28gbG9uZyBsaW5lcyBpbiB0aGUg
ZG9jdW1lbnQsIHRoZSBsb25nZXN0IG9uZQ0KICAgICBiZWluZyA1IGNoYXJhY3RlcnMgaW4gZXhj
ZXNzIG9mIDcyLg0KDQoNCiAgVGhpcyAiKioiIGlzIGJlaW5nIGZsYWdnZWQgYXMgYW4gImVycm9y
Ii4gIA0KICBJZG5pdHMgbGFiZWwsIG5vdCBtaW5lLiAgUGxlYXNlIGZpeC4NCg0KDQoxLjINCg0K
ICA9PSBUaGVyZSBhcmUgNyBpbnN0YW5jZXMgb2YgbGluZXMgd2l0aCBub24tUkZDNjg5MC1jb21w
bGlhbnQgSVB2NCBhZGRyZXNzZXMNCiAgICAgaW4gdGhlIGRvY3VtZW50LiAgSWYgdGhlc2UgYXJl
IGV4YW1wbGUgYWRkcmVzc2VzLCB0aGV5IHNob3VsZCBiZSBjaGFuZ2VkLg0KDQogIFRoaXMgaXMg
anVzdCBhIHdhcm5pbmcsIGJ1dCBnaXZlbiB0aGF0IHRoZXJlIGFyZSBzZXZlbiBvY2N1cnJlbmNl
cywgaXQNCiAgbWlnaHQgYmUgYSBnb29kIGlkZWEgdG8gZml4LiAgUGxlYXNlIHNlZSBTZWN0aW9u
IDMsIHBvaW50ICM2IGluIHRoaXMNCiAgZG9jdW1lbnQgZm9yIGRldGFpbHM6IGh0dHBzOi8vdXJs
ZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX2lk
LTJEaW5mb19jaGVja2xpc3QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUst
bmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZtPTdCeDNoZ29mU0Z4dk5SVjdYejdGdWFKY0tLZnpFQjBzQkp6Tl9LT0N0U2cmcz1BWW84
WkhQWTRTQUhNcWN5MXFWOXlyN0Jqb3hHeV9DOXpjSl9aYndYQlQ0JmU9Lg0KDQoNCjEuMw0KDQog
ICoqIFRoZSBkb2N1bWVudCBzZWVtcyB0byBsYWNrIGEgYm90aCBhIHJlZmVyZW5jZSB0byBSRkMg
MjExOSBhbmQgdGhlDQogICAgIHJlY29tbWVuZGVkIFJGQyAyMTE5IGJvaWxlcnBsYXRlLCBldmVu
IGlmIGl0IGFwcGVhcnMgdG8gdXNlIFJGQyAyMTE5DQogICAgIGtleXdvcmRzLiANCg0KICAgICBS
RkMgMjExOSBrZXl3b3JkLCBsaW5lIDc5NzogJy4uLnMtbGlzdC4gQSBkZXZpY2UgTUFZIHJlc3Ry
aWN0IHRoZSBsZW5nLi4uJw0KDQoNCiAgVGhlcmUgbmVlZHMgdG8gYmUgYSBzZWN0aW9uIHRoYXQg
bG9va3MgbGlrZSBSRkMgODE3NCwgcGFyYWdyYXBoIDExOg0KDQogICAgIFRoZSBrZXkgd29yZHMg
Ik1VU1QiLCAiTVVTVCBOT1QiLCAiUkVRVUlSRUQiLCAiU0hBTEwiLCAiU0hBTEwgTk9UIiwNCiAg
ICAgIlNIT1VMRCIsICJTSE9VTEQgTk9UIiwgIlJFQ09NTUVOREVEIiwgIk5PVCBSRUNPTU1FTkRF
RCIsICJNQVkiLA0KICAgICBhbmQgIk9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBi
ZSBpbnRlcnByZXRlZCBhcw0KICAgICBkZXNjcmliZWQgaW4gQkNQIDE0IFtSRkMyMTE5XSBbUkZD
ODE3NF0gd2hlbiwgYW5kIG9ubHkgd2hlbiwgdGhleQ0KICAgICBhcHBlYXIgaW4gYWxsIGNhcGl0
YWxzLCBhcyBzaG93biBoZXJlLg0KDQoNCjEuNC4NCg0KICAtLSBUaGUgZG9jdW1lbnQgZGF0ZSAo
RmVicnVhcnkgMiwgMjAxOCkgaXMgMTEgZGF5cyBpbiB0aGUgcGFzdC4gIElzIHRoaXMNCiAgICAg
aW50ZW50aW9uYWw/DQoNCiAgVGhpcyBpcyBmaW5lLCBpZ25vcmUgaXQuDQoNCjEuNQ0KDQogICoq
IE9ic29sZXRlIG5vcm1hdGl2ZSByZWZlcmVuY2U6IFJGQyAyNDYwDQoNCiAgVGhpcyBuZWVkcyB0
byBiZSBmaXhlZC4NCg0KMS42DQoNCiAgKiogRG93bnJlZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0
byBhbiBIaXN0b3JpYyBSRkM6IFJGQyAzNTQwDQoNCiAgSG1tbW0sIGFub3RoZXIgSElTVE9SSUMg
ZG9jdW1lbnQsIGJ1dCB0aGlzIHRpbWUgbm90IGR1ZSB0byBhbiBJRVNHDQogIGFjdGlvbi4gIFRo
ZSBxdWVzdGlvbiBpcyBob3cgaW1wb3J0YW50IHRoaXMgcmVmZXJlbmNlIGlzLCBpcyB0aGlzDQog
ICJucyIgYml0IChFQ04tbm9uY2UgY29uY2VhbG1lbnQgcHJvdGVjdGlvbikgY29tbW9ubHkgdXNl
ZCBpbiB0aGUgDQogIGluZHVzdHJ5PyAgIA0KDQoxLjcNCg0KICA9PSBPdXRkYXRlZCByZWZlcmVu
Y2U6IEEgbGF0ZXIgdmVyc2lvbiAoLTA2KSBleGlzdHMgb2YNCiAgICAgZHJhZnQtaWV0Zi1uZXRt
b2QteWFuZy10cmVlLWRpYWdyYW1zLTA0DQoNCiAgUGxlYXNlIHVwZGF0ZSB0byAtMDYNCg0KMS44
DQoNCiAgLS0gT2Jzb2xldGUgaW5mb3JtYXRpb25hbCByZWZlcmVuY2UgKGlzIHRoaXMgaW50ZW50
aW9uYWw/KTogUkZDIDUxMDENCiAgICAgKE9ic29sZXRlZCBieSBSRkMgNzAxMSkNCg0KICBQbGVh
c2UgdXBkYXRlIHRvIFJGQyA3MDExDQoNCg0KDQoyICBZQU5HIFZBTElEQVRJT04NCg0KMi4xIE5v
cm1hdGl2ZSBNb2R1bGVzDQoNCiAgQWxsIG9mIHRoZSBmb2xsb3dpbmcgcGFzc2VkOg0KDQogICAg
cHlhbmcgLS1pZXRmIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdFxAMjAxOC0wMi0wMi55YW5nIA0K
ICAgIHB5YW5nIC0taWV0ZiBpZXRmLXBhY2tldC1maWVsZHNcQDIwMTgtMDItMDIueWFuZyANCiAg
ICBweWFuZyAtLWlldGYgaWV0Zi1ldGhlcnR5cGVzXEAyMDE4LTAyLTAyLnlhbmcNCg0KICAgIHlh
bmdsaW50IC1zIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdFxAMjAxOC0wMi0wMi55YW5nIA0KICAg
IHlhbmdsaW50IC1zIGlldGYtcGFja2V0LWZpZWxkc1xAMjAxOC0wMi0wMi55YW5nIA0KICAgIHlh
bmdsaW50IC1zIGlldGYtZXRoZXJ0eXBlc1xAMjAxOC0wMi0wMi55YW5nIA0KDQoyLjIgRXhhbXBs
ZSBNb2R1bGUNCg0KICBFeGFtcGxlIG1vZHVsZSBwYXNzZWQgYHlhbmdsaW50IC1zYCwgYnV0IG5v
dCBgcHlhbmcgLS1saW50YDoNCg0KICAgIHlhbmdsaW50IC1zIGV4YW1wbGUtbmV3Y28tYWNsLnlh
bmcNCiAgICBweWFuZyAtLWxpbnQgZXhhbXBsZS1uZXdjby1hY2wueWFuZyANCg0KICAgIGV4YW1w
bGUtbmV3Y28tYWNsLnlhbmc6Nzg6IGVycm9yOiBrZXl3b3JkICJkZXNjcmlwdGlvbiIgbm90IGlu
DQogICAgY2Fub25pY2FsIG9yZGVyLCBleHBlY3RlZCAidHlwZSIsIChTZWUgUkZDIDYwMjAsIFNl
Y3Rpb24gMTIpDQoNCiAgICBleGFtcGxlLW5ld2NvLWFjbC55YW5nOjc5OiBlcnJvcjoga2V5d29y
ZCAidHlwZSIgbm90IGluIA0KICAgIGNhbm9uaWNhbCBvcmRlciwgKFNlZSBSRkMgNjAyMCwgU2Vj
dGlvbiAxMikNCg0KICAgIGV4YW1wbGUtbmV3Y28tYWNsLnlhbmc6ODI6IGVycm9yOiBrZXl3b3Jk
ICJkZWZhdWx0IiBub3QgaW4gDQogICAgY2Fub25pY2FsIG9yZGVyLCAoU2VlIFJGQyA2MDIwLCBT
ZWN0aW9uIDEyKQ0KDQogIFBsZWFzZSBmaXguDQoNCg0KMi4zIFhNTCBFeGFtcGxlcyBmcm9tIFNl
Y3Rpb24gNC4zDQoNCiAgeWFuZ2xpbnQgZGlkbid0IGZpbmQgYW55IGlzc3VlczoNCg0KICAgIHlh
bmdsaW50IGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdFxAMjAxOC0wMi0wMi55YW5nIGV4LTQuMy54
bWwgDQoNCg0KMi40IEV4YW1wbGVzIGZyb20gU2VjdGlvbiA0LjQNCg0KICBJIGhhZCB0byBzdGl0
Y2ggdGhlc2UgaW50byB0aGUgNC4zIGV4YW1wbGUuICBJdCBmb3VuZCBvbmUgaXNzdWUsIGEgdHlw
bw0KICBpbiB0aGUgbGFzdCBjbG9zaW5nIHRhZyBpbiB0aGUgZmlyc3QgZXhhbXBsZSBpbiB0aGlz
IHNlY3Rpb246DQoNCiAgICB5YW5nbGludCBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3RcQDIwMTgt
MDItMDIueWFuZyBleC00LjQrKy54bWwgDQogICAgZXJyIDogSW52YWxpZCAobWl4ZWQgbmFtZXMp
IG9wZW5pbmcgKHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yKSBhbmQgY2xvc2luZyAodGNw
KSBlbGVtZW50IHRhZ3MuICgvZGF0YS9hY2Nlc3MtbGlzdHMvYWNsL2FjZXMvYWNlL21hdGNoZXMv
bDQvdGNwL3NvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yL3NvdXJjZS1wb3J0LXJhbmdlLW9y
LW9wZXJhdG9yKQ0KDQogIFBsZWFzZSBmaXguDQoNCg0KICBQUzogQW5kIHRoaXMgaXMgbm90IGEg
c2hlcGhlcmQgZGlyZWN0aXZlLCBidXQgSSBmb3VuZCB0aGUgd2hvbGUgDQogICAgICAic291cmNl
LXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IiIHN5bnRheCBjbHVtc3kuICBJJ20gc3VycHJpc2VkDQog
ICAgICBpdCBkaWRuJ3QgbG9vayBzb21ldGhpbmcgbGlrZToNCg0KICAgICAgICAgIE9MRA0KICAg
ICAgICAgICAgICAgIDxzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcj4NCiAgICAgICAgICAg
ICAgICAgICA8cG9ydC1yYW5nZS1vci1vcGVyYXRvcj4NCiAgICAgICAgICAgICAgICAgICAgIDxy
YW5nZT4NCiAgICAgICAgICAgICAgICAgICAgICAgPGxvd2VyLXBvcnQ+MTYzODQ8L2xvd2VyLXBv
cnQ+DQogICAgICAgICAgICAgICAgICAgICAgIDx1cHBlci1wb3J0PjY1NTM1PC91cHBlci1wb3J0
Pg0KICAgICAgICAgICAgICAgICAgICAgPC9yYW5nZT4NCiAgICAgICAgICAgICAgICAgICA8L3Bv
cnQtcmFuZ2Utb3Itb3BlcmF0b3I+DQogICAgICAgICAgICAgICAgPC9zb3VyY2UtcG9ydC1yYW5n
ZS1vci1vcGVyYXRvcj4NCg0KICAgICAgICAgICAgICAgIDxzb3VyY2UtcG9ydC1yYW5nZS1vci1v
cGVyYXRvcj4NCiAgICAgICAgICAgICAgICAgIDxwb3J0LXJhbmdlLW9yLW9wZXJhdG9yPg0KICAg
ICAgICAgICAgICAgICAgICA8b3BlcmF0b3I+DQogICAgICAgICAgICAgICAgICAgICAgPG9wZXJh
dG9yPmVxPC9vcGVyYXRvcj4NCiAgICAgICAgICAgICAgICAgICAgICA8cG9ydD4yMTwvcG9ydD4N
CiAgICAgICAgICAgICAgICAgICAgPC9vcGVyYXRvcj4NCiAgICAgICAgICAgICAgICAgIDwvcG9y
dC1yYW5nZS1vci1vcGVyYXRvcj4NCiAgICAgICAgICAgICAgICA8L3NvdXJjZS1wb3J0LXJhbmdl
LW9yLW9wZXJhdG9yPg0KDQogICAgICAgICAgTkVXDQoNCiAgICAgICAgICAgICAgICA8c291cmNl
LXBvcnQ+DQogICAgICAgICAgICAgICAgICA8cmFuZ2U+DQogICAgICAgICAgICAgICAgICAgIDxs
b3dlcj4xNjM4NDwvbG93ZXI+DQogICAgICAgICAgICAgICAgICAgIDx1cHBlcj42NTUzNTwvdXBw
ZXI+DQogICAgICAgICAgICAgICAgICA8L3JhbmdlPg0KICAgICAgICAgICAgICAgIDwvc291cmNl
LXBvcnQ+DQoNCiAgICAgICAgICAgICAgICA8c291cmNlLXBvcnQ+DQogICAgICAgICAgICAgICAg
ICA8b3BlcmF0b3I+DQogICAgICAgICAgICAgICAgICAgIDxvcGVyYXRvcj5lcTwvb3BlcmF0b3I+
DQogICAgICAgICAgICAgICAgICAgIDxwb3J0PjIxPC9wb3J0Pg0KICAgICAgICAgICAgICAgICAg
PC9vcGVyYXRvcj4NCiAgICAgICAgICAgICAgICA8L3NvdXJjZS1wb3J0Pg0KDQoNCg0KMyBLZXkg
RHJhZnQgU2VjdGlvbnMNCg0KDQozLjEgQWJzdHJhY3QNCg0KICBGaXJzdCwgSSdtIHVuc3VyZSBp
ZiB0aGF0IGZpcnN0ICJzZW50ZW5jZSIgaXMgcHJvcGVybHkgd29yZGVkLCBidXQgSQ0KICBkZWZp
bml0ZWx5IHRoaW5rIHRoYXQgaXQgaXMgYSBiaXQgdG9vIG11Y2ggb24gdGhlIHRlcnNlIHNpZGUu
ICBDYW4geW91DQogIGVtYmVsbGlzaCBpdCBhIGxpdHRsZT8NCg0KICBTZWNvbmQsIGFtIEkgcmVh
ZGluZyBpdCBjb3JyZWN0PyAtIGlzIHRoZSAiRWRpdG9yaWFsIE5vdGUiIGluIHRoZQ0KICBBYnN0
cmFjdCBzZWN0aW9uLiAgSSBzdHJvbmdseSBhZHZpc2UgbW92aW5nIA0KDQozLjIgUkZDIEVkaXRv
ciBOb3RlDQoNCiAgVGhlcmUgaXMgbm8gcmVxdWVzdCB0byByZXBsYWNlICJJLUQuaWV0Zi1uZXRt
b2QteWFuZy10cmVlLWRpYWdyYW1zIiB3aXRoDQogIHRoZSBmaW5hbCBSRkMgYXNzaWdubWVudC4N
Cg0KICBZb3UgbWlnaHQgd2FudCB0byBhZGQgd2hhdCB0aGUgY3VycmVudCBkYXRlIHZhbHVlIHVz
ZWQgaW4gdGhlIGRyYWZ0IGlzDQogIChpLmUuLCAyMDE4LTAyLTAyKS4gICBQUzogbXkgZHJhZnQg
YnVpbGQgdG9vbHMsIHdoaWNoIEkgdGhpbmsgeW91J3JlDQogIHVzaW5nLCBzaG91bGQgc2V0IHRo
ZSB2YWx1ZSBmb3IgeW91IGF1dG9tYXRpY2FsbHkgaWYgeW91IHB1dCBZWVlZLU1NLUREDQogIGlu
dG8gdGhlIHRleHQuDQoNCg0KMy4zIEltcG9ydCBzdGF0ZW1lbnRzIG1pc3NpbmcgcmVmZXJlbmNl
cw0KDQogIEFsbCBpbXBvcnQgc3RhdGVtZW50cyBpbiBhbGwgbW9kdWxlcyBhcmUgbWlzc2luZyBy
ZWZlcmVuY2Ugc3RhdGVtZW50cw0KICAgICAtIHdoeSB3YXNuJ3QgdGhpcyBjYXVnaHQgYnkgdGhl
IHRvb2xzPyENCg0KICBQbGVhc2Ugc2VlIHJmYzYwODdiaXMgU2VjdGlvbiA0LjcuICANCg0KDQoz
LjQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMNCg0KICBQbGVhc2UgcmVmb3JtYXQgdGhlIGxhc3Qg
cGFyYWdyYXBoIHNvIHRoZSAiYWNlcyIgcGF0aCBpcyBtb3JlIHByb25vdW5jZWQuDQogIFBlcmhh
cHMgdXNlIGhhbmdUZXh0Lg0KDQoNCjMuNSBJQU5BIENvbnNpZGVyYXRpb25zDQoNCiAgVGhpcyBz
ZWN0aW9uIGlzIGhhcmQgdG8gcmVhZC4NCg0KICBDb25zaWRlcmF0aW9uIGJyZWFraW5nIHVwIHRo
ZSAiWE1MIiBhbmQgdGhlICJZQU5HIE1vZHVsZSBOYW1lcyIgcmVnaXN0cnkNCiAgcmVxdWVzdHMg
aW50byB0d28gc3Vic2VjdGlvbnMuDQoNCiAgQ29uc2lkZXIgbWFraW5nIHRoZSByZWdpc3RyYXRp
b24gZW50cnkgcmVxdWVzdHMgdGhlbXNlbHZlcyBhcnR3b3JrIHNvDQogIHRoZXkncmUgbGluZS1z
cGFjZWQgYW5kIGluZGVudGVkIGFzIHN1Y2guDQogDQogIFRoZSBmaXJzdCBwYXJhZ3JhcGggb2Yg
dGhlICJYTUwiIHJlZ2lzdHJ5IHJlcXVlc3Qgc2F5cyAiYSBVUkkiLCBidXQgaXQgDQogIHNob3Vs
ZCBiZSAidHdvIFVSSXMiDQoNCiAgVGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgIllBTkcgTW9k
dWxlIE5hbWVzIiByZWdpc3RyeSByZXF1ZXN0IHNheXMgDQogICJhIFlBTkcgbW9kdWxlIiwgYnV0
IGl0IHNob3VsZCBiZSAidHdvIFlBTkcgbW9kdWxlcyINCg0KDQozLjYgUmVmZXJlbmNlcw0KDQog
IEkgaGF2ZW4ndCBjaGVja2VkIHlldCwgYnV0IHBsZWFzZSB2ZXJpZnkgdGhhdCBhbGwgdGhlIHJl
ZmVyZW5jZXMgYXJlDQogIHByb3Blcmx5IHNvcnRlZCBhcyB0byBiZWluZyBOb3JtYXRpdmUgb3Ig
SW5mb3JtYXRpdmUuDQoNCg0KMy43IEFwcGVuZGl4IEENCg0KICBJdCB0b29rIG1lIGF3aGlsZSB0
byBmaWd1cmUgb3V0IHdoYXQgSSB3YXMgbG9va2luZyBhdC4gIFRoZSB0cmVlLWRpYWdyYW0NCiAg
aXMgcG9vcmx5IGluZGVudGVkIGFuZCB0aGVyZSBpcyBubyB0ZXh0IHByZWNlZGluZyB0aGUgZXhh
bXBsZSBtb2R1bGUuICANCg0KICBJIHJlY29tbWVuZCB5b3UgZm9sZCB0aGUgbGluZXMgb2YgeW91
ciB0cmVlIGRpYWdyYW0gYXQgYSBjZXJ0YWluIGNvbHVtbg0KICB3aGlsc3QgYWRkaW5nIGEgJ1wn
IGNoYXJhY3Rlci4gIEkndmUgc2luY2UgYWRkZWQgdGhpcyBhYmlsaXR5IHRvIG15IGRyYWZ0DQog
IGJ1aWxkIHRvb2xzLCBsZXQgbWUga25vdyBpZiBpbnRlcmVzdGVkIGluIGFuIHVwZGF0ZS4gIFlv
dSBtaWdodCBhbHNvIHdhbnQNCiAgdG8gbG9vayBhdCBkcmFmdC13dS1uZXRtb2QteWFuZy14bWwt
ZG9jLWNvbnZlbnRpb25zLg0KDQogIEFsc28sIHBsZWFzZSBmaXggdGhlIGV4YW1wbGUgbW9kdWxl
J3MgbmFtZXNwYWNlIHBlciB0aGUgZW5kIG9mIA0KICByZmM2MDg3YmlzIFNlY3Rpb24gNC45Lg0K
DQoNCg0KVGhhbmtzLA0KS2VudA0KDQoNCg0KDQpfX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fXw0KTmV0Y29uZiBtYWlsaW5nIGxpc3QNCk5ldGNvbmZAaWV0Zi5v
cmcNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0Y29uZiZkPUR3SUNBZyZjPUhBa1l1aDYz
cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I
N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09N0J4M2hnb2ZTRnh2TlJWN1h6N0Z1YUpjS0tmekVC
MHNCSnpOX0tPQ3RTZyZzPVhrbkxxZ0F1M1o5dDFNRTZGTy1fbVpZMm9DTjYxODY3VkIwdWJMZWl2
M1EmZT0NCg0KDQo=


From nobody Wed Feb 14 02:10:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 39E3512783A; Wed, 14 Feb 2018 02:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id saHSSGP73VuB; Wed, 14 Feb 2018 02:10:46 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CD4E3126CF9; Wed, 14 Feb 2018 02:10:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=6811; q=dns/txt; s=iport; t=1518603046; x=1519812646; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=DZtBPzJZhNI/6fkVNHD1rm8FXo0SGdKotpCbBvWi1RE=; b=Rv66bkiOay/7kQ6a84bjhDc2yfM3o++0ChYgCaIHYvRB1sVbD2FougHE RoBP2dbNCi61kty/zLA6qef13CbvcZvJUvqPrSLZXXR6akXAkQw0OnhRH D+ugffwQGWq+Gcx0XuabpfZYzqu9qlhja3otdGdU5gk/lfW1xprwa+n5A 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAJCoRa/xbLJq1ZAxkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGEOHAog2WLGI8PgReHf5BbChgLhElPAoNHFQECAQEBAQEBAms?= =?us-ascii?q?ohSMBAQEEAQEhBAsBBTYLDAICCxABBAEBAQICIwMCAhsGBh8JCAYNBgIBAReKA?= =?us-ascii?q?gMVELAHgW06hQGCQA2BMoITAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAUFgQqDcoN?= =?us-ascii?q?sghGCTzaCa0QBAQECgU4BAQg3JoJQgmUFo3o1CYggiFqFC4IfhiqDc4gJjgJIg?= =?us-ascii?q?TaIGYE8NSOBUDMaCBsVPYJGhHdBNwGLJ4I+AQEB?=
X-IronPort-AV: E=Sophos;i="5.46,511,1511827200";  d="scan'208";a="2063126"
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; 14 Feb 2018 10:10:43 +0000
Received: from [10.63.23.94] (dhcp-ensft1-uk-vla370-10-63-23-94.cisco.com [10.63.23.94]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1EAAh2H003179; Wed, 14 Feb 2018 10:10:43 GMT
To: Alexander Clemm 
Cc: NETCONF WG , NETMOD WG 
References:  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com> <20180213194821.cwbwwmy7bqhvkfsd@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com> <20180213202858.uvowmjtx2uk4snyz@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE82BD@sjceml521-mbs.china.huawei.com>
From: Robert Wilton 
Message-ID: 
Date: Wed, 14 Feb 2018 10:10:43 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE82BD@sjceml521-mbs.china.huawei.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Feb 2018 10:10:48 -0000

Hi Alex,

I see no real advantages to putting this directly in YANG library bis, 
but I think that augmenting the YANG library bis structure is just fine 
(in the same way that the latest version of schema mount has proposed to 
do).

Generally, I think that it is good that NETCONF/YANG is built up of 
fairly loosely coupled components.  E.g. implementations can choose 
which subset of features are required for their particular circumstances 
(e.g. protocol, encoding, schema mount, YANG push, with-defaults, etc).  
If over time it becomes clear that it is critical for good interop that 
particular features must always be supported then we can define NETCONF 
2.0 or 3.0 that mandates that a particular set of technologies must be 
implemented to meet the standard.

The added bonus of having these components loosely coupled is that they 
can be improved and refined independently, potentially allowing IETF to 
move a bit quicker advancing the technologies.

Finally, even if there is common meta-data structure that is shared by 
multiple features, that still doesn't mean that it has to go in the base 
YANG library spec, that can still just be shared common extension.

Thanks,
Rob


On 13/02/2018 21:25, Alexander Clemm wrote:
> My proposal is to add this to the YANG data model.  I think this logically belongs to YANG library which is why I would like to see it there.  I also think it will be useful to many implementations.  All, probably not, but they have also survived without YANG library for a while:-) Of course, it is always possible to write another draft or do a bisbis.
> Cheers
> --- Alex
>
>> -----Original Message-----
>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.de]
>> Sent: Tuesday, February 13, 2018 12:29 PM
>> To: Alexander Clemm 
>> Cc: Mahesh Jethanandani ; NETCONF WG
>> ; NETMOD WG 
>> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
>>
>> I must have missed your actionable proposal that is relevant for _all_ NETCONF
>> and RESTCONF implementations.
>>
>> YANG data models are extensible so lets use that.
>>
>> /js
>>
>> On Tue, Feb 13, 2018 at 07:58:37PM +0000, Alexander Clemm wrote:
>>> Well, we need a general solution for that.  YANG-push is just one use case.
>> There are other cases where there will be "metadata" (that does not pertain to
>> instance data)  and capabilities that clients want to discover.  YANG library (in
>> itself providing "metadata" about what a server supports and is capable of) is an
>> excellent place to maintain this information.  It also provides the opportunity to
>> be systemic about it, as opposed to requiring everyone to define their own little
>> custom extensions.
>>> --- Alex
>>>
>>>> -----Original Message-----
>>>> From: Juergen Schoenwaelder
>>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>>> Sent: Tuesday, February 13, 2018 11:48 AM
>>>> To: Alexander Clemm 
>>>> Cc: Mahesh Jethanandani ; NETCONF WG
>>>> ; NETMOD WG 
>>>> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
>>>>
>>>> Alexander,
>>>>
>>>> I disagree. This YANG Library is mandatory for all implementations;
>>>> what you talk about seems to concern only implementations that
>>>> support YANG push. Hence, this is an extension that should go in its own
>> module.
>>>> /js
>>>>
>>>> On Tue, Feb 13, 2018 at 07:38:31PM +0000, Alexander Clemm wrote:
>>>>> Hi,
>>>>>
>>>>> I have taken a look at this document.
>>>>>
>>>>> My main comment is that one aspect that is missing, that I believe
>>>>> should be
>>>> added, concerns the inclusion of certain metadata about the modules.
>>>> Specifically, in the context of YANG-Push we had a discussion about
>>>> being able to mark nodes that are notifiable on change.  This is
>>>> just one particular use case of a more general issue; in YANG-Push
>>>> after much debate the conclusion was for now to simply make
>>>> implementors aware of this issue and advise that a solution to this
>>>> must be provided, with the clear understanding that eventually a standard
>> solution should be defined.
>>>>> Since the goal of YANG-Library is to allow clients to find out
>>>>> what is actually
>>>> supported on a given server, this is the right place to keep this
>>>> information.  One possible way to address this would be, for a given
>>>> module, to maintain a list of "meta-info", with a key "meta-tag",
>>>> and a list with references to the nodes to which the metadata
>>>> applies.  In the case of notifiable-on-change, you would have a list
>>>> with one entry "notifiable-on-change", and then the list with the node
>> definitions to which this tag applies.
>>>>> Editorial nit:
>>>>> 2nd paragraph Introduction: informaton --> information
>>>>>
>>>>> Thanks
>>>>> --- Alex
>>>>>
>>>>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of
>>>>> Mahesh Jethanandani
>>>>> Sent: Thursday, February 01, 2018 11:00 AM
>>>>> To: NETCONF WG 
>>>>> Cc: NETMOD WG 
>>>>> Subject: [Netconf] LC on YANG Library (bis)
>>>>>
>>>>> WG,
>>>>>
>>>>> The authors of rfc7895bis have indicated that they believe the
>>>>> document is
>>>> ready for LC[1].
>>>>> This starts a two week LC on the
>>>>> draft>>> netconf-rfc7895bis-04>. The LC will end on February 15.
>>>>> Please send your comments on this thread. Reviews of the document,
>>>>> and
>>>> statement of support are particularly helpful to the authors. If you
>>>> have concerns about the document, please state those too.
>>>>> Authors please indicate if you are aware of any IPR on the document.
>>>>>
>>>>> Thanks.
>>>>>
>>>>> [1]
>>>>> https://www.ietf.org/mail-archive/web/netconf/current/msg13980.htm
>>>>> l
>>>>>
>>>>> Mahesh & Kent
>>>>>
>>>>> _______________________________________________
>>>>> 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         
>> --
>> Juergen Schoenwaelder           Jacobs University Bremen gGmbH
>> Phone: +49 421 200 3587         Campus Ring 1 | 28759 Bremen | Germany
>> Fax:   +49 421 200 3103         
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
> .
>


From nobody Wed Feb 14 04:50:36 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9779124234; Wed, 14 Feb 2018 04:50:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.921
X-Spam-Level: 
X-Spam-Status: No, score=-1.921 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4xNZgRCzqspQ; Wed, 14 Feb 2018 04:50:32 -0800 (PST)
Received: from EUR02-AM5-obe.outbound.protection.outlook.com (mail-eopbgr00129.outbound.protection.outlook.com [40.107.0.129]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1674D127369; Wed, 14 Feb 2018 04:50:31 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=hG81T45WOA18w7nHYzOR3zd+7uDugI7zFj7Utl+z9P0=; b=TQiiQ5jrQyNGP74iGrtSrZAZGNyYUh5IpEO9D6ApNYOmgdpW+C3U6utsT6JsVg+wNUY7qW2JrvCkVDvQRpdiNJTbHQuGzGCdJFJGI54HwqUMfUvj12ioIlfM1Y/w2L1asivhZATlM0qhcdB26F/UgtXIL+8QNK9cuKcGqtNBxv4=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.176.21.219) by VI1PR0701MB3008.eurprd07.prod.outlook.com (2603:10a6:800:87::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P256) id 15.20.506.7; Wed, 14 Feb 2018 12:50:29 +0000
Message-ID: <02d601d3a592$2145b0e0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: 
Cc: "NETMOD Working Group" 
References: <017b01d3a039$1d4c5c40$4001a8c0@gateway.2wire.net> <20180208141113.GA24140@rfc-editor.org>
Date: Wed, 14 Feb 2018 12:48:11 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.176.21.219]
X-ClientProxiedBy: CWXP265CA0028.GBRP265.PROD.OUTLOOK.COM (2603:10a6:400:2d::16) To VI1PR0701MB3008.eurprd07.prod.outlook.com (2603:10a6:800:87::22)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 2f2e526c-1d5c-4639-8dfe-08d573a9874b
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(5600026)(4604075)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(2017052603307)(7193020); SRVR:VI1PR0701MB3008; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 3:PdUGcWzE/lynIJQov+hDETqGvlaLJEPb3shWLbpiSF8JKiV4X4mElbXn2Vh+aCH8jLoYT2NkMSU39bP60dEWlTLqNRK1bm5vsbhs9NmFEMn21RKemNVqdtLGMqEbvR4dDlDQfidJtNlC9d3q0ztnDeJ1f0KDcenB7R/YarTmv16fAERARvPBm3aDTNdE/JZ3rFMjfCrdaIlmAZjlknULKH6guNR2KvcCHjaQ+WP3ZSXUk4/OFBE+nGhhfwel5kGA; 25:RlpNnXSRZm4GECkzoUxbWfAMSpNoMuNgXDZfQevYElRqwJtaiEcUGDH5EY9UVVu6W9/qQXjIcFLfb3cDDq6msgimOSZiKlEu20k2LyhRtVoy/ZQ1GvKvosbm+7SgYv43cJiZX/vTHQjRH4rOcpyE50xY28J6nTSxVo2ZLUjzBQkBySB6RG+F1sV91a0xNamCs1E5eE0wiFR9Giyc9XQNsT0+k7rkGeVMCKavdGgq14zHFdSg1T3GWcx891PWbbyIiy2aEY7lb5FeeqBT7rhtHQh6aeRliTJtGOdh3Koe27opRqG0nl0qGFO++2a4uC1/W8OhFEqZSoUKmaja6KmBaA==; 31:UkgVV+iybKaRl1PrqE1jsBTqa/2lRC+eBZaVwTv4zuR8cXsI6tlDPEJ7FFVqpHHtXdOZeMy4McHAJjDvX5PJBOTY18k4+JCwHAJtEXHxAo1hmbbS+YYPs7VQlh8QLslwHVD+yRGgb0vxBALR9hee0UIbdf+zJV56Jfal43sXeSyPT15Xxvr6uEuw0jiIoJMo6jVLOYcT1AhRFwT9uh/fLvu1vOmdCnQkWnJHFH3o+8w=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3008:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(158342451672863);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(3231101)(2400082)(944501161)(93006095)(93001095)(10201501046)(6055026)(61426038)(61427038)(6041288)(20161123562045)(20161123560045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:VI1PR0701MB3008; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3008; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 4:YwPlM1JbcIYZ6kYDy/TB4ZEvQclrfF5nQpXSd2I9xEBaPU0Mdq47QRPhMwU3iOgLBaBZN9f9yprv4fEuHKFe7sd2VpgSnfkdEfRGnfHHouzz0u+s+hCHELc6wDmcOWQJoZ0YwdPNdTQbJtzB3Zv/pZPDUeg76V+/pq8wBMH2WsX+BRhlkxoaCkRQbAZFFcmuJFZreOzJldU5fzznK9i56C/uUwSkJCUf28A+kERIZ4a4MhsY8Ir+mWTWiRNr9An0YvkLhl336d2Z7gqL8o4n9BA6U/DI9LN1+c83tbqtFZ0u04jMJQYonZMppCafSEGH
X-Forefront-PRVS: 0583A86C08
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(376002)(39860400002)(396003)(346002)(39380400002)(366004)(189003)(199004)(16526019)(61296003)(6916009)(44716002)(106356001)(1556002)(84392002)(23756003)(6496006)(47776003)(5660300001)(62236002)(26005)(316002)(6666003)(4720700003)(2351001)(478600001)(386003)(14496001)(76176011)(81816011)(33896004)(25786009)(81156014)(230700001)(86362001)(2906002)(50226002)(8676002)(81686011)(81166006)(52116002)(53936002)(9686003)(8936002)(305945005)(44736005)(6486002)(450100002)(186003)(66066001)(3846002)(50466002)(6116002)(68736007)(7736002)(4326008)(105586002)(97736004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3008; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1; VI1PR0701MB3008; 23:eNgpuUQVRbK1oB665Xb1GX8dfWmgagOhw2YxM?= =?iso-8859-1?Q?8SMsARr0Tu+frJihmySABsllgnls5RI9fHcPnVubSEyZ8+mnyoL/D7b087?= =?iso-8859-1?Q?OY8Whk5oWf6R8kZuVyRcyW3gLxknTjGo++ZiOskn/L/RJHVqIHKnU0c5VL?= =?iso-8859-1?Q?S3yk9M8hmbbcgGEso+8AbGoCXmXXQRZyutCJ34vP9Wu/L4Bv+ymZA6yk9N?= =?iso-8859-1?Q?nU1VVsI6uKqNikxROwr/oxdRgroq4fpJKqnDf/j47TpbLB7pjhtzJRlZhx?= =?iso-8859-1?Q?OvztEpBTtwFo0pJ+Ul8PX7Xo3vnTh/a+wQpCRZ6tD3gdxwUrkzZtvUvC4G?= =?iso-8859-1?Q?k9dz2ZbuTa0EsjHvsgUg5UZ+ACCt1LkosXj8LUAV8bhb2C/0FABeL5znkF?= =?iso-8859-1?Q?Nc2nM6Gqk2Hmtnoj+liJa5akISvD4DQPFTaQabN5p/Deokl3HjnARPohFM?= =?iso-8859-1?Q?tQWTU/RuuN5yk1rxEFfTb1ALxdRYrxba8gv0di5t/fQU1/obnnonRWWql4?= =?iso-8859-1?Q?bDLvEh5wWEuYGXfbgMGayCaYUgr6zPmuBoU7GJmS6r3XF8SxYELpvxZnxP?= =?iso-8859-1?Q?gXzEg0rYDHIzMl7QdUdp2dOiVPkPSyh63je2DMxgqrwB3ZV7EoZPTCfwz1?= =?iso-8859-1?Q?DeS8/PGbuDpZwGEFIdMTrabGFaLyAPzcejEKDLHt5JBLWVcVHoz6WlAUKp?= =?iso-8859-1?Q?kwJmHlF/o3TQN88z/XIhVJL+S3NYfoHBCHNQBN6Y+3Vs91cAhGEDOyuuha?= =?iso-8859-1?Q?u/Bm71SNgibhmlDGFIw3zMBYa9Dn6fj/Z8nQ66nHXf4hxHD1MNDP+rRo23?= =?iso-8859-1?Q?FU97K8jDqpoi/l+jJH6mRNyPud6G0bAYMtcK/+/14g20vkQeR2KIxda/Mb?= =?iso-8859-1?Q?Gb/GUvUVR+OLgVB51s7Kifi3nSCGKgoWVenjJJhQai368Yr2lFMAB+tdEg?= =?iso-8859-1?Q?ErBF+ilWAID6RksjFrTOXIROyRHkqY53jQVTieiQ+9XOj6sT9Zn7ip/OIZ?= =?iso-8859-1?Q?r2fYEcC4JWs22LpKsy57k6GRCgAWBwHoNYtAH8VjQZmNSCHHx0s3U2Ud5t?= =?iso-8859-1?Q?sp9Yw+6AKoSU5awWcRUwbvoSZVW/AFo7cjrUUmWRVM/OflUlbHYJMyzQ9H?= =?iso-8859-1?Q?pgCfffNR9NhQVzj3uQrYNN2aJI/Hx6brGrXOpyY4q+lC2eXgV/KE88QA6W?= =?iso-8859-1?Q?DEW/s9A5pBJL+2HZd3j0frYpj7AIDB8wly8dk1QbArJ2DbtvYpFAN5EIX8?= =?iso-8859-1?Q?/lKUP6nTMJoeI+sgwLPRsKPTGn+zIezG99EHmyi0NIBHHM+3Pjayh/Je8p?= =?iso-8859-1?Q?OWsPDXqw7J9V3MwhGJlz/JLUlo7bsrv1SkUjCWwDeUtFPtCDwG9FJ9y+G/?= =?iso-8859-1?Q?lHPqE3oZhVSCyE9s1RF4X6NCf92EcheQlCi1njBRZLUXv37OYgMSQ=3D?= =?iso-8859-1?Q?=3D?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 6:58fXcHPgNB6I4mlpvIy4WC9bXkJw5alFXjtz6OgQqkg5e7fH504OA4+oiD0RBpqpmNsOmh+Vwx7cENLv2ZY9QiEs2tJYNk63JHe9ICQJ12i8JEssX7fqfH54JaE2xzIgMF5TbuBq2l89+rD+ll/zs1AUfqFdOZUsuW91pdG06xTy/AAl5Vl5+gfCQ3UWvAOvfQ26SMXgXI1gsTF4yCKql7LFi+98Co9PwFdU9l3pvmOaCuikpY+FfpYGMUO0qZAkwBZV8/3CF+wyoVqUn6YZR/mix8y3FA5b0JuehCkIyH8FlV6Dg+2riyyuud9dACctF85twh/bFcIk1RcQkIb9JNLUqg9Ujk6+YvVP/yIZJ8M=; 5:Yak/3GzpStkPFgYzzgrlJL3JMFtm1JdJnYsZUFKO/y/iZGZhqchDMXWDsBeywhBLwP9kX4MKjja0GUaLAHqEJyaNt/V7bqeAK8PUpQRM9KyZ1wiv5JO748JzYIy++SalN9dM7Wjq1JydjaPEIYO4i/K2vOpYU1/WiQJp+5d6hbU=; 24:eTWMAqTeMqqffsl9WHkhlsJy6cQkP2Kx4ob2AMF1rIFVK62YeHMF0qtcJuQX/SkZeSqg57VRdsuJ8b2XOuqiesFT/g6ZzDMtIwtLRm9XA1s=; 7:7S6kdkL2kG+9uvd6cQKhofCDZu8Zmth6OZR+GwaEfOaIbMBPylXlhXQk49Ao0kJc1Ghr5pTAbScy1kfvvhYxFIyxbogfgPXk8v4zgMNKJKT54P/mGUOs72O2CfcCcJ0qS6y96GpOMWHmbMYiHYylDlxiP45pBIGYcr4TvxOuFjwVe0RZGaJd6OUji1d3yoSemwR+TdypbrBXXzhGay68woPqRtVTX0tCeViQCCI45WTdjPiVEObezhgs/Yh0v7mc
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 14 Feb 2018 12:50:29.6367 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 2f2e526c-1d5c-4639-8dfe-08d573a9874b
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3008
Archived-At: 
Subject: [netmod] Draft Informative references in a YANG module
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Feb 2018 12:50:35 -0000

If a YANG module has a Reference or Description clause specifying an
I-D, and the I-D is listed as an Informative Reference, as many are
outside the
NETCONF/Netmod WGs, then will the I-D be published with that reference
still as a draft e.g. with text such as

 reference "I-D.ietf-netconf-tls-client-server: TLS Client and Server
Models";

or

See section 4.2.1 of draft-ietf-ntp-packet-timestamps
?

The RFC Editor has a MISSREF status/procedure but that only applies to a
Normative Reference, not to an Informative one, so will the RFC appear
with the Reference or Description clause specifying the I-D?

Tom Petch



From nobody Wed Feb 14 05:07:29 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2012B124234; Wed, 14 Feb 2018 05:07:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id L5xmtkDnUINf; Wed, 14 Feb 2018 05:07:25 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 1528E120454; Wed, 14 Feb 2018 05:07:25 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id BADE21820414; Wed, 14 Feb 2018 14:05:28 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 257B418203DE; Wed, 14 Feb 2018 14:05:24 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , Alexander Clemm 
Cc: NETCONF WG , NETMOD WG 
In-Reply-To: 
References:  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com> <20180213194821.cwbwwmy7bqhvkfsd@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com> <20180213202858.uvowmjtx2uk4snyz@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE82BD@sjceml521-mbs.china.huawei.com> 
Mail-Followup-To: Robert Wilton , Alexander Clemm , NETCONF WG , NETMOD WG 
Date: Wed, 14 Feb 2018 14:07:19 +0100
Message-ID: <87r2pn3ek8.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Feb 2018 13:07:28 -0000

Robert Wilton  writes:

> Hi Alex,
>
> I see no real advantages to putting this directly in YANG library bis,=20
> but I think that augmenting the YANG library bis structure is just fine=20
> (in the same way that the latest version of schema mount has proposed to=
=20
> do).
>
> Generally, I think that it is good that NETCONF/YANG is built up of=20
> fairly loosely coupled components.=C2=A0 E.g. implementations can choose=
=20
> which subset of features are required for their particular circumstances=
=20
> (e.g. protocol, encoding, schema mount, YANG push, with-defaults, etc).=
=C2=A0=20
> If over time it becomes clear that it is critical for good interop that=20
> particular features must always be supported then we can define NETCONF=20
> 2.0 or 3.0 that mandates that a particular set of technologies must be=20
> implemented to meet the standard.
>
> The added bonus of having these components loosely coupled is that they=20
> can be improved and refined independently, potentially allowing IETF to=20
> move a bit quicker advancing the technologies.
>
> Finally, even if there is common meta-data structure that is shared by=20
> multiple features, that still doesn't mean that it has to go in the base=
=20
> YANG library spec, that can still just be shared common extension.

+1

Lada

>
> Thanks,
> Rob
>
>
> On 13/02/2018 21:25, Alexander Clemm wrote:
>> My proposal is to add this to the YANG data model.  I think this logical=
ly belongs to YANG library which is why I would like to see it there.  I al=
so think it will be useful to many implementations.  All, probably not, but=
 they have also survived without YANG library for a while:-) Of course, it =
is always possible to write another draft or do a bisbis.
>> Cheers
>> --- Alex
>>
>>> -----Original Message-----
>>> From: Juergen Schoenwaelder [mailto:j.schoenwaelder@jacobs-university.d=
e]
>>> Sent: Tuesday, February 13, 2018 12:29 PM
>>> To: Alexander Clemm 
>>> Cc: Mahesh Jethanandani ; NETCONF WG
>>> ; NETMOD WG 
>>> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
>>>
>>> I must have missed your actionable proposal that is relevant for _all_ =
NETCONF
>>> and RESTCONF implementations.
>>>
>>> YANG data models are extensible so lets use that.
>>>
>>> /js
>>>
>>> On Tue, Feb 13, 2018 at 07:58:37PM +0000, Alexander Clemm wrote:
>>>> Well, we need a general solution for that.  YANG-push is just one use =
case.
>>> There are other cases where there will be "metadata" (that does not per=
tain to
>>> instance data)  and capabilities that clients want to discover.  YANG l=
ibrary (in
>>> itself providing "metadata" about what a server supports and is capable=
 of) is an
>>> excellent place to maintain this information.  It also provides the opp=
ortunity to
>>> be systemic about it, as opposed to requiring everyone to define their =
own little
>>> custom extensions.
>>>> --- Alex
>>>>
>>>>> -----Original Message-----
>>>>> From: Juergen Schoenwaelder
>>>>> [mailto:j.schoenwaelder@jacobs-university.de]
>>>>> Sent: Tuesday, February 13, 2018 11:48 AM
>>>>> To: Alexander Clemm 
>>>>> Cc: Mahesh Jethanandani ; NETCONF WG
>>>>> ; NETMOD WG 
>>>>> Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
>>>>>
>>>>> Alexander,
>>>>>
>>>>> I disagree. This YANG Library is mandatory for all implementations;
>>>>> what you talk about seems to concern only implementations that
>>>>> support YANG push. Hence, this is an extension that should go in its =
own
>>> module.
>>>>> /js
>>>>>
>>>>> On Tue, Feb 13, 2018 at 07:38:31PM +0000, Alexander Clemm wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have taken a look at this document.
>>>>>>
>>>>>> My main comment is that one aspect that is missing, that I believe
>>>>>> should be
>>>>> added, concerns the inclusion of certain metadata about the modules.
>>>>> Specifically, in the context of YANG-Push we had a discussion about
>>>>> being able to mark nodes that are notifiable on change.  This is
>>>>> just one particular use case of a more general issue; in YANG-Push
>>>>> after much debate the conclusion was for now to simply make
>>>>> implementors aware of this issue and advise that a solution to this
>>>>> must be provided, with the clear understanding that eventually a stan=
dard
>>> solution should be defined.
>>>>>> Since the goal of YANG-Library is to allow clients to find out
>>>>>> what is actually
>>>>> supported on a given server, this is the right place to keep this
>>>>> information.  One possible way to address this would be, for a given
>>>>> module, to maintain a list of "meta-info", with a key "meta-tag",
>>>>> and a list with references to the nodes to which the metadata
>>>>> applies.  In the case of notifiable-on-change, you would have a list
>>>>> with one entry "notifiable-on-change", and then the list with the node
>>> definitions to which this tag applies.
>>>>>> Editorial nit:
>>>>>> 2nd paragraph Introduction: informaton --> information
>>>>>>
>>>>>> Thanks
>>>>>> --- Alex
>>>>>>
>>>>>> From: Netconf [mailto:netconf-bounces@ietf.org] On Behalf Of
>>>>>> Mahesh Jethanandani
>>>>>> Sent: Thursday, February 01, 2018 11:00 AM
>>>>>> To: NETCONF WG 
>>>>>> Cc: NETMOD WG 
>>>>>> Subject: [Netconf] LC on YANG Library (bis)
>>>>>>
>>>>>> WG,
>>>>>>
>>>>>> The authors of rfc7895bis have indicated that they believe the
>>>>>> document is
>>>>> ready for LC[1].
>>>>>> This starts a two week LC on the
>>>>>> draft>>>> netconf-rfc7895bis-04>. The LC will end on February 15.
>>>>>> Please send your comments on this thread. Reviews of the document,
>>>>>> and
>>>>> statement of support are particularly helpful to the authors. If you
>>>>> have concerns about the document, please state those too.
>>>>>> Authors please indicate if you are aware of any IPR on the document.
>>>>>>
>>>>>> Thanks.
>>>>>>
>>>>>> [1]
>>>>>> https://www.ietf.org/mail-archive/web/netconf/current/msg13980.htm
>>>>>> l
>>>>>>
>>>>>> Mahesh & Kent
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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         
>>> --
>>> 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

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


From nobody Wed Feb 14 05:18:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9546B124234 for ; Wed, 14 Feb 2018 05:18:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rP3IwE2z0yZc for ; Wed, 14 Feb 2018 05:18:46 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C053F120454 for ; Wed, 14 Feb 2018 05:18:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1951; q=dns/txt; s=iport; t=1518614325; x=1519823925; h=to:from:subject:message-id:date:mime-version; bh=dEwZO2UH77IrQ5vZGt6h+HCJnSI37F0wMIhvRBb68iY=; b=NG/XLDHeXPMGaAIWcDCCCcTpm+rSedyaY2mhbdWQIAN1rRfV2EWYBC4n bgIDdsdv8adk4pEMYlTOWvDxYWpiITPnaxmSsukFlyIGxz4FB89iN3jIf qupf8L5anTsMNEtgBVB5gmzi2MQ2wfgpkQFDZHe7hu8L0WeUJAY3jxGK4 w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAQDONoRa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUohA2LGJAnkGeFcIIDCokJFAECAQEBAQEBAmsohRozdAEOMAJ?= =?us-ascii?q?LFA0IAQGKMa9LgicmhFuDfYITAQEIAgElhQGDbIFoKYdvg0+CZQWkLwmWBYIfh?= =?us-ascii?q?iqDc4gJkACIGYE8NiKBUDMaCBsVgwSEd0COHQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,512,1511827200"; d="scan'208,217";a="2068074"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 13:18:42 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1EDIgKa027956 for ; Wed, 14 Feb 2018 13:18:42 GMT
To: NETMOD Working Group 
From: Benoit Claise 
Message-ID: 
Date: Wed, 14 Feb 2018 14:18:42 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------7800BCED7E7FC4B2011D4240"
Content-Language: en-US
Archived-At: 
Subject: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Feb 2018 13:18:47 -0000

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

Dear all,

- the draft is NMDA compliant, right? It should be mentioned.
Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro

    The YANG model in this document conforms to the Network Management
    Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.

- As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams] 
should be an informative reference, not normative.

- Editorial:
OLD:
This draft addresses the common leafs
NEW:
This document addresses the common leafs

Please publish a new version asap.
In the mean time, I'm sending this draft to IETF LC.

Regards, Benoit


--------------7800BCED7E7FC4B2011D4240
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    Dear all,

    

    - the draft is NMDA compliant, right? It should be mentioned.

    Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and
      intro

    
   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in I-D.ietf-netmod-revised-datastores.



    - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
    should be an informative reference, not normative.

    

    - Editorial:

    OLD: 

    This draft addresses the common leafs

    NEW: 

    This document addresses the common leafs

    

    Please publish a new version asap.

    In the mean time, I'm sending this draft to IETF LC.

    

    Regards, Benoit

    

  


--------------7800BCED7E7FC4B2011D4240--


From nobody Wed Feb 14 06:42:10 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 931FE12741D; Wed, 14 Feb 2018 06:42:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vxo4MKaissSr; Wed, 14 Feb 2018 06:42:05 -0800 (PST)
Received: from smtp2.eurecom.fr (smtp2.eurecom.fr [193.55.113.211]) by ietfa.amsl.com (Postfix) with ESMTP id 1D6AE126BFD; Wed, 14 Feb 2018 06:42:03 -0800 (PST)
X-IronPort-AV: E=Sophos;i="5.46,512,1511823600";  d="scan'208";a="7652973"
Received: from thorgal.eurecom.fr ([10.3.2.220]) by drago2i.eurecom.fr with ESMTP; 14 Feb 2018 15:42:02 +0100
Received: (from apache@localhost) by thorgal.eurecom.fr (8.14.4+Sun/8.14.4/Submit) id w1EEg2E4020499; Wed, 14 Feb 2018 15:42:02 +0100 (CET)
X-Authentication-Warning: thorgal.eurecom.fr: apache set sender to otilibil@eurecom.fr using -f
Received: from reverse.completel.net (reverse.completel.net [92.103.89.82]) by webmail.eurecom.fr (Horde MIME library) with HTTP; Wed, 14 Feb 2018 15:42:02 +0100
Message-ID: <20180214154202.v15kguz5cs80ok44@webmail.eurecom.fr>
Date: Wed, 14 Feb 2018 15:42:02 +0100
From: otilibil@eurecom.fr
To: draft-ietf-netconf-rfc6536bis@ietf.org
Cc: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; DelSp="Yes"; format="flowed"
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
User-Agent: Internet Messaging Program (IMP) H3 (4.1.4)
X-Originating-IP: 92.103.89.82
X-Remote-Browser: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.89 Safari/537.36
Archived-At: 
Subject: [netmod] A mean to match many entries would ease the writing of rules
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Feb 2018 14:42:08 -0000

Hello all,
I reviewed draft-ietf-netconf-rfc6536bis-09; it seems the draft misses =20
a way to match many entries under the same rule. For example, instead =20
of,

       
         permit-get-config
         ietf-netconf
         get-config
         exec
         permit
         
=09  Permits invocation of the NETCONF 'get-config'.
=09
       
       
         permit-get
         ietf-netconf
         get
         exec
         permit
         
=09  Permits invocation of the NETCONF 'get'.
=09
       

It would ease the writing to have a keyword (or a white space, as for =20
'access-operations') to match many entries at the same time:

       
         permit-get
         ietf-netconf
         get get-config
         exec
         permit
         
=09  Permits invocation of the NETCONF 'get' & 'get-config'.
=09
       

So, the valid values will become (for 'rpc-name', 'notification-name', =20
and 'path'):

  * A string for one entry
  * A string for more than one entry (a white space separates entries)
  * Or, the catch-all '*'.

How do you see my proposal?

Regards,
Ariel



----------------------------------------------------------------------------=
---
This message was sent using EURECOM Webmail: http://webmail.eurecom.fr


From nobody Wed Feb 14 06:46:49 2018
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 0951C124E15; Wed, 14 Feb 2018 06:46:34 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.1
Auto-Submitted: auto-generated
Precedence: bulk
CC: netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org, Kent Watsen , draft-ietf-netmod-syslog-model@ietf.org, Lou Berger , bclaise@cisco.com
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151861959399.19230.11554893820425004879.idtracker@ietfa.amsl.com>
Date: Wed, 14 Feb 2018 06:46:33 -0800
Archived-At: 
Subject: [netmod] Last Call:  (A YANG Data Model for Syslog Configuration) to Proposed Standard
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Feb 2018 14:46:34 -0000

The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'A YANG Data Model for Syslog
Configuration'
   as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-02-28. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.

Editorial Note (To be removed by RFC Editor)

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

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

   o  "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft-
      ietf-netconf-keystore


   o  "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value
      for draft-ietf-netconf-tls-client-server


   o  "zzzz" --> the assigned RFC value for this draft





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
    draft-ietf-netconf-tls-client-server: YANG Groupings for TLS Clients and TLS Servers (None - IETF stream)
    draft-ietf-netconf-keystore: YANG Data Model for a "Keystore" Mechanism (None - IETF stream)




From nobody Wed Feb 14 07:11:26 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 75827128959 for ; Wed, 14 Feb 2018 07:11:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HAzBUSSZOjgi for ; Wed, 14 Feb 2018 07:11:22 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E7EFA126BFD for ; Wed, 14 Feb 2018 07:11:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8673; q=dns/txt; s=iport; t=1518621082; x=1519830682; h=from:subject:to:cc:message-id:date:mime-version; bh=+a9gg/Pzzva6hHr4zuALYLJCdMvxq8ddS3A8F5y1FtU=; b=VHb854v3Z6T6VlpZ2zxv4D6L3a8EJ+xxzhA8JdKeHnlVR29ND3dSZKom uk0M6Hl7ME20xWXXRzAKH8RYf2AlA9wTHkmwQVIFJdrg7D13C6kJlRsA5 iZTAF3mewbEHSJ+aOQWrF1UDlIag8/PZMfry+vFtZXVCryno/jQSQYYg4 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DUAQC2UIRa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ4cCiDZYsYjmqBPpBnhXCCAwojhRiDURUBAgEBAQEBAQJrKIV?= =?us-ascii?q?NTwddAl8NCAEBijEQryeCJyaEW4N8ghMBAQEBAQUBAQEBAQEdBYUCg2yBaCkMh?= =?us-ascii?q?igBAQIBgTYFARIBCYMtgmUFkk6RYQmIII1lgh+GKoNzJodjjgKBfogZgTw1I2B?= =?us-ascii?q?wMxoIGxUZgmuEd0A3AQGLJoI+AQEB?=
X-IronPort-AV: E=Sophos;i="5.46,512,1511827200"; d="scan'208,217";a="2070402"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Feb 2018 15:11:19 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1EFBJLK005450; Wed, 14 Feb 2018 15:11:19 GMT
From: Benoit Claise 
To: NETMOD Working Group 
Message-ID: 
Date: Wed, 14 Feb 2018 16:11:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="------------EFE58642229F355B38A8B34E"
Content-Language: en-US
Archived-At: 
Subject: [netmod] AD review of draft-ietf-netmod-rfc6087bis Part 2
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Feb 2018 15:11:24 -0000

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

Dear all,

Here is the part 2 of the AD review, from section 4.21 on.

Regarding the part 1, thanks Andy for addressing all comments in version 17.

- section 4.22 "Data Correlation.

Not sure what you mean by the section title and "Data can be correlated in various ways"?
Which data? YANG modules, YANG objects, object instances, from different YANG server, etc.
I guess I miss a sentence or two regarding this "correlation" objective and which guidelines this section
is going to provide to "authors and reviewers of Standards Track specifications containing YANG data model modules".
Note: I read that section multiple times.

- section 4.22
    It is sometimes useful to separate configuration data and operational
    state, so that they do not not even share the exact same naming
    characteristics.  The correlation between configuration the
    operational state that is affected by changes in configuration is a
    complex problem.  There may not be a simple 1:1 relationship between
    a configuration data node and an operational state node.  Further
    work is needed in YANG to clarify this relationship.  Protocol work
    may also be needed to allow a client to retrieve this type of
    information from a server.  At this time the best practice is to
    clearly document any relationship to other data structures in the
    "description" statement.

Isn't it clarified with NMDA. It's not inline with 4.23.2, which says:
	
    Designers SHOULD describe and justify any NMDA exceptions in detail,
    such as the use of separate subtrees and/or separate leafs.

... and I guess confusing in light of the real guidelines in 4.23.3
Btw, why is this paragraph in 4.22 and not in 4.23?

- section 4.23

	Operational state is now modeled using YANG according to new NMDA,

Please add a reference to the draft.

- section 4.26 "YANG 1.1 Guidelines"
I'm confused by the title. The entire document is about 1.1, right?
I guess you want to express something such as "YANG 1.1 specific Constructs Guidelines"

- section 4.26.1

      Multiple revisions of the same module can be imported, provided that
      different prefixes are used.

Reading https://tools.ietf.org/html/rfc7950#section-7.1.5. Any contradiction?
Then reading:
    This MAY be done if the authors can
    demonstrate that the "avoided" definitions from the most recent of
    the multiple revisions are somehow broken or harmful to
    interoperability.

"avoided" definitions?
I simply don't understand this sentence.

- section 4.26.4
    The NETCONF Access Control Model (NACM) [RFC6536 ] does not support
    parameter access control for RPC operations.

Let's use draft-ietf-netconf-rfc6536bis


- Appendix B

    YANG Module Registry: Register the YANG module name, prefix,
          namespace, and RFC number, according to the rules specified
          in [RFC7950 ].

I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" registry is specified in RFC6020/.
See for example https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6

- Appendix B
References -- verify that the references are properly divided
       between normative and informative references, thatRFC 2119   is
       included as a normative reference if the terminology defined
       therein is used in the document

Refer to RFC8174

- Appendix B (and maybe some more text somewhere else.
To refer to Tom Petch latest email to NETMOD, we should need a few words about:
   If a YANG module has a Reference or Description clause specifying an
   I-D, and the I-D is listed as an Informative Reference.

Regards, Benoit


--------------EFE58642229F355B38A8B34E
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  

    
  
  
    
Dear all,

Here is the part 2 of the AD review, from section 4.21 on.

Regarding the part 1, thanks Andy for addressing all comments in version 17.

- section 4.22 "Data Correlation.

Not sure what you mean by the section title and "Data can be correlated in various ways"?
Which data? YANG modules, YANG objects, object instances, from different YANG server, etc.
I guess I miss a sentence or two regarding this "correlation" objective and which guidelines this section 
is going to provide to "authors and reviewers of Standards Track specifications containing YANG data model modules".
Note: I read that section multiple times.

- section 4.22
   It is sometimes useful to separate configuration data and operational
   state, so that they do not not even share the exact same naming
   characteristics.  The correlation between configuration the
   operational state that is affected by changes in configuration is a
   complex problem.  There may not be a simple 1:1 relationship between
   a configuration data node and an operational state node.  Further
   work is needed in YANG to clarify this relationship.  Protocol work
   may also be needed to allow a client to retrieve this type of
   information from a server.  At this time the best practice is to
   clearly document any relationship to other data structures in the
   "description" statement.

Isn't it clarified with NMDA. It's not inline with 4.23.2, which says:
	
   Designers SHOULD describe and justify any NMDA exceptions in detail,
   such as the use of separate subtrees and/or separate leafs. 

... and I guess confusing in light of the real guidelines in 4.23.3
Btw, why is this paragraph in 4.22 and not in 4.23? 

- section 4.23

	Operational state is now modeled using YANG according to new NMDA,

Please add a reference to the draft.

- section 4.26 "YANG 1.1 Guidelines"
I'm confused by the title. The entire document is about 1.1, right?
I guess you want to express something such as "YANG 1.1 specific Constructs Guidelines"

- section 4.26.1 


    

      
 Multiple revisions of the same module can be imported, provided that
 different prefixes are used.


    

    
Reading https://tools.ietf.org/html/rfc7950#section-7.1.5. Any contradiction?
Then reading:
   This MAY be done if the authors can
   demonstrate that the "avoided" definitions from the most recent of
   the multiple revisions are somehow broken or harmful to
   interoperability. 

"avoided" definitions? 
I simply don't understand this sentence.


    
- section 4.26.4
   The NETCONF Access Control Model (NACM) [RFC6536] does not support
   parameter access control for RPC operations.

Let's use draft-ietf-netconf-rfc6536bis


- Appendix B

   YANG Module Registry: Register the YANG module name, prefix,
         namespace, and RFC number, according to the rules specified
         in [RFC7950].

I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" registry is specified in RFC6020/.
See for example https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6

- Appendix B
References -- verify that the references are properly divided
      between normative and informative references, that RFC 2119 is
      included as a normative reference if the terminology defined
      therein is used in the document

Refer to RFC8174

- Appendix B (and maybe some more text somewhere else.
To refer to Tom Petch latest email to NETMOD, we should need a few words about:
  If a YANG module has a Reference or Description clause specifying an
  I-D, and the I-D is listed as an Informative Reference.

Regards, Benoit



    
 

  


--------------EFE58642229F355B38A8B34E--


From nobody Wed Feb 14 10:04:00 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3B2512D810 for ; Wed, 14 Feb 2018 10:03:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wIIQpW0XEgUy for ; Wed, 14 Feb 2018 10:03:56 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A9C9912D811 for ; Wed, 14 Feb 2018 10:03:53 -0800 (PST)
Received: from pps.filterd (m0108160.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1EHx8Af020191; Wed, 14 Feb 2018 10:03:51 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=dcvOrcHBWBDkUAoA9NNccvrFjVfXbsh/iGyN1PYwcgs=; b=p3J3OxRnU2CUcoo2AXEtuuXlUGuDmZ9ga4XkKcNBNhDByrE8zKehszvOWC9d4ZEd5iq4 RDI3G8TD77IdRGyzxqItzOnGt3Y+rxON/OtpaGqlA7cpTx6iLrh6DCbVT0VBpA5T/1nG enURfu81HFXPez1bbE76LjLkxj23YVZS60GMAoUCSBHDztZA7USf+qBJe9y7vbffLRpa ECbu0n/sCvUSf2dAmfFo3MELwdpoqLU0gmAK9kzk8F4qa8VHwSUyTd+iRr98XFzIV1tb LJV5DjnmX7rdNZWzH9m9e5MN48sEqoB6yTZ2cB8bN6K31orj6oWkQJgbdxxGNvbtEYxn rg== 
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0050.outbound.protection.outlook.com [216.32.180.50]) by mx0b-00273201.pphosted.com with ESMTP id 2g4st500ug-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 14 Feb 2018 10:03:51 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3435.namprd05.prod.outlook.com (10.174.240.26) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384) id 15.20.527.6; Wed, 14 Feb 2018 18:03:43 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::7433:3915:f20d:6747%13]) with mapi id 15.20.0506.013; Wed, 14 Feb 2018 18:03:43 +0000
From: Kent Watsen 
To: NETMOD Working Group 
Thread-Topic: [netmod] AD review of draft-ietf-netmod-syslog-model-20
Thread-Index: AQHTpZZd5Geu+8X2WUq2NsIzPrmhNqOj3UoA
Date: Wed, 14 Feb 2018 18:03:43 +0000
Message-ID: <922E608D-951A-459A-B515-B53834C805C1@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.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3435; 7:8Tq0CtNG8yKlVdPnTZ9EvaoGYp14w1AHhNK6nwPc9u2dSoKnWtAa2tcOsrZp0ErTNNI+bBb6QhVu9UzOH8JDEvMwrSeu1vZqEebWaXyUNr/6eRuHjEk+5063j/0H/RlvKufcFfhyyLaVrcZtdenrEpnKEEtuxwhzgAmQlgon0qGPUr+bnIcdE4bbpT02P3qO//STWipRHyUhqbOTCwOc4w4q7Ejf3bC+Ce1r0Jg47RTHuGHUjUXe9k28jzQu3JoZ
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 4fb34aff-f41a-4d1f-c3ed-08d573d54937
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3435; 
x-ms-traffictypediagnostic: DM5PR05MB3435:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(95692535739014)(21748063052155); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(10201501046)(3231101)(944501161)(3002001)(6055026)(6041288)(20161123562045)(20161123564045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB3435; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3435; 
x-forefront-prvs: 0583A86C08
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39380400002)(366004)(396003)(39860400002)(199004)(189003)(3280700002)(6246003)(76176011)(2950100002)(186003)(6916009)(236005)(105586002)(6512007)(54896002)(8936002)(7736002)(6306002)(53936002)(3846002)(6116002)(33656002)(2906002)(106356001)(478600001)(58126008)(83506002)(5660300001)(82746002)(316002)(99286004)(97736004)(3660700001)(6506007)(86362001)(53546011)(229853002)(36756003)(4326008)(59450400001)(68736007)(2900100001)(8676002)(25786009)(81156014)(6486002)(83716003)(81166006)(26005)(14454004)(6436002)(5250100002)(102836004)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3435; H:DM5PR05MB3484.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)
x-microsoft-antispam-message-info: oRsH58ZC/xMttmjXz3VYyruZzEgwGfjhNMaOoKAvid0qQ3hkaxedrjZBprkPpACM7LuO5TFisvGRnDwbshsSng==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_922E608D951A459AB515B53834C805C1junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 4fb34aff-f41a-4d1f-c3ed-08d573d54937
X-MS-Exchange-CrossTenant-originalarrivaltime: 14 Feb 2018 18:03:43.6100 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3435
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-14_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802140212
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 14 Feb 2018 18:03:59 -0000

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

QnVnZ2VycywgSSB0aG91Z2h0IHdlIGNhdWdodCB0aGF0IHRyZWUtZGlhZ3JhbXMgaW5mb3JtYXRp
dmUvbm9ybWF0aXZlIHRoaW5nIGJlZm9yZS4NCg0KUmVnYXJkbGVzcywgQ2x5ZGUsIHBsZWFzZSBu
b3RlIHRoYXQgSSB0aGluayBJIHdhcyB3cm9uZyBiZWZvcmUgZnJvbSB0aGUgc2hlcGhlcmQgd3Jp
dGUtdXAgcmVnYXJkaW5nIGlkbml0cyBoYXZpbmcgYSBwcm9ibGVtOg0KDQoiIiINCiAgPT0gVW51
c2VkIFJlZmVyZW5jZTogJ0ktRC5pZXRmLW5ldGNvbmYta2V5c3RvcmUnIGlzIGRlZmluZWQgb24g
bGluZSAxMzQwLA0KICAgICBidXQgbm8gZXhwbGljaXQgcmVmZXJlbmNlIHdhcyBmb3VuZCBpbiB0
aGUgdGV4dA0KICAgICAnW0ktRC5pZXRmLW5ldGNvbmYta2V5c3RvcmVdIFdhdHNlbiwgSy4sICJZ
QU5HIERhdGEgTW9kZWwgZm9yIGEgIktleXMuLi4nDQoNCiAgIFRoaXMgaXMgYSBidWcgaW4gaWRu
aXRzLCB3aGVyZWJ5IGEgcmVmZXJlbmNlIHRoYXQgc3BsaXRzIHR3byBsaW5lcyBpcw0KICAgbm90
IGZvdW5kLg0KIiIiDQoNCkxvb2tpbmcgYXQgdGhlIFhNTCwgaXQgc2VlbXMgdGhhdCByZWZlcmVu
Y2VzIGFyZSBub3Qgc3BlY2lmaWVkIGNvcnJlY3RseS4NCg0KQ1VSUkVOVDoNCg0KICAgICAgICA8
dD5UaGlzIG1vZHVsZSBpbXBvcnRzIHR5cGVkZWZzIGZyb20gW1JGQzcyMjNdLCBncm91cGluZ3Mg
ZnJvbQ0KICAgICAgICBbSS1ELmlldGYtbmV0Y29uZi1rZXlzdG9yZV0sIGFuZCBbSS1ELmlldGYt
bmV0Y29uZi10bHMtY2xpZW50LXNlcnZlcl0sIGFuZCBpdCByZWZlcmVuY2VzIFtSRkM1NDI0XSwN
CiAgICAgICAgW1JGQzU0MjVdLCBbUkZDNTQyNl0sIGFuZCBbUkZDNTg0OF0gYW5kIFtTdGQtMTAw
My4xLTIwMDhdLjwvdD4NCg0KU0hPVUxEIEJFOg0KDQogICAgICAgIDx0PlRoaXMgbW9kdWxlIGlt
cG9ydHMgdHlwZWRlZnMgZnJvbSA8eHJlZiB0YXJnZXQ9IlJGQzcyMjMiLz4sIGdyb3VwaW5ncyBm
cm9tDQogICAgICAgIDx4cmVmIHRhcmdldD0iSS1ELmlldGYtbmV0Y29uZi1rZXlzdG9yZSIvPiwg
YW5kIDx4cmVmIHRhcmdldD0iSS1ELmlldGYtbmV0Y29uZi10bHMtY2xpZW50LXNlcnZlciIvPiwg
YW5kIGl0IHJlZmVyZW5jZXMgPHhyZWYgdGFyZ2V0PSJSRkM1NDI0Ii8+LA0KICAgICAgICA8eHJl
ZiB0YXJnZXQ9IlJGQzU0MjUiLz4sIDx4cmVmIHRhcmdldD0iUkZDNTQyNiIvPiwgYW5kIDx4cmVm
IHRhcmdldD0iUkZDNTg0OCIvPiBhbmQgPHhyZWYgdGFyZ2V0PSJTdGQtMTAwMy4xLTIwMDgiLz4u
PC90Pg0KDQpSaWdodD8NCg0KQW5kIHdoaWxlIHlvdSdyZSBhdCBpdCwgcGxlYXNlIHVwZGF0ZSB0
aGUgcmVmZXJlbmNlIHRvIHRoZSB0cmVlLWRpYWdyYW1zIGRyYWZ0ICgtMDYgaXMgY3VycmVudCku
ICBBbHNvLCBtaXNzaW5nIGlzIGFuIFJGQyBFZGl0b3Igbm90ZSByZXF1ZXN0aW5nIHRoYXQgdGhl
IEktRCByZWZlcmVuY2UgdG8gYmUgdXBkYXRlZCB0byByZWZsZWN0IHRoZSBhc3NpZ25lZCBSRkMg
bnVtYmVyLg0KDQpQbGVhc2UgYWxzbyBhZGRyZXNzIHRoZXNlIGlzc3VlcyB3aGVuIHBvc3Rpbmcg
LTIxIHRvIGFkZHJlc3MgQmVub2l0J3MgaXNzdWVzLiAgUGxlYXNlIHBvc3QgLTIxIEFTQVAgYXMg
QmVub2l0IGhhcyBhbHJlYWR5IHBsYWNlZCB0aGlzIGRyYWZ0IG9uIHRoZSBJRVNHIHRlbGVjaGF0
IGluIGEgY291cGxlIHdlZWtzLg0KDQpUaGFua3MsDQpLZW50IC8vIHNoZXBoZXJkDQoNCg0KT24g
Mi8xNC8xOCwgODoxOCBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgQmVub2l0IENsYWlzZSIgPG5l
dG1vZC1ib3VuY2VzQGlldGYub3JnPG1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZz4gb24g
YmVoYWxmIG9mIGJjbGFpc2VAY2lzY28uY29tPG1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbT4+IHdy
b3RlOg0KDQpEZWFyIGFsbCwNCg0KLSB0aGUgZHJhZnQgaXMgTk1EQSBjb21wbGlhbnQsIHJpZ2h0
PyBJdCBzaG91bGQgYmUgbWVudGlvbmVkLg0KRXg6IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzcyMjNi
aXMtMDMsIGluIHRoZSBhYnN0cmFjdCBhbmQgaW50cm8NCg0KICAgVGhlIFlBTkcgbW9kZWwgaW4g
dGhpcyBkb2N1bWVudCBjb25mb3JtcyB0byB0aGUgTmV0d29yayBNYW5hZ2VtZW50DQoNCiAgIERh
dGFzdG9yZSBBcmNoaXRlY3R1cmUgZGVmaW5lZCBpbiBJLUQuaWV0Zi1uZXRtb2QtcmV2aXNlZC1k
YXRhc3RvcmVzLg0KDQoNCi0gQXMgbWVudGlvbmVkIGluIHRoZSB3cml0ZXVwLCBbSS1ELmlldGYt
bmV0bW9kLXlhbmctdHJlZS1kaWFncmFtc10gc2hvdWxkIGJlIGFuIGluZm9ybWF0aXZlIHJlZmVy
ZW5jZSwgbm90IG5vcm1hdGl2ZS4NCg0KLSBFZGl0b3JpYWw6DQpPTEQ6DQpUaGlzIGRyYWZ0IGFk
ZHJlc3NlcyB0aGUgY29tbW9uIGxlYWZzDQpORVc6DQpUaGlzIGRvY3VtZW50IGFkZHJlc3NlcyB0
aGUgY29tbW9uIGxlYWZzDQoNClBsZWFzZSBwdWJsaXNoIGEgbmV3IHZlcnNpb24gYXNhcC4NCklu
IHRoZSBtZWFuIHRpbWUsIEknbSBzZW5kaW5nIHRoaXMgZHJhZnQgdG8gSUVURiBMQy4NCg0KUmVn
YXJkcywgQmVub2l0DQoNCg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpz
cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250
LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xv
cjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5v
bmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu
MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkJ1Z2dlcnMsIEkg
dGhvdWdodCB3ZSBjYXVnaHQgdGhhdCB0cmVlLWRpYWdyYW1zIGluZm9ybWF0aXZlL25vcm1hdGl2
ZSB0aGluZyBiZWZvcmUuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD
YWxpYnJpIj5SZWdhcmRsZXNzLCBDbHlkZSwgcGxlYXNlIG5vdGUgdGhhdCBJIHRoaW5rIEkgd2Fz
IHdyb25nIGJlZm9yZSBmcm9tIHRoZSBzaGVwaGVyZCB3cml0ZS11cCByZWdhcmRpbmcgaWRuaXRz
IGhhdmluZyBhIHByb2JsZW06PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpIj4mcXVvdDsmcXVvdDsmcXVvdDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7
ID09IFVudXNlZCBSZWZlcmVuY2U6ICdJLUQuaWV0Zi1uZXRjb25mLWtleXN0b3JlJyBpcyBkZWZp
bmVkIG9uIGxpbmUgMTM0MCw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7IGJ1dCBubyBleHBsaWNpdCByZWZlcmVuY2Ugd2FzIGZvdW5kIGluIHRoZSB0ZXh0PG86
cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyAnW0ktRC5pZXRmLW5l
dGNvbmYta2V5c3RvcmVdIFdhdHNlbiwgSy4sICZxdW90O1lBTkcgRGF0YSBNb2RlbCBmb3IgYSAm
cXVvdDtLZXlzLi4uJzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2Fs
aWJyaSI+Jm5ic3A7Jm5ic3A7IFRoaXMgaXMgYSBidWcgaW4gaWRuaXRzLCB3aGVyZWJ5IGEgcmVm
ZXJlbmNlIHRoYXQgc3BsaXRzIHR3byBsaW5lcyBpczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJz
cDsmbmJzcDsgbm90IGZvdW5kLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mcXVvdDsmcXVvdDsmcXVv
dDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkxvb2tp
bmcgYXQgdGhlIFhNTCwgaXQgc2VlbXMgdGhhdCByZWZlcmVuY2VzIGFyZSBub3Qgc3BlY2lmaWVk
IGNvcnJlY3RseS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+
PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGli
cmkiPkNVUlJFTlQ6PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOzxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp
YnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsgJmx0O3QmZ3Q7
VGhpcyBtb2R1bGUgaW1wb3J0cyB0eXBlZGVmcyBmcm9tIFtSRkM3MjIzXSwgZ3JvdXBpbmdzIGZy
b208bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7W0ktRC5pZXRmLW5ldGNvbmYta2V5c3RvcmVdLCBhbmQgW0ktRC5pZXRm
LW5ldGNvbmYtdGxzLWNsaWVudC1zZXJ2ZXJdLCBhbmQgaXQgcmVmZXJlbmNlcyBbUkZDNTQyNF0s
PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtZmFtaWx5OkNhbGlicmkiPiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyBbUkZDNTQyNV0sIFtSRkM1NDI2XSwgYW5kIFtSRkM1ODQ4XSBhbmQgW1N0ZC0xMDAz
LjEtMjAwOF0uJmx0Oy90Jmd0OzxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1p
bHk6Q2FsaWJyaSI+U0hPVUxEIEJFOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj4mbmJzcDs8bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1m
YW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
ICZsdDt0Jmd0O1RoaXMgbW9kdWxlIGltcG9ydHMgdHlwZWRlZnMgZnJvbSAmbHQ7eHJlZiB0YXJn
ZXQ9JnF1b3Q7UkZDNzIyMyZxdW90Oy8mZ3Q7LCBncm91cGluZ3MgZnJvbTxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD
YWxpYnJpIj4mbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bHQ7eHJlZiB0YXJnZXQ9JnF1b3Q7SS1ELmlldGYtbmV0Y29uZi1rZXlzdG9yZSZxdW90Oy8mZ3Q7
LCBhbmQgJmx0O3hyZWYgdGFyZ2V0PSZxdW90O0ktRC5pZXRmLW5ldGNvbmYtdGxzLWNsaWVudC1z
ZXJ2ZXImcXVvdDsvJmd0OywgYW5kIGl0IHJlZmVyZW5jZXMgJmx0O3hyZWYgdGFyZ2V0PSZxdW90
O1JGQzU0MjQmcXVvdDsvJmd0Oyw8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7ICZsdDt4cmVmIHRhcmdldD0mcXVvdDtSRkM1NDI1
JnF1b3Q7LyZndDssICZsdDt4cmVmIHRhcmdldD0mcXVvdDtSRkM1NDI2JnF1b3Q7LyZndDssIGFu
ZCAmbHQ7eHJlZiB0YXJnZXQ9JnF1b3Q7UkZDNTg0OCZxdW90Oy8mZ3Q7IGFuZCAmbHQ7eHJlZiB0
YXJnZXQ9JnF1b3Q7U3RkLTEwMDMuMS0yMDA4JnF1b3Q7LyZndDsuJmx0Oy90Jmd0OzxvOnA+PC9v
OnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZh
bWlseTpDYWxpYnJpIj4mbmJzcDs8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+UmlnaHQ/PG86cD48L286
cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFt
aWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5BbmQgd2hpbGUgeW91J3Jl
IGF0IGl0LCBwbGVhc2UgdXBkYXRlIHRoZSByZWZlcmVuY2UgdG8gdGhlIHRyZWUtZGlhZ3JhbXMg
ZHJhZnQgKC0wNiBpcyBjdXJyZW50KS4mbmJzcDsgQWxzbywgbWlzc2luZyBpcyBhbiBSRkMgRWRp
dG9yIG5vdGUgcmVxdWVzdGluZyB0aGF0IHRoZSBJLUQgcmVmZXJlbmNlIHRvIGJlIHVwZGF0ZWQg
dG8gcmVmbGVjdCB0aGUgYXNzaWduZWQNCiBSRkMgbnVtYmVyLjxvOnA+PC9vOnA+PC9zcGFuPjwv
cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJp
Ij48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+UGxlYXNlIGFsc28gYWRkcmVzcyB0aGVzZSBp
c3N1ZXMgd2hlbiBwb3N0aW5nIC0yMSB0byBhZGRyZXNzIEJlbm9pdCdzIGlzc3Vlcy4mbmJzcDsg
UGxlYXNlIHBvc3QgLTIxIEFTQVAgYXMgQmVub2l0IGhhcyBhbHJlYWR5IHBsYWNlZCB0aGlzIGRy
YWZ0IG9uIHRoZSBJRVNHIHRlbGVjaGF0IGluIGEgY291cGxlIHdlZWtzLjxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD
YWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+VGhhbmtzLDxvOnA+PC9vOnA+PC9z
cGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpD
YWxpYnJpIj5LZW50IC8vIHNoZXBoZXJkPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250
LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPGRp
dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIDIvMTQvMTgsIDg6MTggQU0sICZxdW90O25ldG1v
ZCBvbiBiZWhhbGYgb2YgQmVub2l0IENsYWlzZSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm5l
dG1vZC1ib3VuY2VzQGlldGYub3JnIj5uZXRtb2QtYm91bmNlc0BpZXRmLm9yZzwvYT4gb24gYmVo
YWxmIG9mDQo8YSBocmVmPSJtYWlsdG86YmNsYWlzZUBjaXNjby5jb20iPmJjbGFpc2VAY2lzY28u
Y29tPC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj5EZWFyIGFsbCw8YnI+DQo8YnI+DQotIHRoZSBkcmFmdCBpcyBOTURB
IGNvbXBsaWFudCwgcmlnaHQ/IEl0IHNob3VsZCBiZSBtZW50aW9uZWQuPGJyPg0KRXg6IDxzcGFu
IHN0eWxlPSJmb250LXNpemU6MTAuMHB0Ij5kcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAz
LCBpbiB0aGUgYWJzdHJhY3QgYW5kIGludHJvPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHByZT4m
bmJzcDsmbmJzcDsgVGhlIFlBTkcgbW9kZWwgaW4gdGhpcyBkb2N1bWVudCBjb25mb3JtcyB0byB0
aGUgTmV0d29yayBNYW5hZ2VtZW50PG86cD48L286cD48L3ByZT4NCjxwcmU+Jm5ic3A7Jm5ic3A7
IERhdGFzdG9yZSBBcmNoaXRlY3R1cmUgZGVmaW5lZCBpbiBJLUQuaWV0Zi1uZXRtb2QtcmV2aXNl
ZC1kYXRhc3RvcmVzLjxvOnA+PC9vOnA+PC9wcmU+DQo8cHJlPjxvOnA+Jm5ic3A7PC9vOnA+PC9w
cmU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4tIEFzIG1lbnRpb25lZCBpbiB0aGUgd3JpdGV1cCwg
W0ktRC5pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXNdIHNob3VsZCBiZSBhbiBpbmZvcm1h
dGl2ZSByZWZlcmVuY2UsIG5vdCBub3JtYXRpdmUuPGJyPg0KPGJyPg0KLSBFZGl0b3JpYWw6PGJy
Pg0KT0xEOiA8YnI+DQpUaGlzIGRyYWZ0IGFkZHJlc3NlcyB0aGUgY29tbW9uIGxlYWZzPGJyPg0K
TkVXOiA8YnI+DQpUaGlzIGRvY3VtZW50IGFkZHJlc3NlcyB0aGUgY29tbW9uIGxlYWZzPGJyPg0K
PGJyPg0KUGxlYXNlIHB1Ymxpc2ggYSBuZXcgdmVyc2lvbiBhc2FwLjxicj4NCkluIHRoZSBtZWFu
IHRpbWUsIEknbSBzZW5kaW5nIHRoaXMgZHJhZnQgdG8gSUVURiBMQy48YnI+DQo8YnI+DQpSZWdh
cmRzLCBCZW5vaXQ8YnI+DQo8YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i
b2R5Pg0KPC9odG1sPg0K

--_000_922E608D951A459AB515B53834C805C1junipernet_--


From nobody Wed Feb 14 18:23:22 2018
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 BC18F126C25; Wed, 14 Feb 2018 18:23:15 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151866139572.7472.13148235163775906818@ietfa.amsl.com>
Date: Wed, 14 Feb 2018 18:23:15 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-21.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Feb 2018 02:23:16 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : A YANG Data Model for Syslog Configuration
        Authors         : Clyde Wildes
                          Kiran Koushik
	Filename        : draft-ietf-netmod-syslog-model-21.txt
	Pages           : 34
	Date            : 2018-02-14

Abstract:
   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.

   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in [I-D.ietf-netmod-revised-
   datastores].

Editorial Note (To be removed by RFC Editor)

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

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

   o  "I-D.ietf-netconf-keystore" --> the assigned RFC value for draft-
      ietf-netconf-keystore


   o  "I-D.ietf-netconf-tls-client-server" --> the assigned RFC value
      for draft-ietf-netconf-tls-client-server


   o  "zzzz" --> the assigned RFC value for this draft



The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-21
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-21

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-21


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Thu Feb 15 05:33:00 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2DC3012DA03 for ; Thu, 15 Feb 2018 05:32:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.901
X-Spam-Level: 
X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (768-bit key) header.d=labn.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NCg9GOdFlxrB for ; Thu, 15 Feb 2018 05:32:57 -0800 (PST)
Received: from gproxy10-pub.mail.unifiedlayer.com (gproxy10-pub.mail.unifiedlayer.com [69.89.20.226]) (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 5A57312420B for ; Thu, 15 Feb 2018 05:32:57 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy10.mail.unifiedlayer.com (Postfix) with ESMTP id E95901404BC for ; Thu, 15 Feb 2018 06:32:56 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id B1Ys1x00s2SSUrH011Yvz5; Thu, 15 Feb 2018 06:32:56 -0700
X-Authority-Analysis: v=2.2 cv=Rf/gMxlv c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=48vgC7mUAAAA:8 a=hh9n8B1FEgfrgkyi4zYA:9 a=QEXdDO2ut3YA:10 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:Cc:References:To:From:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=wYjqM0z0aMlv6z7Izgj0HZAovdlctrjpa/9AsIl8PkM=; b=V2o/wmdwAA3zSsjvHiWdEOuTBS 88Zxb58ak+XKT9XVeNWYI+nwWZHKtX6V6ZBdhRdgJN8nImOLZ+eVDTwLYmAQQ30OSky/0OP2qlFlO UYkwcjkuHepVO93N91wah3kNb;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:40022 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1emJee-003Cex-It; Thu, 15 Feb 2018 06:32:52 -0700
From: Lou Berger 
To: NetMod WG , draft-bierman-netmod-yang-data-ext@ietf.org
References: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net>
Cc: NetMod WG Chairs 
Message-ID: <84afbbd3-685c-ebac-f7cf-c3238f5fa7a6@labn.net>
Date: Thu, 15 Feb 2018 08:32:49 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1emJee-003Cex-It
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:40022
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Feb 2018 13:32:59 -0000

All,

     The adoption call for this document closed on Feb 8th.

Authors,

Please repost your document with only the 'filename' and date updated as 
draft-ietf-netmod-yang-data-ext-00. Please discuss on list any comments 
received during the adoption call and then capture the results of the 
discussions in the -01 rev. Finally, I believe the -01 rev should 
indicate that the document updates RFC8040.

Thank you,

Lou (and co-chairs)


On 1/25/2018 8:26 AM, Lou Berger wrote:
> Hi,
>
> This is the start of a *two* week poll on making
> draft-bierman-netmod-yang-data-ext a working group document. Please send
> email to the list indicating "yes/support" or "no/do not support".  If
> indicating no, please state your reservations with the document.  If
> yes, please also feel free to provide comments you'd like to see
> addressed once the document is a WG document.
>
> This poll ends on February 8.
>
> Thank you!
>
> Lou (and Co-chairs)
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>


From nobody Thu Feb 15 07:51:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8DE54126BF0; Thu, 15 Feb 2018 07:51:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZcMSuQguwPbE; Thu, 15 Feb 2018 07:51:26 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 46A41124C27; Thu, 15 Feb 2018 07:51:26 -0800 (PST)
Received: from pps.filterd (m0108163.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1FFoCYN017687; Thu, 15 Feb 2018 07:51:20 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=JJZbX3dKuun6b6vQhrAOjXkYsA2jiu0xl4gTfkTRW3Q=; b=Ey8/0MwZbHmQeaY9eMYv8jv+kGuM3auYhoUd+wOLCgI716fy8yaiKnOSqR0CgrELUvEQ f8qdpP7QxPGlnq7O6SHz+HWtUZleuAlaZSy6TmY+U7paYOPxMcHIt0LIF+AVk8JVcSKa 8/9wbqViSGk6PzKWsE+hyz3cZem02vz4GPHxUzylL0ocCJ5hfxnKkMuUalinjeIdtRfh Pw0U2ui1ldWzhjGS+AozX5lxjegTb6LIMusTFOtqyVtzZfWg14K2f274FxeHUbxLLYN4 JBOsJS0kfLOfzCQcQfmQJoftnOQ/act6TxT+cC/PPh7xynUqQzWQdK4eWmZUzzrueA7Q TQ== 
Received: from nam01-by2-obe.outbound.protection.outlook.com (mail-by2nam01lp0184.outbound.protection.outlook.com [216.32.181.184]) by mx0b-00273201.pphosted.com with ESMTP id 2g5d2b00bx-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Thu, 15 Feb 2018 07:51:20 -0800
Received: from BN6PR05MB3473.namprd05.prod.outlook.com (10.174.232.37) by BN6PR05MB2884.namprd05.prod.outlook.com (10.168.255.145) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Thu, 15 Feb 2018 15:51:17 +0000
Received: from BN6PR05MB3473.namprd05.prod.outlook.com ([10.174.232.37]) by BN6PR05MB3473.namprd05.prod.outlook.com ([10.174.232.37]) with mapi id 15.20.0527.006; Thu, 15 Feb 2018 15:51:17 +0000
From: Kent Watsen 
To: Alexander Clemm , Juergen Schoenwaelder 
CC: NETCONF WG , NETMOD WG 
Thread-Topic: [Netconf] [netmod]  LC on YANG Library (bis)
Thread-Index: AQHTpQOkNnE56QWOok2Cl9au3Xfg+6OiwAqAgAKLvoA=
Date: Thu, 15 Feb 2018 15:51:17 +0000
Message-ID: 
References:  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com> <20180213194821.cwbwwmy7bqhvkfsd@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com>
In-Reply-To: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.13]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; BN6PR05MB2884; 6:+UoItJoCMbEmNlOXI54/StwhwXoMw29HSe8KoK7bz0LYmQqzbYUrmlfQSd0Ofqnld85i6CckBmggJwjl0SJvibf2Sl+6whC0rSxfznzSfdfEde38VyIaeigYJeyfM9JpTRBexV0Mi1ZBEuvMFX4M8tIoX21dyA1MHIJdeyCxqD31yQ/gtMxQqjiLkF2ndQxJ2nBZTLYfJ8UASH4avGSZIeBod7IiOWBqq9KzFEGImRL3XHHJGm0tjMRH/3CKqBGoXdjGyGEaOVv1KchyFQ084fJ9u/sD6+BbBCKY+yU3viA/8Sna2KgnOiosI6E1MEgdP/OPJ/FysCl2cGrKuuqrNmH+mglGRFUEZiUPCDdk9iKnN5k5XD4v15shXiPqOfWO; 5:CBT1s1hbOwDwhp51O/VYV6yRULxaGh6K1C8IfxlHyjjRJLcodYJggMB/2medB6RSXkOs5BEwH1wfoJFg2hXaXSNqIOUtckdRQrwgRUNEIcd/G0Qr2bKUGSfQKOsniI9SIRKFs+aPOzmAUrzaP7tUXpWO6yWKpn5wy09D7K4fVGY=; 24:cooEBxIlvwS5/CZnHYE6spJoR/A5jrvfLaydxw3a7HqpxiUkQpRYknbExjulvlqEUq+lZLBYA6IO506YSp4PUT7SJgCs72C2tBTMybiGVBA=; 7:8ZpTrXBCMagNbmDV8yzfong69x5FAEbgDbajq0nolqFbWbE2dyZk/6C4Nz+bAA7ZbkhHAsON1T18SG/DgJe98ws0RJwXKaUXgbs0ea401QPZGbX01sok1Gt07TtgF+V3XrnfjqT6JHSBs3Q2wuQ1s8qYxzvqCnpzud6pzgIvd37raz3U7C9VZ512PdPvnLAvflpCfjjNpWlEeOzSjISHKf73XiOfs2YypnsulBW6bsi0aRRdSUyEEXQH4/7w2EId
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 5dc21368-e3cb-42de-59b7-08d5748bf387
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:BN6PR05MB2884; 
x-ms-traffictypediagnostic: BN6PR05MB2884:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(158342451672863)(10436049006162)(50582790962513)(85827821059158); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001026)(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231101)(944501161)(6055026)(6041288)(20161123564045)(20161123560045)(20161123558120)(20161123562045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:BN6PR05MB2884; BCL:0; PCL:0; RULEID:; SRVR:BN6PR05MB2884; 
x-forefront-prvs: 058441C12A
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(366004)(39380400002)(346002)(376002)(39860400002)(189003)(199004)(13464003)(2906002)(6116002)(2900100001)(105586002)(966005)(6246003)(8676002)(316002)(478600001)(2950100002)(3846002)(81166006)(81156014)(14454004)(5660300001)(8936002)(102836004)(6506007)(54906003)(36756003)(25786009)(53546011)(4326008)(76176011)(106356001)(53936002)(305945005)(3280700002)(6306002)(6512007)(6436002)(6486002)(58126008)(110136005)(99286004)(7736002)(93886005)(83506002)(86362001)(26005)(575784001)(97736004)(68736007)(186003)(3660700001)(82746002)(229853002)(77096007)(83716003)(33656002)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:BN6PR05MB2884; H:BN6PR05MB3473.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)
x-microsoft-antispam-message-info: JhlcEkJRSKxfbc/wJGKoYrpYrZqeIEjijWk/WdlxZfVxwXPNq8NBU62sFPKby57pczjDAV6RnyP9GoEp1S1SSQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 5dc21368-e3cb-42de-59b7-08d5748bf387
X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Feb 2018 15:51:17.7490 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR05MB2884
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-15_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802150194
Archived-At: 
Subject: Re: [netmod] [Netconf]   LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Feb 2018 15:51:30 -0000

QWxleCwNCg0KV2hhdCB5b3Ugd2FudCBtYWtlcyBzZW5zZSB0byBtZS4gIEhvdyBhYm91dCBwdXR0
aW5nIGl0IGludG8gYW4gSS1EIHRoYXQgYXVnbWVudHMgdGhlIHlhbmcgbGlicmFyeSBiaXM/ICBJ
dCBkb2Vzbid0IGhhdmUgdG8gYmUgaW4gdGhpcyBkb2N1bWVudCwgcmlnaHQ/DQoNCktlbnQNCg0K
PT09PT0gb3JpZ2luYWwgbWVzc2FnZSA9PT09PQ0KDQpXZWxsLCB3ZSBuZWVkIGEgZ2VuZXJhbCBz
b2x1dGlvbiBmb3IgdGhhdC4gIFlBTkctcHVzaCBpcyBqdXN0IG9uZSB1c2UgY2FzZS4gIFRoZXJl
IGFyZSBvdGhlciBjYXNlcyB3aGVyZSB0aGVyZSB3aWxsIGJlICJtZXRhZGF0YSIgKHRoYXQgZG9l
cyBub3QgcGVydGFpbiB0byBpbnN0YW5jZSBkYXRhKSAgYW5kIGNhcGFiaWxpdGllcyB0aGF0IGNs
aWVudHMgd2FudCB0byBkaXNjb3Zlci4gIFlBTkcgbGlicmFyeSAoaW4gaXRzZWxmIHByb3ZpZGlu
ZyAibWV0YWRhdGEiIGFib3V0IHdoYXQgYSBzZXJ2ZXIgc3VwcG9ydHMgYW5kIGlzIGNhcGFibGUg
b2YpIGlzIGFuIGV4Y2VsbGVudCBwbGFjZSB0byBtYWludGFpbiB0aGlzIGluZm9ybWF0aW9uLiAg
SXQgYWxzbyBwcm92aWRlcyB0aGUgb3Bwb3J0dW5pdHkgdG8gYmUgc3lzdGVtaWMgYWJvdXQgaXQs
IGFzIG9wcG9zZWQgdG8gcmVxdWlyaW5nIGV2ZXJ5b25lIHRvIGRlZmluZSB0aGVpciBvd24gbGl0
dGxlIGN1c3RvbSBleHRlbnNpb25zLiAgDQotLS0gQWxleA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVz
c2FnZS0tLS0tDQo+IEZyb206IEp1ZXJnZW4gU2Nob2Vud2FlbGRlciBbbWFpbHRvOmouc2Nob2Vu
d2FlbGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZV0NCj4gU2VudDogVHVlc2RheSwgRmVicnVhcnkg
MTMsIDIwMTggMTE6NDggQU0NCj4gVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVyLmNsZW1t
QGh1YXdlaS5jb20+DQo+IENjOiBNYWhlc2ggSmV0aGFuYW5kYW5pIDxtamV0aGFuYW5kYW5pQGdt
YWlsLmNvbT47IE5FVENPTkYgV0cNCj4gPG5ldGNvbmZAaWV0Zi5vcmc+OyBORVRNT0QgV0cgPG5l
dG1vZEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtuZXRtb2RdIFtOZXRjb25mXSBMQyBvbiBZ
QU5HIExpYnJhcnkgKGJpcykNCj4gDQo+IEFsZXhhbmRlciwNCj4gDQo+IEkgZGlzYWdyZWUuIFRo
aXMgWUFORyBMaWJyYXJ5IGlzIG1hbmRhdG9yeSBmb3IgYWxsIGltcGxlbWVudGF0aW9uczsgd2hh
dCB5b3UgdGFsaw0KPiBhYm91dCBzZWVtcyB0byBjb25jZXJuIG9ubHkgaW1wbGVtZW50YXRpb25z
IHRoYXQgc3VwcG9ydCBZQU5HIHB1c2guIEhlbmNlLA0KPiB0aGlzIGlzIGFuIGV4dGVuc2lvbiB0
aGF0IHNob3VsZCBnbyBpbiBpdHMgb3duIG1vZHVsZS4NCj4gDQo+IC9qcw0KPiANCj4gT24gVHVl
LCBGZWIgMTMsIDIwMTggYXQgMDc6Mzg6MzFQTSArMDAwMCwgQWxleGFuZGVyIENsZW1tIHdyb3Rl
Og0KPiA+IEhpLA0KPiA+DQo+ID4gSSBoYXZlIHRha2VuIGEgbG9vayBhdCB0aGlzIGRvY3VtZW50
Lg0KPiA+DQo+ID4gTXkgbWFpbiBjb21tZW50IGlzIHRoYXQgb25lIGFzcGVjdCB0aGF0IGlzIG1p
c3NpbmcsIHRoYXQgSSBiZWxpZXZlIHNob3VsZCBiZQ0KPiBhZGRlZCwgY29uY2VybnMgdGhlIGlu
Y2x1c2lvbiBvZiBjZXJ0YWluIG1ldGFkYXRhIGFib3V0IHRoZSBtb2R1bGVzLg0KPiBTcGVjaWZp
Y2FsbHksIGluIHRoZSBjb250ZXh0IG9mIFlBTkctUHVzaCB3ZSBoYWQgYSBkaXNjdXNzaW9uIGFi
b3V0IGJlaW5nIGFibGUgdG8NCj4gbWFyayBub2RlcyB0aGF0IGFyZSBub3RpZmlhYmxlIG9uIGNo
YW5nZS4gIFRoaXMgaXMganVzdCBvbmUgcGFydGljdWxhciB1c2UgY2FzZSBvZiBhDQo+IG1vcmUg
Z2VuZXJhbCBpc3N1ZTsgaW4gWUFORy1QdXNoIGFmdGVyIG11Y2ggZGViYXRlIHRoZSBjb25jbHVz
aW9uIHdhcyBmb3Igbm93DQo+IHRvIHNpbXBseSBtYWtlIGltcGxlbWVudG9ycyBhd2FyZSBvZiB0
aGlzIGlzc3VlIGFuZCBhZHZpc2UgdGhhdCBhIHNvbHV0aW9uIHRvDQo+IHRoaXMgbXVzdCBiZSBw
cm92aWRlZCwgd2l0aCB0aGUgY2xlYXIgdW5kZXJzdGFuZGluZyB0aGF0IGV2ZW50dWFsbHkgYSBz
dGFuZGFyZA0KPiBzb2x1dGlvbiBzaG91bGQgYmUgZGVmaW5lZC4NCj4gPg0KPiA+IFNpbmNlIHRo
ZSBnb2FsIG9mIFlBTkctTGlicmFyeSBpcyB0byBhbGxvdyBjbGllbnRzIHRvIGZpbmQgb3V0IHdo
YXQgaXMgYWN0dWFsbHkNCj4gc3VwcG9ydGVkIG9uIGEgZ2l2ZW4gc2VydmVyLCB0aGlzIGlzIHRo
ZSByaWdodCBwbGFjZSB0byBrZWVwIHRoaXMgaW5mb3JtYXRpb24uICBPbmUNCj4gcG9zc2libGUg
d2F5IHRvIGFkZHJlc3MgdGhpcyB3b3VsZCBiZSwgZm9yIGEgZ2l2ZW4gbW9kdWxlLCB0byBtYWlu
dGFpbiBhIGxpc3Qgb2YNCj4gIm1ldGEtaW5mbyIsIHdpdGggYSBrZXkgIm1ldGEtdGFnIiwgYW5k
IGEgbGlzdCB3aXRoIHJlZmVyZW5jZXMgdG8gdGhlIG5vZGVzIHRvDQo+IHdoaWNoIHRoZSBtZXRh
ZGF0YSBhcHBsaWVzLiAgSW4gdGhlIGNhc2Ugb2Ygbm90aWZpYWJsZS1vbi1jaGFuZ2UsIHlvdSB3
b3VsZCBoYXZlDQo+IGEgbGlzdCB3aXRoIG9uZSBlbnRyeSAibm90aWZpYWJsZS1vbi1jaGFuZ2Ui
LCBhbmQgdGhlbiB0aGUgbGlzdCB3aXRoIHRoZSBub2RlDQo+IGRlZmluaXRpb25zIHRvIHdoaWNo
IHRoaXMgdGFnIGFwcGxpZXMuDQo+ID4NCj4gPiBFZGl0b3JpYWwgbml0Og0KPiA+IDJuZCBwYXJh
Z3JhcGggSW50cm9kdWN0aW9uOiBpbmZvcm1hdG9uIC0tPiBpbmZvcm1hdGlvbg0KPiA+DQo+ID4g
VGhhbmtzDQo+ID4gLS0tIEFsZXgNCj4gPg0KPiA+IEZyb206IE5ldGNvbmYgW21haWx0bzpuZXRj
b25mLWJvdW5jZXNAaWV0Zi5vcmddIE9uIEJlaGFsZiBPZiBNYWhlc2gNCj4gPiBKZXRoYW5hbmRh
bmkNCj4gPiBTZW50OiBUaHVyc2RheSwgRmVicnVhcnkgMDEsIDIwMTggMTE6MDAgQU0NCj4gPiBU
bzogTkVUQ09ORiBXRyA8bmV0Y29uZkBpZXRmLm9yZz4NCj4gPiBDYzogTkVUTU9EIFdHIDxuZXRt
b2RAaWV0Zi5vcmc+DQo+ID4gU3ViamVjdDogW05ldGNvbmZdIExDIG9uIFlBTkcgTGlicmFyeSAo
YmlzKQ0KPiA+DQo+ID4gV0csDQo+ID4NCj4gPiBUaGUgYXV0aG9ycyBvZiByZmM3ODk1YmlzIGhh
dmUgaW5kaWNhdGVkIHRoYXQgdGhleSBiZWxpZXZlIHRoZSBkb2N1bWVudCBpcw0KPiByZWFkeSBm
b3IgTENbMV0uDQo+ID4NCj4gPiBUaGlzIHN0YXJ0cyBhIHR3byB3ZWVrIExDIG9uIHRoZSBkcmFm
dDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3Rv
b2xzLmlldGYub3JnX2h0bWxfZHJhZnQtMkRpZXRmLTJEJmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3Vo
cjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhx
bjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1vQUxiN0xLclVrS0RzSjA2VklNM0FueF9pRDA1QmtteGph
TTBUWkYxaGVBJnM9TmFZOFI5REJoSW5aUUF4TDM1X0tqRnplWUhmeVRPVkpMbk1IQUtHZUtGMCZl
PQ0KPiBuZXRjb25mLXJmYzc4OTViaXMtMDQ+LiBUaGUgTEMgd2lsbCBlbmQgb24gRmVicnVhcnkg
MTUuDQo+ID4NCj4gPiBQbGVhc2Ugc2VuZCB5b3VyIGNvbW1lbnRzIG9uIHRoaXMgdGhyZWFkLiBS
ZXZpZXdzIG9mIHRoZSBkb2N1bWVudCwgYW5kDQo+IHN0YXRlbWVudCBvZiBzdXBwb3J0IGFyZSBw
YXJ0aWN1bGFybHkgaGVscGZ1bCB0byB0aGUgYXV0aG9ycy4gSWYgeW91IGhhdmUgY29uY2VybnMN
Cj4gYWJvdXQgdGhlIGRvY3VtZW50LCBwbGVhc2Ugc3RhdGUgdGhvc2UgdG9vLg0KPiA+DQo+ID4g
QXV0aG9ycyBwbGVhc2UgaW5kaWNhdGUgaWYgeW91IGFyZSBhd2FyZSBvZiBhbnkgSVBSIG9uIHRo
ZSBkb2N1bWVudC4NCj4gPg0KPiA+IFRoYW5rcy4NCj4gPg0KPiA+IFsxXQ0KPiA+IGh0dHBzOi8v
dXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3Jn
X21haWwtMkRhcmNoaXZlX3dlYl9uZXRjb25mX2N1cnJlbnRfbXNnMTM5ODAuaHRtbCZkPUR3SUNB
ZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhu
SlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09b0FMYjdMS3JVa0tEc0owNlZJ
TTNBbnhfaUQwNUJrbXhqYU0wVFpGMWhlQSZzPVFtNlU5Q0lwREhTMGpxVW5HR1psOFgwNXFlQV9W
dk15eXVPdHdESEJmMU0mZT0NCj4gPg0KPiA+IE1haGVzaCAmIEtlbnQNCj4gPg0KPiANCj4gPiBf
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiA+IG5ldG1v
ZCBtYWlsaW5nIGxpc3QNCj4gPiBuZXRtb2RAaWV0Zi5vcmcNCj4gPiBodHRwczovL3VybGRlZmVu
c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu
X2xpc3RpbmZvX25ldG1vZCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1u
ZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpk
Y1pvJm09b0FMYjdMS3JVa0tEc0owNlZJTTNBbnhfaUQwNUJrbXhqYU0wVFpGMWhlQSZzPUdQZHFs
aW9fMmxhUWw5M2pvYkdYZ1hPcy1XcG91eEUxVzRNZUd4dmg1NTgmZT0NCj4gDQo+IA0KPiAtLQ0K
PiBKdWVyZ2VuIFNjaG9lbndhZWxkZXIgICAgICAgICAgIEphY29icyBVbml2ZXJzaXR5IEJyZW1l
biBnR21iSA0KPiBQaG9uZTogKzQ5IDQyMSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEg
fCAyODc1OSBCcmVtZW4gfCBHZXJtYW55DQo+IEZheDogICArNDkgNDIxIDIwMCAzMTAzICAgICAg
ICAgPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
d3d3LmphY29icy0yRHVuaXZlcnNpdHkuZGVfJmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTY2Jm
aDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ
YUdUdmpJU2xhSmRjWm8mbT1vQUxiN0xLclVrS0RzSjA2VklNM0FueF9pRDA1QmtteGphTTBUWkYx
aGVBJnM9ejlWOGt5dG85RWd5R3AzSnN3QTJRYkpCU1FkM2VjemZjaXp0Y0MxZ050NCZlPT4NCg0K
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCk5ldGNvbmYg
bWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnDQpodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv
X25ldGNvbmYmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRY
Y1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPW9B
TGI3TEtyVWtLRHNKMDZWSU0zQW54X2lEMDVCa214amFNMFRaRjFoZUEmcz1qOWVkbHBJR2J1RWVT
N3lNclY0aVJXWTd2dnEwYzJGcUllbXVIZjE3TExVJmU9DQoNCg0K


From nobody Thu Feb 15 09:03:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED7FA12AF84; Thu, 15 Feb 2018 09:03:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -12.52
X-Spam-Level: 
X-Spam-Status: No, score=-12.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id d-VX5glVv7dJ; Thu, 15 Feb 2018 09:03:35 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C2E74129C56; Thu, 15 Feb 2018 09:03:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12709; q=dns/txt; s=iport; t=1518714215; x=1519923815; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=PS8060EmCJ1i+3pThgrT4hHiRz9KjQVWG6NeoaUjQBg=; b=OXWVKSEo99PIUjS2nw7cA1feaiRP+pZS0Vcm4p14PtdCkCUe2pAKt1Y+ WNE0Kjdh+C6+cX2VN8pa3zv9R3Q5R+kO/iPmA38CIvbj1PlQ5xLojR4nt BmG1LNXFcqEVPaUDIkPmtgMET+AHicHIZjuZEXdmcyAjVFMSU9h+zP4Fi w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A/AQAivIVa/xbLJq1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJagV5wKINliiV0jxKBF5BphVyCGAoYAQmESk8CgxYYAQIBAQE?= =?us-ascii?q?BAQECaygJBYUWAQEEAQEhSxsLDgonAwICJx8RBgEMBgIBAYoxEK5KgicmhFuDe?= =?us-ascii?q?4ITAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWFA4N+ghGDBYMvAQEBARmBNgEBgzW?= =?us-ascii?q?CZQWaKYoJCYggjWWCH4Yqg3Mmh2SOBYF+iBmBPB85gVEzGggbFT2CRoIcgltBN?= =?us-ascii?q?wEBAYt8gj4BAQE?=
X-IronPort-AV: E=Sophos;i="5.46,517,1511827200"; d="scan'208,217";a="2092842"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Feb 2018 17:03:32 +0000
Received: from [10.63.23.94] (dhcp-ensft1-uk-vla370-10-63-23-94.cisco.com [10.63.23.94]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1FH3W6w010199; Thu, 15 Feb 2018 17:03:32 GMT
To: Kent Watsen , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net>
From: Robert Wilton 
Message-ID: <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com>
Date: Thu, 15 Feb 2018 17:03:32 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net>
Content-Type: multipart/alternative; boundary="------------F409F3EC81B75D9D6E5612CD"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Feb 2018 17:03:38 -0000

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

I should add, as a contributor, I have read this document and think that 
is ready for advancement.

I have three minor comments:

1) module "feature" in YANG library is a leaf-list, but currently it is 
a list in YANG libary bis. I suspect that this is due to one of the 
incarnations when it contained additional information.  I think that we 
should revert it back to being a leaf list for consistency.

2) Lada recommended that module "deviation" be made a leaf-list. I also 
support changing this for consistency with "feature" above, but don't 
feel too strongly on this one.

3) I think the "modules" list is also allowed to included modules that 
don't actually contain any nodes that require implementation.  Hence, it 
might be useful of the "modules" description statement explicitly stated 
this.  I.e. perhaps something like:

"This list may contain modules that do not contain any schema nodes that 
require implementation.  For example, it could contain a module that 
only defines types and not any data nodes, RPCs, actions, notifications, 
or deviations."

Thanks,
Rob


On 02/02/2018 13:51, Kent Watsen wrote:
>
> As co-author, I am not aware of any IPR related to this document.
>
> As a contributor, I have read this document and think that it is ready 
> for advancement.
>
> Kent
>
> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton" 
>  on behalf 
> of rwilton@cisco.com > wrote:
>
> I am not aware of any IPR related to this document.
>
> Thanks,
> Rob
>
> On 01/02/2018 18:59, Mahesh Jethanandani wrote:
>
>     WG,
>
>     The authors of rfc7895bis have indicated that they believe the
>     document is ready for LC[1].
>
>     This starts a two week LC on the draft
>     .
>     The LC will end on February 15.
>
>     Please send your comments on this thread. Reviews of the document,
>     and statement of support are particularly helpful to the authors.
>     If you have concerns about the document, please state those too.
>
>     Authors please indicate if you are aware of any IPR on the document.
>
>     Thanks.
>
>     [1]
>     https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>     
>
>     Mahesh & Kent
>
>
>
>
>     _______________________________________________
>
>     Netconf mailing list
>
>     Netconf@ietf.org 
>
>     https://www.ietf.org/mailman/listinfo/netconf
>     
>
>
>


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


  
    
  
  
    
I should add, as a contributor, I have read this document and
      think that is ready for advancement.

    
I have three minor comments:

    
1) module "feature" in YANG library is a leaf-list, but currently
      it is a list in YANG libary bis. I suspect that this is due to one
      of the incarnations when it contained additional information.  I
      think that we should revert it back to being a leaf list for
      consistency.

    
2) Lada recommended that module "deviation" be made a leaf-list. 
      I also support changing this for consistency with "feature" above,
      but don't feel too strongly on this one.

    
3) I think the "modules" list is also allowed to included modules
      that don't actually contain any nodes that require
      implementation.  Hence, it might be useful of the "modules"
      description statement explicitly stated this.  I.e. perhaps
      something like:

      

      "This list may contain modules that do not contain any schema
        nodes that require implementation.  For example, it could
        contain a module that only defines types and not any data nodes,
        RPCs, actions, notifications, or deviations."

    Thanks,

    Rob

    

    

    
On 02/02/2018 13:51, Kent Watsen wrote:

    

    

      
      
      
      
      
      

        
As
            co-author, I am not aware of any IPR related to this
            document.

        
 

        
As a
            contributor, I have read this document and think that it is
            ready for advancement.

        
 

        
Kent

        
 

        
 

        

          

            
On 2/2/18, 4:30 AM, "Netconf on behalf
              of Robert Wilton" <netconf-bounces@ietf.org on
              behalf of
              rwilton@cisco.com>
              wrote:

          

        

        

          
 

        

        
I am not aware
          of any IPR related to this document.

          

          Thanks,

          Rob

          

          

        

          
On 01/02/2018 18:59, Mahesh Jethanandani
            wrote:

        

        

          
WG, 

          

            
 

          

          

            
The authors of rfc7895bis have
              indicated that they believe the document is ready for
              LC[1].

          

          

            
 

          

          

            
This starts a two week LC on the draft. The LC will end on
              February 15. 

          

          

            
 

          

          

            
Please send your comments on this
              thread. Reviews of the document, and statement of support
              are particularly helpful to the authors. If you have
              concerns about the document, please state those too.

          

          

            
 

          

          

            
Authors please indicate if you are
              aware of any IPR on the document.

          

          

            
 

          

          

            
Thanks.

          

          

            
 

          

          
          

            
 

            

              

                
Mahesh & Kent

              

            

            
 

          

          


            

            

            

          
_______________________________________________

          
Netconf mailing list

          
Netconf@ietf.org

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

        

        


          

          

      

    

    

  


--------------F409F3EC81B75D9D6E5612CD--


From nobody Thu Feb 15 10:10:08 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3201412D574; Thu, 15 Feb 2018 10:10:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O6Bs9RNm4wJU; Thu, 15 Feb 2018 10:09:59 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D15C4127863; Thu, 15 Feb 2018 10:09:58 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9E90D60; Thu, 15 Feb 2018 19:09:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id sR8se7H9TnR6; Thu, 15 Feb 2018 19:09:56 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 Feb 2018 19:09:57 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id 845D420151; Thu, 15 Feb 2018 19:09:57 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id nSkmnU32GGC7; Thu, 15 Feb 2018 19:09:56 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id B740F20150; Thu, 15 Feb 2018 19:09:56 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 21E9842490A5; Thu, 15 Feb 2018 19:09:56 +0100 (CET)
Date: Thu, 15 Feb 2018 19:09:55 +0100
From: Juergen Schoenwaelder 
To: Robert Wilton 
Cc: Kent Watsen , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
Message-ID: <20180215180955.idnyuacivy6h3lrf@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Robert Wilton , Kent Watsen , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
X-Clacks-Overhead: GNU Terry Pratchett
Content-Transfer-Encoding: 8bit
In-Reply-To: <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Feb 2018 18:10:02 -0000

On Thu, Feb 15, 2018 at 05:03:32PM +0000, Robert Wilton wrote:
> 
> 1) module "feature" in YANG library is a leaf-list, but currently it is a
> list in YANG libary bis. I suspect that this is due to one of the
> incarnations when it contained additional information.  I think that we
> should revert it back to being a leaf list for consistency.
> 
> 2) Lada recommended that module "deviation" be made a leaf-list. I also
> support changing this for consistency with "feature" above, but don't feel
> too strongly on this one.
>

I suggest we either make both leaf-lists or keep both as lists. I am
fine with making both lead-lists.

/js

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


From nobody Thu Feb 15 11:03:09 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 96E7F12D574 for ; Thu, 15 Feb 2018 11:03:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uFZp8Dvb4ge0 for ; Thu, 15 Feb 2018 11:03:05 -0800 (PST)
Received: from mail-lf0-x22d.google.com (mail-lf0-x22d.google.com [IPv6:2a00:1450:4010:c07::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4F071120227 for ; Thu, 15 Feb 2018 11:03:05 -0800 (PST)
Received: by mail-lf0-x22d.google.com with SMTP id 37so959001lfs.7 for ; Thu, 15 Feb 2018 11:03:05 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=3qHtbzPF7nWn1gpPhhr2/sz+OIAkzj3zSMTMN3/QSJg=; b=CVOIj9zukiw4DZmHqOfB8e8nULBcFFaTb3ztS8xTIaH4r5WGm0RD7vRstyRd8dEz2c mISCIjqg2HLhCKnT/QNon+iXQgcJnIAQ/SBRr2usi8P8zMnZDRW0nnC1xqRkVIcsrd89 dH8JLT1lfX/lg/ko+FLGaJTwvy89xCXzAqWufxVWPuogngJnr9AjqQDev1qlHgYYwwAW UPJNJurRava1EiRd2VmP7fUgkDEY5EX8ibs+nvwsimqVKtR/TvcC3LpXIU5szRF9LTDV 9RJpnhiApDLknCp8MdsONJ/OtDxa5jxJL9bpwssLwxaa8vloHO1k2w1cyXr2vsIwClB/ Q4sA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=3qHtbzPF7nWn1gpPhhr2/sz+OIAkzj3zSMTMN3/QSJg=; b=surWQsXHnBX4IDb0HSc+xXEGJcqLLmSH4Xhwh2CGUnVaIH2S39FdazZygkktlMQii/ zA1tDPwtjLYZyV0qTDh9YzcPg6bK6H4y7QLobGGZ4Mdnwc40gEsdU9UgB1eF5LZCnJGO Hl8bcsai4YDXICMOelld+WD6RRUhBAiJ7YI92HyssHON9T8PqzZ09fWBNaGYNkJsI1qv XeWIxuaXhknUe1WunM2s8zj2lp/9MwI4ONukhUXA+ZT6+63AmrAgkzP7iUJP0Y+xTZd9 +INKeBMNsXnRwMv4hgn4kU2D2rxgWum5TMSHlYNygbmmyXoJbzqdTeEaV/S3i6iNUM9X w3LQ==
X-Gm-Message-State: APf1xPDwBbXqO4pGlraquEZfReQwrS58yTVNwaa9QQIKIbkkpkOZ0LFi I93R/YGwHQ3HQQ4tLe/Tuy6Jf7D3qKBIsFgK0yHpOg==
X-Google-Smtp-Source: AH8x225Y2sU5kNOJDHrlXJIYg94CaCZdUMuHQyLObmIH/Gum7LAxWet+ewBVWH/oNAreQgQ0zSwN/TrMhGK/F2hZOgk=
X-Received: by 10.46.47.13 with SMTP id v13mr2419151ljv.15.1518721383606; Thu, 15 Feb 2018 11:03:03 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Thu, 15 Feb 2018 11:03:02 -0800 (PST)
In-Reply-To: <20180215180955.idnyuacivy6h3lrf@elstar.local>
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com> <20180215180955.idnyuacivy6h3lrf@elstar.local>
From: Andy Bierman 
Date: Thu, 15 Feb 2018 11:03:02 -0800
Message-ID: 
To: Juergen Schoenwaelder , Robert Wilton , Kent Watsen , Mahesh Jethanandani ,  NETCONF WG , NETMOD WG 
Content-Type: multipart/alternative; boundary="089e082f330c953f34056544e042"
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Feb 2018 19:03:07 -0000

--089e082f330c953f34056544e042
Content-Type: text/plain; charset="UTF-8"

On Thu, Feb 15, 2018 at 10:09 AM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Feb 15, 2018 at 05:03:32PM +0000, Robert Wilton wrote:
> >
> > 1) module "feature" in YANG library is a leaf-list, but currently it is a
> > list in YANG libary bis. I suspect that this is due to one of the
> > incarnations when it contained additional information.  I think that we
> > should revert it back to being a leaf list for consistency.
> >
> > 2) Lada recommended that module "deviation" be made a leaf-list. I also
> > support changing this for consistency with "feature" above, but don't
> feel
> > too strongly on this one.
> >
>
> I suggest we either make both leaf-lists or keep both as lists. I am
> fine with making both lead-lists.
>
>

The reason the deviation is a list is because it has a name and revision.
Or it did until it was removed.

I prefer to keep the contents of the "module" list the
same as RFC 7895.  The "improvement" is much worse --
harder to use by clients and provides less information to clients.



> /js
>


Andy


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

--089e082f330c953f34056544e042
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable




On Thu, Feb 15, 2018 at 10:09 AM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Feb 15, 2018 at 05:03:32PM +0000, Robert Wi=
lton wrote:

>

> 1) module "feature" in YANG library is a leaf-list, but curr=
ently it is a

> list in YANG libary bis. I suspect that this is due to one of the

> incarnations when it contained additional information.=C2=A0 I think t=
hat we

> should revert it back to being a leaf list for consistency.

>

> 2) Lada recommended that module "deviation" be made a leaf-l=
ist. I also

> support changing this for consistency with "feature" above, =
but don't feel

> too strongly on this one.

>



I suggest we either make both leaf-lists or keep both as lists. I am

fine with making both lead-lists.




The reason the deviation is a list is=
 because it has a name and revision.
Or it did until it was remov=
ed.

I prefer to keep the contents of the "mod=
ule" list the
same as RFC 7895.=C2=A0 The "improvement&=
quot; is much worse --
harder to use by clients and provides less=
 information to clients.

=C2=A0

/js


Andy
=C2=A0
=



--

Juergen Schoenwaelder=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Jacobs Univer=
sity Bremen gGmbH

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

Fax:=C2=A0 =C2=A0+49 421 200 3103=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0<https://www.jacobs-university.de/>



_______________________________________________

Netconf mailing list

Netconf@ietf.org

https://www.ietf.org/mailman/listinfo/netconf<=
br>




--089e082f330c953f34056544e042--


From nobody Thu Feb 15 12:12:23 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8EC1A12946D; Thu, 15 Feb 2018 12:12:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id A9MWhOyw4VuY; Thu, 15 Feb 2018 12:12:19 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BB032124D68; Thu, 15 Feb 2018 12:12:19 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 84C59B71; Thu, 15 Feb 2018 21:12:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id cXe86kfbHsqG; Thu, 15 Feb 2018 21:12:17 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Thu, 15 Feb 2018 21:12:18 +0100 (CET)
Received: from localhost (demetrius3.jacobs-university.de [212.201.44.48]) by hermes.jacobs-university.de (Postfix) with ESMTP id 6906520152; Thu, 15 Feb 2018 21:12:18 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius3.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id DuUdwIuAO-SR; Thu, 15 Feb 2018 21:12:18 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 07FED20151; Thu, 15 Feb 2018 21:12:17 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 024BC4249411; Thu, 15 Feb 2018 21:12:15 +0100 (CET)
Date: Thu, 15 Feb 2018 21:12:15 +0100
From: Juergen Schoenwaelder 
To: Andy Bierman 
Cc: Robert Wilton , Kent Watsen , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
Message-ID: <20180215201215.2fvrs3nykkpdd3fs@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Andy Bierman , Robert Wilton , Kent Watsen , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com> <20180215180955.idnyuacivy6h3lrf@elstar.local> 
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: 
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Feb 2018 20:12:22 -0000

On Thu, Feb 15, 2018 at 11:03:02AM -0800, Andy Bierman wrote:
> 
> The reason the deviation is a list is because it has a name and revision.
> Or it did until it was removed.
>

> I prefer to keep the contents of the "module" list the
> same as RFC 7895.  The "improvement" is much worse --
> harder to use by clients and provides less information to clients.

Which "improvement" do you mean? Which information is lost? In which
situations are things harder to use?

/js

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


From nobody Thu Feb 15 12:50:46 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EE44112D830 for ; Thu, 15 Feb 2018 12:50:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level: 
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w0dEQFNigZvy for ; Thu, 15 Feb 2018 12:50:37 -0800 (PST)
Received: from mail-lf0-x236.google.com (mail-lf0-x236.google.com [IPv6:2a00:1450:4010:c07::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E277F12D831 for ; Thu, 15 Feb 2018 12:50:36 -0800 (PST)
Received: by mail-lf0-x236.google.com with SMTP id f136so1350996lff.8 for ; Thu, 15 Feb 2018 12:50:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=OljBNHVSbvHIo5zvINyI0hVT7DTJkXFnP8/XajS3+S0=; b=abUmU+FbFVisoVsarXW9ZQjFteCtapK7QPAMMUImZePjek6SKxw5IUh8V06I7o2DjF 9DaVbfQOb7F+tw7J/6VbS05EFPUn9tFvuALdVeAI8TtngaT4lwjDuMsW1bl7YgNl/p9e SvdyKFFsX8NQvsGjLoVgbOka5nM1t328ug5dGYi1zRCR6YQwbeLmL+q8HqvcqlMJgCgd X5AaJAwOxVCm2ZAkKMl8SrEimBPOLnCDFbMP+iQ4YsOr4zWr4hkF5yMcksdJrrvAeDaC 5qD2qsTzNwy7A0/hOcs6t9fs055dJhP2WZL8591Y27y9w87P4i6pEjISQUZSg2YwhbZN Mnpg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=OljBNHVSbvHIo5zvINyI0hVT7DTJkXFnP8/XajS3+S0=; b=BzU/UJkOUtmeXDJ6SXu7y2rHvF3OkQAbopbdqInvQZIOXFl9XYNDKHzKvh8OLy2Wlq BEkxEaWjSYbU23iTKx8C1m4T5WfAAwOWnsvxhb1KdHQkPSBpRMR8zXQw/UYPOWzQzcEj 8SEGQK2P3LVGpOq6S6UaokANRJr7WIV5kaeLeEDUSsTrR2X/B8/qq+ntSjyXOlNFOrJF V9lpC0auY2oo7yyazN+2EQd5BNh72As3P/IDDr9UWtp7ff663btBRA+WdF4w2SqDMcfH Re9V0ZPQ4d//WxBOGUvtxeyw6mE+icxiuQir5JBoT+xbEqh6kPhJEROshrV3ap/Oofnk SDdg==
X-Gm-Message-State: APf1xPCOctj6Pf/XaGpOg2lJvW5VIdNaQTlinbpypTLfwjX+cOa6eLDT jOnPTnwlBCP9FjJdZAJ2d84VjCLuSSK5gT33SNsJmA==
X-Google-Smtp-Source: AH8x224spfF+FodY5tkM4qCwjES5jLM6j/SCQtbiZ5v6s1dHCf4JcOdcZI0ogsAA4mwAJE/+b+rmuZKr6+9fS74aTyw=
X-Received: by 10.25.26.200 with SMTP id a191mr2376492lfa.35.1518727834999; Thu, 15 Feb 2018 12:50:34 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Thu, 15 Feb 2018 12:50:34 -0800 (PST)
In-Reply-To: <20180215201215.2fvrs3nykkpdd3fs@elstar.local>
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com> <20180215180955.idnyuacivy6h3lrf@elstar.local>  <20180215201215.2fvrs3nykkpdd3fs@elstar.local>
From: Andy Bierman 
Date: Thu, 15 Feb 2018 12:50:34 -0800
Message-ID: 
To: Juergen Schoenwaelder , Andy Bierman ,  Robert Wilton , Kent Watsen ,  Mahesh Jethanandani , NETCONF WG ,  NETMOD WG 
Content-Type: multipart/alternative; boundary="001a11401eda1db76f056546614a"
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 15 Feb 2018 20:50:40 -0000

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

On Thu, Feb 15, 2018 at 12:12 PM, Juergen Schoenwaelder <
j.schoenwaelder@jacobs-university.de> wrote:

> On Thu, Feb 15, 2018 at 11:03:02AM -0800, Andy Bierman wrote:
> >
> > The reason the deviation is a list is because it has a name and revision.
> > Or it did until it was removed.
> >
>
> > I prefer to keep the contents of the "module" list the
> > same as RFC 7895.  The "improvement" is much worse --
> > harder to use by clients and provides less information to clients.
>
> Which "improvement" do you mean? Which information is lost? In which
> situations are things harder to use?
>

The supposed improvement is the /yang-library subtree.

It is now much harder to determine the modules used by the server
because there are 3 data structures to retrieve and process instead of 1.

The module list used to have a deviation list so revisions could be
identified

    list deviation {
           key "name revision";
           description
             "List of YANG deviation module names and revisions
              used by this server to modify the conformance of
              the module associated with this entry.  Note that
              the same module can be used for deviations for
              multiple modules, so the same entry MAY appear
              within multiple 'module' entries.

              The deviation module MUST be present in the 'module'
              list, with the same name and revision values.
              The 'conformance-type' value will be 'implement' for
              the deviation module.";
           uses common-leafs;

         }


> /js
>


Andy


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

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




On Thu, Feb 15, 2018 at 12:12 PM, Juergen Schoenwaelder <j.schoenwaelder@jacobs-university.de> wrote:
On Thu, Feb 15, 2018 at 11:03:02=
AM -0800, Andy Bierman wrote:

>

> The reason the deviation is a list is because it has a name and revisi=
on.

> Or it did until it was removed.

>



> I prefer to keep the contents of the "module" list the

> same as RFC 7895.=C2=A0 The "improvement" is much worse --
> harder to use by clients and provides less information to clients.



Which "improvement" do you mean? Which information is lost? In wh=
ich

situations are things harder to use?

Th=
e supposed improvement is the /yang-library subtree.

It is now much harder to determine the modules used by the server
<=
div>because there are 3 data structures to retrieve and process instead of =
1.

The module list used to have a deviation list s=
o revisions could be identified

    list deviation {
           key "name revision";
           description
             "List of YANG deviation module names and revisions
              used by this server to modify the conformance of
              the module associated with this entry.  Note that
              the same module can be used for deviations for
              multiple modules, so the same entry MAY appear
              within multiple 'module' entries.

              The deviation module MUST be present in the 'module'
              list, with the same name and revision values.
              The 'conformance-type' value will be 'implement&#=
39; for
              the deviation module.";
           uses common-leafs;

         }



/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<https://www.jacobs-university.de/>





--001a11401eda1db76f056546614a--


From nobody Thu Feb 15 17:27:20 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2725A126DED; Thu, 15 Feb 2018 17:27:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.231
X-Spam-Level: 
X-Spam-Status: No, score=-4.231 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, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id u46YQ1xoOIWa; Thu, 15 Feb 2018 17:27:16 -0800 (PST)
Received: from huawei.com (lhrrgout.huawei.com [194.213.3.17]) (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 6F6F5126CD8; Thu, 15 Feb 2018 17:27:16 -0800 (PST)
Received: from lhreml706-cah.china.huawei.com (unknown [172.18.7.108]) by Forcepoint Email with ESMTP id 265867ADA3E; Fri, 16 Feb 2018 01:27:13 +0000 (GMT)
Received: from SJCEML702-CHM.china.huawei.com (10.208.112.38) by lhreml706-cah.china.huawei.com (10.201.108.47) with Microsoft SMTP Server (TLS) id 14.3.361.1; Fri, 16 Feb 2018 01:27:14 +0000
Received: from SJCEML521-MBS.china.huawei.com ([169.254.2.168]) by SJCEML702-CHM.china.huawei.com ([169.254.4.179]) with mapi id 14.03.0382.000;  Thu, 15 Feb 2018 17:27:07 -0800
From: Alexander Clemm 
To: Kent Watsen , Juergen Schoenwaelder 
CC: NETCONF WG , NETMOD WG 
Thread-Topic: [Netconf] [netmod]  LC on YANG Library (bis)
Thread-Index: AQHTpnTc9+x4PHWQskiS0bFD5BSAGaOmPJ8w
Date: Fri, 16 Feb 2018 01:27:06 +0000
Message-ID: <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE915F@sjceml521-mbs.china.huawei.com>
References:  <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE81CB@sjceml521-mbs.china.huawei.com> <20180213194821.cwbwwmy7bqhvkfsd@elstar.local> <644DA50AFA8C314EA9BDDAC83BD38A2E0EAE8224@sjceml521-mbs.china.huawei.com> 
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [10.209.216.150]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: 
Subject: Re: [netmod] [Netconf]   LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Feb 2018 01:27:19 -0000

SGkgS2VudCwNCg0KeWVzLCBpdCB3b3VsZG4ndCBoYXZlIHRvIGJlIGluIHRoaXMgZG9jdW1lbnQu
ICBCdXQgSSBkbyB0aGluayBhIHNvbHV0aW9uIGZvciB0aGlzIGlzIGNsZWFybHkgbmVlZGVkLCBh
bmQgWUFORyBsaWJyYXJ5IChvciBhdWdtZW50YXRpb24gdG8gaXQpIGlzIHRoZSBiZXN0IHdheSB0
byBwdXQgaXQuICANCg0KSSB3YXNuJ3QgcGxhbm5pbmcgdG8gcHV0IG91dCBhbiBJLUQgb24gdGhp
cyBteXNlbGYsIGJ1dCBjYW4gcHV0IGl0IG9uIG15IHRvLWRvIGxpc3QgKGFuZCB3aWxsIGJlIGhh
cHB5IHRvIGNvbnRyaWJ1dGUgaWYgc29tZW9uZSB3YW50cyB0byB0YWtlIHRoZSBsZWFkKS4gIA0K
DQotLS0gQWxleA0KDQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZyb206IEtlbnQg
V2F0c2VuIFttYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldF0NCj4gU2VudDogVGh1cnNkYXksIEZl
YnJ1YXJ5IDE1LCAyMDE4IDc6NTEgQU0NCj4gVG86IEFsZXhhbmRlciBDbGVtbSA8YWxleGFuZGVy
LmNsZW1tQGh1YXdlaS5jb20+OyBKdWVyZ2VuDQo+IFNjaG9lbndhZWxkZXIgPGouc2Nob2Vud2Fl
bGRlckBqYWNvYnMtdW5pdmVyc2l0eS5kZT4NCj4gQ2M6IE5FVENPTkYgV0cgPG5ldGNvbmZAaWV0
Zi5vcmc+OyBORVRNT0QgV0cgPG5ldG1vZEBpZXRmLm9yZz4NCj4gU3ViamVjdDogUmU6IFtOZXRj
b25mXSBbbmV0bW9kXSBMQyBvbiBZQU5HIExpYnJhcnkgKGJpcykNCj4gDQo+IEFsZXgsDQo+IA0K
PiBXaGF0IHlvdSB3YW50IG1ha2VzIHNlbnNlIHRvIG1lLiAgSG93IGFib3V0IHB1dHRpbmcgaXQg
aW50byBhbiBJLUQgdGhhdA0KPiBhdWdtZW50cyB0aGUgeWFuZyBsaWJyYXJ5IGJpcz8gIEl0IGRv
ZXNuJ3QgaGF2ZSB0byBiZSBpbiB0aGlzIGRvY3VtZW50LCByaWdodD8NCj4gDQo+IEtlbnQNCj4g
DQo+ID09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT0NCj4gDQo+IFdlbGwsIHdlIG5lZWQgYSBn
ZW5lcmFsIHNvbHV0aW9uIGZvciB0aGF0LiAgWUFORy1wdXNoIGlzIGp1c3Qgb25lIHVzZSBjYXNl
LiAgVGhlcmUNCj4gYXJlIG90aGVyIGNhc2VzIHdoZXJlIHRoZXJlIHdpbGwgYmUgIm1ldGFkYXRh
IiAodGhhdCBkb2VzIG5vdCBwZXJ0YWluIHRvIGluc3RhbmNlDQo+IGRhdGEpICBhbmQgY2FwYWJp
bGl0aWVzIHRoYXQgY2xpZW50cyB3YW50IHRvIGRpc2NvdmVyLiAgWUFORyBsaWJyYXJ5IChpbiBp
dHNlbGYNCj4gcHJvdmlkaW5nICJtZXRhZGF0YSIgYWJvdXQgd2hhdCBhIHNlcnZlciBzdXBwb3J0
cyBhbmQgaXMgY2FwYWJsZSBvZikgaXMgYW4NCj4gZXhjZWxsZW50IHBsYWNlIHRvIG1haW50YWlu
IHRoaXMgaW5mb3JtYXRpb24uICBJdCBhbHNvIHByb3ZpZGVzIHRoZSBvcHBvcnR1bml0eSB0bw0K
PiBiZSBzeXN0ZW1pYyBhYm91dCBpdCwgYXMgb3Bwb3NlZCB0byByZXF1aXJpbmcgZXZlcnlvbmUg
dG8gZGVmaW5lIHRoZWlyIG93biBsaXR0bGUNCj4gY3VzdG9tIGV4dGVuc2lvbnMuDQo+IC0tLSBB
bGV4DQo+IA0KPiA+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+ID4gRnJvbTogSnVlcmdl
biBTY2hvZW53YWVsZGVyDQo+ID4gW21haWx0bzpqLnNjaG9lbndhZWxkZXJAamFjb2JzLXVuaXZl
cnNpdHkuZGVdDQo+ID4gU2VudDogVHVlc2RheSwgRmVicnVhcnkgMTMsIDIwMTggMTE6NDggQU0N
Cj4gPiBUbzogQWxleGFuZGVyIENsZW1tIDxhbGV4YW5kZXIuY2xlbW1AaHVhd2VpLmNvbT4NCj4g
PiBDYzogTWFoZXNoIEpldGhhbmFuZGFuaSA8bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+OyBORVRD
T05GIFdHDQo+ID4gPG5ldGNvbmZAaWV0Zi5vcmc+OyBORVRNT0QgV0cgPG5ldG1vZEBpZXRmLm9y
Zz4NCj4gPiBTdWJqZWN0OiBSZTogW25ldG1vZF0gW05ldGNvbmZdIExDIG9uIFlBTkcgTGlicmFy
eSAoYmlzKQ0KPiA+DQo+ID4gQWxleGFuZGVyLA0KPiA+DQo+ID4gSSBkaXNhZ3JlZS4gVGhpcyBZ
QU5HIExpYnJhcnkgaXMgbWFuZGF0b3J5IGZvciBhbGwgaW1wbGVtZW50YXRpb25zOw0KPiA+IHdo
YXQgeW91IHRhbGsgYWJvdXQgc2VlbXMgdG8gY29uY2VybiBvbmx5IGltcGxlbWVudGF0aW9ucyB0
aGF0IHN1cHBvcnQNCj4gPiBZQU5HIHB1c2guIEhlbmNlLCB0aGlzIGlzIGFuIGV4dGVuc2lvbiB0
aGF0IHNob3VsZCBnbyBpbiBpdHMgb3duIG1vZHVsZS4NCj4gPg0KPiA+IC9qcw0KPiA+DQo+ID4g
T24gVHVlLCBGZWIgMTMsIDIwMTggYXQgMDc6Mzg6MzFQTSArMDAwMCwgQWxleGFuZGVyIENsZW1t
IHdyb3RlOg0KPiA+ID4gSGksDQo+ID4gPg0KPiA+ID4gSSBoYXZlIHRha2VuIGEgbG9vayBhdCB0
aGlzIGRvY3VtZW50Lg0KPiA+ID4NCj4gPiA+IE15IG1haW4gY29tbWVudCBpcyB0aGF0IG9uZSBh
c3BlY3QgdGhhdCBpcyBtaXNzaW5nLCB0aGF0IEkgYmVsaWV2ZQ0KPiA+ID4gc2hvdWxkIGJlDQo+
ID4gYWRkZWQsIGNvbmNlcm5zIHRoZSBpbmNsdXNpb24gb2YgY2VydGFpbiBtZXRhZGF0YSBhYm91
dCB0aGUgbW9kdWxlcy4NCj4gPiBTcGVjaWZpY2FsbHksIGluIHRoZSBjb250ZXh0IG9mIFlBTkct
UHVzaCB3ZSBoYWQgYSBkaXNjdXNzaW9uIGFib3V0DQo+ID4gYmVpbmcgYWJsZSB0byBtYXJrIG5v
ZGVzIHRoYXQgYXJlIG5vdGlmaWFibGUgb24gY2hhbmdlLiAgVGhpcyBpcyBqdXN0DQo+ID4gb25l
IHBhcnRpY3VsYXIgdXNlIGNhc2Ugb2YgYSBtb3JlIGdlbmVyYWwgaXNzdWU7IGluIFlBTkctUHVz
aCBhZnRlcg0KPiA+IG11Y2ggZGViYXRlIHRoZSBjb25jbHVzaW9uIHdhcyBmb3Igbm93IHRvIHNp
bXBseSBtYWtlIGltcGxlbWVudG9ycw0KPiA+IGF3YXJlIG9mIHRoaXMgaXNzdWUgYW5kIGFkdmlz
ZSB0aGF0IGEgc29sdXRpb24gdG8gdGhpcyBtdXN0IGJlDQo+ID4gcHJvdmlkZWQsIHdpdGggdGhl
IGNsZWFyIHVuZGVyc3RhbmRpbmcgdGhhdCBldmVudHVhbGx5IGEgc3RhbmRhcmQgc29sdXRpb24N
Cj4gc2hvdWxkIGJlIGRlZmluZWQuDQo+ID4gPg0KPiA+ID4gU2luY2UgdGhlIGdvYWwgb2YgWUFO
Ry1MaWJyYXJ5IGlzIHRvIGFsbG93IGNsaWVudHMgdG8gZmluZCBvdXQgd2hhdA0KPiA+ID4gaXMg
YWN0dWFsbHkNCj4gPiBzdXBwb3J0ZWQgb24gYSBnaXZlbiBzZXJ2ZXIsIHRoaXMgaXMgdGhlIHJp
Z2h0IHBsYWNlIHRvIGtlZXAgdGhpcw0KPiA+IGluZm9ybWF0aW9uLiAgT25lIHBvc3NpYmxlIHdh
eSB0byBhZGRyZXNzIHRoaXMgd291bGQgYmUsIGZvciBhIGdpdmVuDQo+ID4gbW9kdWxlLCB0byBt
YWludGFpbiBhIGxpc3Qgb2YgIm1ldGEtaW5mbyIsIHdpdGggYSBrZXkgIm1ldGEtdGFnIiwgYW5k
DQo+ID4gYSBsaXN0IHdpdGggcmVmZXJlbmNlcyB0byB0aGUgbm9kZXMgdG8gd2hpY2ggdGhlIG1l
dGFkYXRhIGFwcGxpZXMuICBJbg0KPiA+IHRoZSBjYXNlIG9mIG5vdGlmaWFibGUtb24tY2hhbmdl
LCB5b3Ugd291bGQgaGF2ZSBhIGxpc3Qgd2l0aCBvbmUgZW50cnkNCj4gPiAibm90aWZpYWJsZS1v
bi1jaGFuZ2UiLCBhbmQgdGhlbiB0aGUgbGlzdCB3aXRoIHRoZSBub2RlIGRlZmluaXRpb25zIHRv
IHdoaWNoIHRoaXMNCj4gdGFnIGFwcGxpZXMuDQo+ID4gPg0KPiA+ID4gRWRpdG9yaWFsIG5pdDoN
Cj4gPiA+IDJuZCBwYXJhZ3JhcGggSW50cm9kdWN0aW9uOiBpbmZvcm1hdG9uIC0tPiBpbmZvcm1h
dGlvbg0KPiA+ID4NCj4gPiA+IFRoYW5rcw0KPiA+ID4gLS0tIEFsZXgNCj4gPiA+DQo+ID4gPiBG
cm9tOiBOZXRjb25mIFttYWlsdG86bmV0Y29uZi1ib3VuY2VzQGlldGYub3JnXSBPbiBCZWhhbGYg
T2YgTWFoZXNoDQo+ID4gPiBKZXRoYW5hbmRhbmkNCj4gPiA+IFNlbnQ6IFRodXJzZGF5LCBGZWJy
dWFyeSAwMSwgMjAxOCAxMTowMCBBTQ0KPiA+ID4gVG86IE5FVENPTkYgV0cgPG5ldGNvbmZAaWV0
Zi5vcmc+DQo+ID4gPiBDYzogTkVUTU9EIFdHIDxuZXRtb2RAaWV0Zi5vcmc+DQo+ID4gPiBTdWJq
ZWN0OiBbTmV0Y29uZl0gTEMgb24gWUFORyBMaWJyYXJ5IChiaXMpDQo+ID4gPg0KPiA+ID4gV0cs
DQo+ID4gPg0KPiA+ID4gVGhlIGF1dGhvcnMgb2YgcmZjNzg5NWJpcyBoYXZlIGluZGljYXRlZCB0
aGF0IHRoZXkgYmVsaWV2ZSB0aGUNCj4gPiA+IGRvY3VtZW50IGlzDQo+ID4gcmVhZHkgZm9yIExD
WzFdLg0KPiA+ID4NCj4gPiA+IFRoaXMgc3RhcnRzIGEgdHdvIHdlZWsgTEMgb24gdGhlDQo+ID4g
PiBkcmFmdDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMt
M0FfX3Rvb2xzLmlldA0KPiA+ID4gZi5vcmdfaHRtbF9kcmFmdC0yRGlldGYtDQo+IDJEJmQ9RHdJ
Q0FnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kDQo+ID4gPg0KPiBiM3ZvRFRYY1d6
b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPW9BTA0K
PiBiN0wNCj4gPiA+DQo+IEtyVWtLRHNKMDZWSU0zQW54X2lEMDVCa214amFNMFRaRjFoZUEmcz1O
YVk4UjlEQmhJblpRQXhMMzVfS2pGemUNCj4gWUhmeQ0KPiA+ID4gVE9WSkxuTUhBS0dlS0YwJmU9
DQo+ID4gbmV0Y29uZi1yZmM3ODk1YmlzLTA0Pi4gVGhlIExDIHdpbGwgZW5kIG9uIEZlYnJ1YXJ5
IDE1Lg0KPiA+ID4NCj4gPiA+IFBsZWFzZSBzZW5kIHlvdXIgY29tbWVudHMgb24gdGhpcyB0aHJl
YWQuIFJldmlld3Mgb2YgdGhlIGRvY3VtZW50LA0KPiA+ID4gYW5kDQo+ID4gc3RhdGVtZW50IG9m
IHN1cHBvcnQgYXJlIHBhcnRpY3VsYXJseSBoZWxwZnVsIHRvIHRoZSBhdXRob3JzLiBJZiB5b3UN
Cj4gPiBoYXZlIGNvbmNlcm5zIGFib3V0IHRoZSBkb2N1bWVudCwgcGxlYXNlIHN0YXRlIHRob3Nl
IHRvby4NCj4gPiA+DQo+ID4gPiBBdXRob3JzIHBsZWFzZSBpbmRpY2F0ZSBpZiB5b3UgYXJlIGF3
YXJlIG9mIGFueSBJUFIgb24gdGhlIGRvY3VtZW50Lg0KPiA+ID4NCj4gPiA+IFRoYW5rcy4NCj4g
PiA+DQo+ID4gPiBbMV0NCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92
Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21hDQo+ID4gPiBpbC0NCj4gMkRhcmNoaXZl
X3dlYl9uZXRjb25mX2N1cnJlbnRfbXNnMTM5ODAuaHRtbCZkPUR3SUNBZyZjPUhBa1l1aDYzcnMN
Cj4gPiA+IHVocjZTY2JmaDBVakJYZU1LLQ0KPiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2
WkdKOUVQb09IN1locW4yZ3NCWWFHVA0KPiA+ID4NCj4gdmpJU2xhSmRjWm8mbT1vQUxiN0xLclVr
S0RzSjA2VklNM0FueF9pRDA1QmtteGphTTBUWkYxaGVBJnM9UW02DQo+IFU5Q0lwDQo+ID4gPiBE
SFMwanFVbkdHWmw4WDA1cWVBX1Z2TXl5dU90d0RIQmYxTSZlPQ0KPiA+ID4NCj4gPiA+IE1haGVz
aCAmIEtlbnQNCj4gPiA+DQo+ID4NCj4gPiA+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fDQo+ID4gPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+ID4gPiBuZXRt
b2RAaWV0Zi5vcmcNCj4gPiA+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21hDQo+ID4gPiBpbG1hbl9saXN0aW5mb19uZXRt
b2QmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstDQo+IG5kYjN2b0QNCj4g
PiA+DQo+IFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZtPW9BTGI3TEtyDQo+IFVrSw0KPiA+ID4gRHNKMDZWSU0zQW54X2lEMDVCa214amFNMFRa
RjFoZUEmcz1HUGRxbGlvXzJsYVFsOTNqb2JHWGdYT3MtDQo+IFdwb3V4RTFXDQo+ID4gPiA0TWVH
eHZoNTU4JmU9DQo+ID4NCj4gPg0KPiA+IC0tDQo+ID4gSnVlcmdlbiBTY2hvZW53YWVsZGVyICAg
ICAgICAgICBKYWNvYnMgVW5pdmVyc2l0eSBCcmVtZW4gZ0dtYkgNCj4gPiBQaG9uZTogKzQ5IDQy
MSAyMDAgMzU4NyAgICAgICAgIENhbXB1cyBSaW5nIDEgfCAyODc1OSBCcmVtZW4gfCBHZXJtYW55
DQo+ID4gRmF4OiAgICs0OSA0MjEgMjAwIDMxMDMNCj4gPGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9v
ZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmphY29icy0NCj4gMkR1bml2ZXJzaXR5
LmRlXyZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy0NCj4gbmRiM3ZvRFRY
Y1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPW8N
Cj4gQUxiN0xLclVrS0RzSjA2VklNM0FueF9pRDA1QmtteGphTTBUWkYxaGVBJnM9ejlWOGt5dG85
RWd5R3AzSnN3QQ0KPiAyUWJKQlNRZDNlY3pmY2l6dGNDMWdOdDQmZT0+DQo+IA0KPiBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBOZXRjb25mIG1haWxp
bmcgbGlzdA0KPiBOZXRjb25mQGlldGYub3JnDQo+IGh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBv
aW50LmNvbS92Mi91cmw/dT1odHRwcy0NCj4gM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3Rp
bmZvX25ldGNvbmYmZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlMNCj4gY2JmaDBVakJYZU1LLQ0K
PiBuZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNs
YUpkY1pvJm09bw0KPiBBTGI3TEtyVWtLRHNKMDZWSU0zQW54X2lEMDVCa214amFNMFRaRjFoZUEm
cz1qOWVkbHBJR2J1RWVTN3lNclY0aQ0KPiBSV1k3dnZxMGMyRnFJZW11SGYxN0xMVSZlPQ0KPiAN
Cg0K


From nobody Fri Feb 16 01:07:14 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3814E124BAC; Fri, 16 Feb 2018 01:07:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HrRGOdVUo64e; Fri, 16 Feb 2018 01:07:10 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 4D25C124B17; Fri, 16 Feb 2018 01:06:59 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 885E91820413; Fri, 16 Feb 2018 10:04:52 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 8BF8818203F6; Fri, 16 Feb 2018 10:04:49 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , Kent Watsen , Mahesh Jethanandani , NETCONF WG ,  NETMOD WG 
In-Reply-To: <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com>
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com>
Mail-Followup-To: Robert Wilton , Kent Watsen , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
Date: Fri, 16 Feb 2018 10:06:54 +0100
Message-ID: <87y3jtjob5.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Feb 2018 09:07:12 -0000

Robert Wilton  writes:

> I should add, as a contributor, I have read this document and think that=
=20
> is ready for advancement.
>
> I have three minor comments:
>
> 1) module "feature" in YANG library is a leaf-list, but currently it is=20
> a list in YANG libary bis. I suspect that this is due to one of the=20
> incarnations when it contained additional information.=C2=A0 I think that=
 we=20
> should revert it back to being a leaf list for consistency.
>
> 2) Lada recommended that module "deviation" be made a leaf-list. I also=20
> support changing this for consistency with "feature" above, but don't=20
> feel too strongly on this one.

I agree to have both as leaf-lists.

>
> 3) I think the "modules" list is also allowed to included modules that=20
> don't actually contain any nodes that require implementation.=C2=A0 Hence=
, it=20
> might be useful of the "modules" description statement explicitly stated=
=20
> this.=C2=A0 I.e. perhaps something like:
>
> "This list may contain modules that do not contain any schema nodes that=
=20
> require implementation.=C2=A0 For example, it could contain a module that=
=20
> only defines types and not any data nodes, RPCs, actions, notifications,=
=20
> or deviations."

Hmm, such modules belong to the other list "import-only-modules", don't
they?

Lada

>
> Thanks,
> Rob
>
>
> On 02/02/2018 13:51, Kent Watsen wrote:
>>
>> As co-author, I am not aware of any IPR related to this document.
>>
>> As a contributor, I have read this document and think that it is ready=20
>> for advancement.
>>
>> Kent
>>
>> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"=20
>>  on behalf=20
>> of rwilton@cisco.com > wrote:
>>
>> I am not aware of any IPR related to this document.
>>
>> Thanks,
>> Rob
>>
>> On 01/02/2018 18:59, Mahesh Jethanandani wrote:
>>
>>     WG,
>>
>>     The authors of rfc7895bis have indicated that they believe the
>>     document is ready for LC[1].
>>
>>     This starts a two week LC on the draft
>>     .
>>     The LC will end on February 15.
>>
>>     Please send your comments on this thread. Reviews of the document,
>>     and statement of support are particularly helpful to the authors.
>>     If you have concerns about the document, please state those too.
>>
>>     Authors please indicate if you are aware of any IPR on the document.
>>
>>     Thanks.
>>
>>     [1]
>>     https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>>     
>>
>>     Mahesh & Kent
>>
>>
>>
>>
>>     _______________________________________________
>>
>>     Netconf mailing list
>>
>>     Netconf@ietf.org 
>>
>>     https://www.ietf.org/mailman/listinfo/netconf
>>     
>>
>>
>>
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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


From nobody Fri Feb 16 01:19:04 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9159312D879; Fri, 16 Feb 2018 01:18:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMgVlpcRIl4A; Fri, 16 Feb 2018 01:18:50 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id AE2D31242F7; Fri, 16 Feb 2018 01:18:46 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id B30C81820415; Fri, 16 Feb 2018 10:16:39 +0100 (CET)
Received: from localhost (unknown [195.113.220.121]) by trail.lhotka.name (Postfix) with ESMTPSA id 0454618203F6; Fri, 16 Feb 2018 10:16:36 +0100 (CET)
From: Ladislav Lhotka 
To: Andy Bierman , Juergen Schoenwaelder , Robert Wilton , Kent Watsen , Mahesh Jethanandani , NETCONF WG ,  NETMOD WG 
In-Reply-To: 
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com> <20180215180955.idnyuacivy6h3lrf@elstar.local> 
Mail-Followup-To: Andy Bierman , Juergen Schoenwaelder , Robert Wilton , Kent Watsen , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
Date: Fri, 16 Feb 2018 10:18:42 +0100
Message-ID: <87vaexjnrh.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Feb 2018 09:18:59 -0000

Andy Bierman  writes:

> On Thu, Feb 15, 2018 at 10:09 AM, Juergen Schoenwaelder <
> j.schoenwaelder@jacobs-university.de> wrote:
>
>> On Thu, Feb 15, 2018 at 05:03:32PM +0000, Robert Wilton wrote:
>> >
>> > 1) module "feature" in YANG library is a leaf-list, but currently it is a
>> > list in YANG libary bis. I suspect that this is due to one of the
>> > incarnations when it contained additional information.  I think that we
>> > should revert it back to being a leaf list for consistency.
>> >
>> > 2) Lada recommended that module "deviation" be made a leaf-list. I also
>> > support changing this for consistency with "feature" above, but don't
>> feel
>> > too strongly on this one.
>> >
>>
>> I suggest we either make both leaf-lists or keep both as lists. I am
>> fine with making both lead-lists.
>>
>>
>
> The reason the deviation is a list is because it has a name and revision.
> Or it did until it was removed.
>
> I prefer to keep the contents of the "module" list the
> same as RFC 7895.  The "improvement" is much worse --
> harder to use by clients and provides less information to clients.

So we currently have:

1. "deviation": [
     {
       "module": "foo-devs"
     },
     {
       "module": "bar-devs"
     }
   ]

and the proposal is to have instead

2. "deviation-module": [
     "foo-devs",
     "bar-dev"
   ]

I fail to see why #2 is harder to use for clients, I would say it is the
opposite. Also, #2 doesn't provide less information than RFC 7895 - the
revision parameter is readily available in the "module" list.

I also expect that this data will be used not only in machine-to-machine
communication but could also be perused by humans - see
e.g. draft-lengyel-netmod-yang-instance-data. For this purpose, #2 is a
clear winer.

Lada

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

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


From nobody Fri Feb 16 02:36:00 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD2DD126C23 for ; Fri, 16 Feb 2018 02:35:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3Z6x8x342P-3 for ; Fri, 16 Feb 2018 02:35:49 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7CC0712D87E for ; Fri, 16 Feb 2018 02:35:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=22976; q=dns/txt; s=iport; t=1518777348; x=1519986948; h=subject:references:from:to:message-id:date:mime-version: in-reply-to; bh=idf7e0p9l6jN0Ed40XWNavfSgXHXxJwRP3H3uPw2j1A=; b=Khj/RBPtKxElAPmv3JTzeSjUY1BT2XhQi8hA3iEfM1tQB6Qza+OAQlLn qTykOMh8i2NPz9KyybPvfYbh12v3odg08DIO1UtGQZ7CKq+F/MXXJJm9N A9ZpX9Y+NaRObQlcQ0BG5ihT8CxD2v2Lm7DspumcZlPpEFeWfexVfe/MO Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAQD0soZa/xbLJq1CGhoBAQEBAQIBA?= =?us-ascii?q?QEBCAEBAQGENXAog1SKJXSOaoE+kG2FXBSCAgomhRUCGoJ+GAECAQEBAQEBAms?= =?us-ascii?q?oQhABhFEGI2YJRAICAlUGDQgBAYodEDSPYZ10gicmhFuDe4ITAQEBAQEBBAEBA?= =?us-ascii?q?QEBAQEcBYUEg3+BaCkMhEKBZwIBAQEBgTUigy2CZQWKdo82igkJiCSNZoIghiq?= =?us-ascii?q?Dc4gLjgaBf4gagTwfOYFRMxoIGxWCfYJgghdANwGFD4hvAQEB?=
X-IronPort-AV: E=Sophos;i="5.46,519,1511827200"; d="scan'208,217";a="2106063"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2018 10:35:46 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1GAZjhs015806 for ; Fri, 16 Feb 2018 10:35:45 GMT
References: <7cd9c63c-8bbe-e7c3-3cb0-dc5c1ebc7304@cisco.com>
From: Benoit Claise 
To: NETMOD Working Group 
X-Forwarded-Message-Id: <7cd9c63c-8bbe-e7c3-3cb0-dc5c1ebc7304@cisco.com>
Message-ID: <42d768a1-2b28-3269-e450-d88bf8b3b441@cisco.com>
Date: Fri, 16 Feb 2018 11:35:45 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <7cd9c63c-8bbe-e7c3-3cb0-dc5c1ebc7304@cisco.com>
Content-Type: multipart/alternative; boundary="------------D7A329188AF94DB6EA62CBAF"
Content-Language: en-US
Archived-At: 
Subject: [netmod] YANG modules publication: what to focus on next? Feb 16th
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Feb 2018 10:36:00 -0000

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

Dear all,

At the last IETF meeting, Alia, Deborah and I looked at the publication=20
status of most YANG modules.
Since that time, I've been keeping a summary of the situation. Let me=20
share it with everybody.

Before publishing YANG modules, we have two series of bottlenecks:
- the YANG module import (shown by tooling below)
- the normative references (MISSREF in the RFC editor queue=20
)

We now have many YANG modules in RFC editor queue:**
**draft-ietf-netconf-rfc6536bis-09 (AUTH48)=20
**
****draft-ietf-netmod-revised-datastores-10 (AUTH48)=20

*draft-ietf-netmod-yang-tree-diagrams-05 (expedited processing)=20

**draft-ietf-lime-yang-connectionless-oam-18=20
**
****draft-ietf-lime-yang-connectionless-oam-methods-13=20
**
****draft-ietf-i2rs-yang-l3-topology-16=20
**
****draft-ietf-i2rs-yang-network-topo-20=20
**
****draft-wu-l3sm-rfc8049bis-11=20
****
*draft-ietf-netmod-rfc7223bis-03=20

draft-ietf-netmod-rfc7277bis-03=20

draft-ietf-rtgwg-yang-vrrp-09=20

draft-ietf-rtgwg-yang-rip-08=20

draft-ietf-netmod-rfc8022bis-10=20

draft-ietf-netmod-entity-08=20

draft-ietf-rtgwg-ni-model-06=20

draft-ietf-rtgwg-lne-model-05=20
=20
(actually, almost in the RFC editor queue)


Here are the YANG module dependencies=20
=20
for these RFC editor modules, as requirement before publishing.

Some more YANG modules are on the IESG table:
 =C2=A0=C2=A0=C2=A0 draft-ietf-pim-yang has a DISCUSS (Jan 11th IESG tele=
chat)

Assuming this one is in the RFC editor queue, this is the new set of=20
YANG module dependencies=20
.
It takes a little bit of re-arrangering the elements, but all the=20
information regarding YANG module dependency is there.

The next bottlenecks for publishing those YANG modules are:
 =C2=A0=C2=A0=C2=A0 draft-ietf-netmod-schema-mount
 =C2=A0=C2=A0=C2=A0 ietf-bfd-yang (currently in WG LC)
 =C2=A0=C2=A0=C2=A0 draft-ietf-ospf-yang
 =C2=A0=C2=A0=C2=A0 draft-ietf-isis-yang-isis-cfg
Please progress those documents asap

Some more updates below.

_NETMOD:_
draft-ietf-netmod-syslog-model-17=20
 (in=20
IETF LC)
draft-ietf-netmod-acl-model-15=20
(WG LC=20
closed, writeup time)
draft-ietf-netmod-rfc6087bis-17=20
 (AD=20
review done)
 =C2=A0=C2=A0=C2=A0 draft-ietf-netmod-schema-mount:

_NETCONF:_
 =C2=A0=C2=A0=C2=A0 Time to progress this set of documents (TLS, SSH, cli=
ent, server,=20
keystore)=20

 =C2=A0=C2=A0=C2=A0 draft-ietf-netconf-rfc7895bis (in WG LC)
 =C2=A0=C2=A0=C2=A0 =C2=A0=C2=A0=C2=A0 Status: Under discussion in NETCON=
F

_LIME:_
draft-ietf-lime-yang-connection-oriented-oam-model-05 (next IESG telechat=
)

_OPSAWG:_
draft-ietf-opsawg-nat-yang-12=20
 (in WG LC)=


_L2SM:_
draft-ietf-l2sm-l2vpn-service-model-06=20
=20
(in WG LC)

_I2RS:_
draft-ietf-i2rs-yang-dc-fabric-network-topology-06=20
=20
(on the IESG telechat)
draft-ietf-i2rs-rib-data-model-10=20
 (on=20
the IESG telechat)

Regards, Benoit

--------------D7A329188AF94DB6EA62CBAF
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: base64

PGh0bWw+DQogIDxoZWFkPg0KDQogICAgPG1ldGEgaHR0cC1lcXVpdj0iY29udGVudC10eXBl
IiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KICA8L2hlYWQ+DQogIDxi
b2R5IHRleHQ9IiMwMDAwMDAiIGJnY29sb3I9IiNGRkZGRkYiPg0KICAgIERlYXIgYWxsLDxi
cj4NCiAgICA8ZGl2IGNsYXNzPSJtb3otZm9yd2FyZC1jb250YWluZXIiPg0KICAgICAgPGRp
diBjbGFzcz0ibW96LWZvcndhcmQtY29udGFpbmVyIj4NCiAgICAgICAgPGRpdiBjbGFzcz0i
bW96LWZvcndhcmQtY29udGFpbmVyIj4NCiAgICAgICAgICA8ZGl2IGNsYXNzPSJtb3otZm9y
d2FyZC1jb250YWluZXIiPg0KICAgICAgICAgICAgPGRpdiBjbGFzcz0ibW96LWZvcndhcmQt
Y29udGFpbmVyIj4NCiAgICAgICAgICAgICAgPGRpdiBjbGFzcz0ibW96LWZvcndhcmQtY29u
dGFpbmVyIj4gPGJyPg0KICAgICAgICAgICAgICAgIEF0IHRoZSBsYXN0IElFVEYgbWVldGlu
ZywgQWxpYSwgRGVib3JhaCBhbmQgSSBsb29rZWQgYXQNCiAgICAgICAgICAgICAgICB0aGUg
cHVibGljYXRpb24gc3RhdHVzIG9mIG1vc3QgWUFORyBtb2R1bGVzLjxicj4NCiAgICAgICAg
ICAgICAgICBTaW5jZSB0aGF0IHRpbWUsIEkndmUgYmVlbiBrZWVwaW5nIGEgc3VtbWFyeSBv
ZiB0aGUNCiAgICAgICAgICAgICAgICBzaXR1YXRpb24uIExldCBtZSBzaGFyZSBpdCB3aXRo
IGV2ZXJ5Ym9keS48YnI+DQogICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAg
IEJlZm9yZSBwdWJsaXNoaW5nIFlBTkcgbW9kdWxlcywgd2UgaGF2ZSB0d28gc2VyaWVzIG9m
DQogICAgICAgICAgICAgICAgYm90dGxlbmVja3M6IDxicj4NCiAgICAgICAgICAgICAgICAt
IHRoZSBZQU5HIG1vZHVsZSBpbXBvcnQgKHNob3duIGJ5IHRvb2xpbmcgYmVsb3cpPGJyPg0K
ICAgICAgICAgICAgICAgIC0gdGhlIG5vcm1hdGl2ZSByZWZlcmVuY2VzIChNSVNTUkVGIGlu
IHRoZSA8YQ0KICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KICAg
ICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvY3VycmVu
dF9xdWV1ZS5waHAiPlJGQw0KICAgICAgICAgICAgICAgICAgZWRpdG9yIHF1ZXVlPC9hPik8
YnI+DQogICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgIFdlIG5vdyBoYXZl
IG1hbnkgWUFORyBtb2R1bGVzIGluIFJGQyBlZGl0b3IgcXVldWU6PGI+PGI+PGJyPg0KICAg
ICAgICAgICAgICAgICAgICDCoMKgIDwvYj48L2I+PGENCiAgICAgICAgICAgICAgICAgIGhy
ZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0Y29u
Zi1yZmM2NTM2YmlzIj5kcmFmdC1pZXRmLW5ldGNvbmYtcmZjNjUzNmJpcy0wOQ0KICAgICAg
ICAgICAgICAgICAgKEFVVEg0OCk8L2E+PGI+PGI+PGJyPg0KICAgICAgICAgICAgICAgICAg
PC9iPjwvYj48Yj7CoMKgwqAgPC9iPjxhDQpocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmll
dGYub3JnL2RvYy9kcmFmdC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMvIj5kcmFm
dC1pZXRmLW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMtMTANCiAgICAgICAgICAgICAgICAg
IChBVVRINDgpPC9hPjxicj4NCiAgICAgICAgICAgICAgICA8Yj7CoMKgwqAgPGENCmhyZWY9
Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXlh
bmctdHJlZS1kaWFncmFtcy8iPmRyYWZ0LWlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFt
cy0wNQ0KICAgICAgICAgICAgICAgICAgICAoZXhwZWRpdGVkIHByb2Nlc3NpbmcpPC9hPjxi
cj4NCiAgICAgICAgICAgICAgICAgIMKgwqDCoCA8L2I+PGI+PGENCmhyZWY9Imh0dHBzOi8v
ZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbGltZS15YW5nLWNvbm5lY3Rp
b25sZXNzLW9hbSINCiAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVl
Ij5kcmFmdC1pZXRmLWxpbWUteWFuZy1jb25uZWN0aW9ubGVzcy1vYW0tMTg8L2E+PC9iPjxi
Pjxicj4NCiAgICAgICAgICAgICAgICA8L2I+PGI+wqDCoMKgIDwvYj48Yj48YQ0KaHJlZj0i
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1saW1lLXlhbmct
Y29ubmVjdGlvbmxlc3Mtb2FtLW1ldGhvZHMiDQogICAgICAgICAgICAgICAgICAgIG1vei1k
by1ub3Qtc2VuZD0idHJ1ZSI+ZHJhZnQtaWV0Zi1saW1lLXlhbmctY29ubmVjdGlvbmxlc3Mt
b2FtLW1ldGhvZHMtMTM8L2E+PC9iPjxiPjxicj4NCiAgICAgICAgICAgICAgICA8L2I+PGI+
wqDCoMKgIDwvYj48Yj48YQ0KICAgICAgICAgICAgICAgICAgICBocmVmPSJodHRwczovL2Rh
dGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1sMy10b3BvbG9n
eSINCiAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5kcmFmdC1p
ZXRmLWkycnMteWFuZy1sMy10b3BvbG9neS0xNjwvYT48L2I+PGI+PGJyPg0KICAgICAgICAg
ICAgICAgIDwvYj48Yj7CoMKgwqAgPC9iPjxiPjxhDQpocmVmPSJodHRwczovL2RhdGF0cmFj
a2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1uZXR3b3JrLXRvcG8iDQog
ICAgICAgICAgICAgICAgICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ZHJhZnQtaWV0Zi1p
MnJzLXlhbmctbmV0d29yay10b3BvLTIwPC9hPjwvYj48Yj48YnI+DQogICAgICAgICAgICAg
ICAgPC9iPjxiPsKgwqDCoCA8L2I+PGI+PGENCiAgICAgICAgICAgICAgICAgICAgaHJlZj0i
aHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtd3UtbDNzbS1yZmM4MDQ5
YmlzIg0KICAgICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmRyYWZ0
LXd1LWwzc20tcmZjODA0OWJpcy0xMTwvYT48L2I+PGI+DQogICAgICAgICAgICAgICAgPC9i
PjxiPjxicj4NCiAgICAgICAgICAgICAgICAgIMKgwqDCoCA8L2I+PGENCiAgICAgICAgICAg
ICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWll
dGYtbmV0bW9kLXJmYzcyMjNiaXMvIg0KICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1z
ZW5kPSJ0cnVlIj5kcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAzPC9hPjxicj4NCiAg
ICAgICAgICAgICAgICDCoMKgwqAgPGENCiAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXJmYzcyNzdi
aXMvIg0KICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5kcmFmdC1p
ZXRmLW5ldG1vZC1yZmM3Mjc3YmlzLTAzPC9hPjxicj4NCiAgICAgICAgICAgICAgICDCoMKg
wqAgPGENCiAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0
Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRnd2cteWFuZy12cnJwLyINCiAgICAgICAgICAgICAg
ICAgIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+ZHJhZnQtaWV0Zi1ydGd3Zy15YW5nLXZycnAt
MDk8L2E+PGJyPg0KICAgICAgICAgICAgICAgIMKgwqDCoCA8YQ0KICAgICAgICAgICAgICAg
ICAgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1y
dGd3Zy15YW5nLXJpcC8iDQogICAgICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRy
dWUiPmRyYWZ0LWlldGYtcnRnd2cteWFuZy1yaXAtMDg8L2E+PGJyPg0KICAgICAgICAgICAg
ICAgIMKgwqDCoCA8YQ0KICAgICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9kYXRhdHJh
Y2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1uZXRtb2QtcmZjODAyMmJpcy8iDQogICAg
ICAgICAgICAgICAgICBtb3otZG8tbm90LXNlbmQ9InRydWUiPmRyYWZ0LWlldGYtbmV0bW9k
LXJmYzgwMjJiaXMtMTA8L2E+PGJyPg0KICAgICAgICAgICAgICAgIMKgwqDCoCA8YQ0KICAg
ICAgICAgICAgICAgICAgaHJlZj0iaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2Mv
ZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5LyINCiAgICAgICAgICAgICAgICAgIG1vei1kby1u
b3Qtc2VuZD0idHJ1ZSI+ZHJhZnQtaWV0Zi1uZXRtb2QtZW50aXR5LTA4PC9hPjxicj4NCiAg
ICAgICAgICAgICAgICDCoMKgwqAgPGENCiAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBz
Oi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRnd2ctbmktbW9kZWwv
Ij5kcmFmdC1pZXRmLXJ0Z3dnLW5pLW1vZGVsLTA2PC9hPjxicj4NCiAgICAgICAgICAgICAg
ICDCoMKgwqAgPGENCiAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNr
ZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtcnRnd2ctbG5lLW1vZGVsLyI+ZHJhZnQtaWV0
Zi1ydGd3Zy1sbmUtbW9kZWwtMDU8L2E+DQogICAgICAgICAgICAgICAgKGFjdHVhbGx5LCBh
bG1vc3QgaW4gdGhlIFJGQyBlZGl0b3IgcXVldWUpPGJyPg0KICAgICAgICAgICAgICAgIDxi
cj4NCiAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgPGEgbW96LWRvLW5v
dC1zZW5kPSJ0cnVlIg0KaHJlZj0iaHR0cHM6Ly93d3cueWFuZ2NhdGFsb2cub3JnL3lhbmct
c2VhcmNoL2ltcGFjdF9hbmFseXNpcy5waHA/bW9kdWxlc1tdPWlldGYtaXAmYW1wO21vZHVs
ZXNbXT1pZXRmLWNvbm5lY3Rpb25sZXNzLW9hbSZhbXA7bW9kdWxlc1tdPWlldGYtbGltZS10
aW1lLXR5cGVzJmFtcDttb2R1bGVzW109aWV0Zi1jb25uZWN0aW9ubGVzcy1vYW0tbWV0aG9k
cyZhbXA7bW9kdWxlc1tdPWlldGYtbDMtdW5pY2FzdC10b3BvbG9neSZhbXA7bW9kdWxlc1td
PWlldGYtbDMtdW5pY2FzdC10b3BvbG9neS1zdGF0ZSZhbXA7bW9kdWxlc1tdPWlldGYtbmV0
d29yay10b3BvbG9neSZhbXA7bW9kdWxlc1tdPWlldGYtbmV0d29yay10b3BvbG9neS1zdGF0
ZSZhbXA7bW9kdWxlc1tdPWlldGYtbmV0d29yayZhbXA7bW9kdWxlc1tdPWlldGYtbmV0d29y
ay1zdGF0ZSZhbXA7bW9kdWxlc1tdPWlldGYtbDN2cG4tc3ZjJmFtcDttb2R1bGVzW109aWV0
Zi1uZXRjb25mLWFjbSZhbXA7bW9kdWxlc1tdPWlldGYtaW50ZXJmYWNlcyZhbXA7bW9kdWxl
c1tdPWlldGYtdnJycCZhbXA7bW9kdWxlc1tdPWlldGYtcmlwJmFtcDttb2R1bGVzW109aWV0
Zi1kYXRhc3RvcmVzJmFtcDttb2R1bGVzW109aWV0Zi1vcmlnaW4mYW1wO21vZHVsZXNbXT1p
ZXRmLWlwdjQtdW5pY2FzdC1yb3V0aW5nJmFtcDttb2R1bGVzW109aWV0Zi1pcHY2LXVuaWNh
c3Qtcm91dGluZyZhbXA7bW9kdWxlc1tdPWlldGYtaXB2Ni1yb3V0ZXItYWR2ZXJ0aXNlbWVu
dHMmYW1wO21vZHVsZXNbXT1pZXRmLXJvdXRpbmcmYW1wO21vZHVsZXNbXT1pYW5hLWhhcmR3
YXJlJmFtcDttb2R1bGVzW109aWV0Zi1oYXJkd2FyZSZhbXA7bW9kdWxlc1tdPWlldGYtaGFy
ZHdhcmUtc3RhdGUmYW1wO21vZHVsZXNbXT1pZXRmLWxvZ2ljYWwtbmV0d29yay1lbGVtZW50
JmFtcDttb2R1bGVzW109aWV0Zi1uZXR3b3JrLWluc3RhbmNlJmFtcDtyZWN1cnNlPTEmYW1w
O3JmY3M9MSZhbXA7c2hvd19zdWJtPTEmYW1wO3Nob3dfZGlyPWRlcGVuZGVuY2llcyI+SGVy
ZQ0KICAgICAgICAgICAgICAgICAgYXJlIHRoZSBZQU5HIG1vZHVsZSBkZXBlbmRlbmNpZXM8
L2E+IGZvciB0aGVzZSBSRkMNCiAgICAgICAgICAgICAgICBlZGl0b3IgbW9kdWxlcywgYXMg
cmVxdWlyZW1lbnQgYmVmb3JlIHB1Ymxpc2hpbmcuPGJyPg0KICAgICAgICAgICAgICAgIDxk
aXYgY2xhc3M9Im1vei1mb3J3YXJkLWNvbnRhaW5lciI+DQogICAgICAgICAgICAgICAgICA8
ZGl2IGNsYXNzPSJtb3otZm9yd2FyZC1jb250YWluZXIiPg0KICAgICAgICAgICAgICAgICAg
ICA8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPiA8YnI+DQogICAgICAgICAgICAgICAg
ICAgICAgU29tZSBtb3JlIFlBTkcgbW9kdWxlcyBhcmUgb24gdGhlIElFU0cgdGFibGU6PGJy
Pg0KICAgICAgICAgICAgICAgICAgICAgIMKgwqDCoCBkcmFmdC1pZXRmLXBpbS15YW5nIGhh
cyBhIERJU0NVU1MgKEphbiAxMXRoDQogICAgICAgICAgICAgICAgICAgICAgSUVTRyB0ZWxl
Y2hhdCk8YnI+DQogICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgIEFzc3VtaW5nIHRoaXMgb25lIGlzIGluIHRoZSBSRkMgZWRpdG9yIHF1ZXVlLCB0
aGlzDQogICAgICAgICAgICAgICAgICAgICAgaXMgdGhlIDxhIG1vei1kby1ub3Qtc2VuZD0i
dHJ1ZSINCmhyZWY9Imh0dHBzOi8vd3d3LnlhbmdjYXRhbG9nLm9yZy95YW5nLXNlYXJjaC9p
bXBhY3RfYW5hbHlzaXMucGhwP21vZHVsZXNbXT1pZXRmLWlwJmFtcDttb2R1bGVzW109aWV0
Zi1jb25uZWN0aW9ubGVzcy1vYW0mYW1wO21vZHVsZXNbXT1pZXRmLWxpbWUtdGltZS10eXBl
cyZhbXA7bW9kdWxlc1tdPWlldGYtY29ubmVjdGlvbmxlc3Mtb2FtLW1ldGhvZHMmYW1wO21v
ZHVsZXNbXT1pZXRmLWwzLXVuaWNhc3QtdG9wb2xvZ3kmYW1wO21vZHVsZXNbXT1pZXRmLWwz
LXVuaWNhc3QtdG9wb2xvZ3ktc3RhdGUmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstdG9w
b2xvZ3kmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstdG9wb2xvZ3ktc3RhdGUmYW1wO21v
ZHVsZXNbXT1pZXRmLW5ldHdvcmsmYW1wO21vZHVsZXNbXT1pZXRmLW5ldHdvcmstc3RhdGUm
YW1wO21vZHVsZXNbXT1pZXRmLWwzdnBuLXN2YyZhbXA7bW9kdWxlc1tdPWlldGYtbmV0Y29u
Zi1hY20mYW1wO21vZHVsZXNbXT1pZXRmLWludGVyZmFjZXMmYW1wO21vZHVsZXNbXT1pZXRm
LXZycnAmYW1wO21vZHVsZXNbXT1pZXRmLXJpcCZhbXA7bW9kdWxlc1tdPWlldGYtZGF0YXN0
b3JlcyZhbXA7bW9kdWxlc1tdPWlldGYtb3JpZ2luJmFtcDttb2R1bGVzW109aWV0Zi1pcHY0
LXVuaWNhc3Qtcm91dGluZyZhbXA7bW9kdWxlc1tdPWlldGYtaXB2Ni11bmljYXN0LXJvdXRp
bmcmYW1wO21vZHVsZXNbXT1pZXRmLWlwdjYtcm91dGVyLWFkdmVydGlzZW1lbnRzJmFtcDtt
b2R1bGVzW109aWV0Zi1yb3V0aW5nJmFtcDttb2R1bGVzW109aWFuYS1oYXJkd2FyZSZhbXA7
bW9kdWxlc1tdPWlldGYtaGFyZHdhcmUmYW1wO21vZHVsZXNbXT1pZXRmLWhhcmR3YXJlLXN0
YXRlJmFtcDttb2R1bGVzW109aWV0Zi1sb2dpY2FsLW5ldHdvcmstZWxlbWVudCZhbXA7bW9k
dWxlc1tdPWlldGYtbmV0d29yay1pbnN0YW5jZSZhbXA7bW9kdWxlc1tdPWlldGYtcGltLWJh
c2UmYW1wO21vZHVsZXNbXT1pZXRmLXBpbS1kbSZhbXA7bW9kdWxlc1tdPWlldGYtcGltLXNt
JmFtcDttb2R1bGVzW109aWV0Zi1waW0tYmlkaXImYW1wO21vZHVsZXNbXT1pZXRmLXBpbS1y
cCZhbXA7cmVjdXJzZT0xJmFtcDtyZmNzPTEmYW1wO3Nob3dfc3VibT0xJmFtcDtzaG93X2Rp
cj1kZXBlbmRlbmNpZXMiPm5ldw0KICAgICAgICAgICAgICAgICAgICAgICAgc2V0IG9mIFlB
TkcgbW9kdWxlIGRlcGVuZGVuY2llczwvYT4uPGJyPg0KICAgICAgICAgICAgICAgICAgICAg
IEl0IHRha2VzIGEgbGl0dGxlIGJpdCBvZiByZS1hcnJhbmdlcmluZyB0aGUNCiAgICAgICAg
ICAgICAgICAgICAgICBlbGVtZW50cywgYnV0IGFsbCB0aGUgaW5mb3JtYXRpb24gcmVnYXJk
aW5nIFlBTkcNCiAgICAgICAgICAgICAgICAgICAgICBtb2R1bGUgZGVwZW5kZW5jeSBpcyB0
aGVyZS48YnI+DQogICAgICAgICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAg
ICAgICAgIDxmb250IGNvbG9yPSIjZmYwMDAwIj5UaGUgbmV4dCBib3R0bGVuZWNrcyBmb3IN
CiAgICAgICAgICAgICAgICAgICAgICAgIHB1Ymxpc2hpbmcgdGhvc2UgWUFORyBtb2R1bGVz
IGFyZTo8YnI+DQogICAgICAgICAgICAgICAgICAgICAgICDCoMKgwqAgZHJhZnQtaWV0Zi1u
ZXRtb2Qtc2NoZW1hLW1vdW50PGJyPg0KICAgICAgICAgICAgICAgICAgICAgICAgwqDCoMKg
IGlldGYtYmZkLXlhbmcgKGN1cnJlbnRseSBpbiBXRyBMQyk8YnI+DQogICAgICAgICAgICAg
ICAgICAgICAgICDCoMKgwqAgZHJhZnQtaWV0Zi1vc3BmLXlhbmc8YnI+DQogICAgICAgICAg
ICAgICAgICAgICAgICDCoMKgwqAgZHJhZnQtaWV0Zi1pc2lzLXlhbmctaXNpcy1jZmc8YnI+
DQogICAgICAgICAgICAgICAgICAgICAgICBQbGVhc2UgcHJvZ3Jlc3MgdGhvc2UgZG9jdW1l
bnRzIGFzYXA8L2ZvbnQ+PGJyPg0KICAgICAgICAgICAgICAgICAgICAgIDxicj4NCiAgICAg
ICAgICAgICAgICAgICAgICBTb21lIG1vcmUgdXBkYXRlcyBiZWxvdy48YnI+DQogICAgICAg
ICAgICAgICAgICAgICAgPGJyPg0KICAgICAgICAgICAgICAgICAgICA8L2Rpdj4NCiAgICAg
ICAgICAgICAgICAgICAgPHU+TkVUTU9EOjwvdT48YnI+DQogICAgICAgICAgICAgICAgICAg
IMKgwqDCoCA8YQ0KICAgICAgICAgICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRy
YWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbC8iDQog
ICAgICAgICAgICAgICAgICAgICAgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIj5kcmFmdC1pZXRm
LW5ldG1vZC1zeXNsb2ctbW9kZWwtMTc8L2E+DQogICAgICAgICAgICAgICAgICAgIChpbiBJ
RVRGIExDKSA8YnI+DQogICAgICAgICAgICAgICAgICAgIMKgwqDCoCA8YQ0KICAgICAgICAg
ICAgICAgICAgICAgIGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2Ry
YWZ0LWlldGYtbmV0bW9kLWFjbC1tb2RlbC8iDQogICAgICAgICAgICAgICAgICAgICAgbW96
LWRvLW5vdC1zZW5kPSJ0cnVlIj5kcmFmdC1pZXRmLW5ldG1vZC1hY2wtbW9kZWwtMTUNCiAg
ICAgICAgICAgICAgICAgICAgPC9hPihXRyBMQyBjbG9zZWQsIHdyaXRldXAgdGltZSk8YnI+
DQogICAgICAgICAgICAgICAgICAgIMKgwqDCoCA8YQ0KICAgICAgICAgICAgICAgICAgICAg
IGhyZWY9Imh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9jL2RyYWZ0LWlldGYtbmV0
bW9kLXJmYzYwODdiaXMvIj5kcmFmdC1pZXRmLW5ldG1vZC1yZmM2MDg3YmlzLTE3PC9hPg0K
ICAgICAgICAgICAgICAgICAgICAoQUQgcmV2aWV3IGRvbmUpPGJyPg0KICAgICAgICAgICAg
ICAgICAgICDCoMKgwqAgZHJhZnQtaWV0Zi1uZXRtb2Qtc2NoZW1hLW1vdW50Ojxicj4NCiAg
ICAgICAgICAgICAgICAgICAgwqA8YnI+DQogICAgICAgICAgICAgICAgICAgIDx1Pk5FVENP
TkY6PC91Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgwqDCoMKgIFRpbWUgdG8gcHJvZ3Jl
c3MgPGEgbW96LWRvLW5vdC1zZW5kPSJ0cnVlIg0KaHJlZj0iaHR0cHM6Ly93d3cueWFuZ2Nh
dGFsb2cub3JnL3lhbmctc2VhcmNoL2ltcGFjdF9hbmFseXNpcy5waHA/bW9kdWxlc1tdPWll
dGYtdGxzLWNsaWVudCZhbXA7bW9kdWxlc1tdPWlldGYtdGxzLXNlcnZlciZhbXA7bW9kdWxl
c1tdPWlldGYtc3NoLWNsaWVudCZhbXA7bW9kdWxlc1tdPWlldGYtc3NoLXNlcnZlciZhbXA7
bW9kdWxlc1tdPWlldGYtcmVzdGNvbmYtY2xpZW50JmFtcDttb2R1bGVzW109aWV0Zi1yZXN0
Y29uZi1zZXJ2ZXImYW1wO21vZHVsZXNbXT1pZXRmLWtleXN0b3JlJmFtcDttb2R1bGVzW109
aWV0Zi1uZXRjb25mLWNsaWVudCZhbXA7bW9kdWxlc1tdPWlldGYtbmV0Y29uZi1zZXJ2ZXIm
YW1wO29yZ3NbXT1pZXRmJmFtcDtyZWN1cnNlPSZhbXA7cmZjcz0xIj50aGlzDQogICAgICAg
ICAgICAgICAgICAgICAgc2V0IG9mIGRvY3VtZW50cyAoVExTLCBTU0gsIGNsaWVudCwgc2Vy
dmVyLA0KICAgICAgICAgICAgICAgICAgICAgIGtleXN0b3JlKTwvYT48YnI+DQogICAgICAg
ICAgICAgICAgICAgIMKgwqDCoCBkcmFmdC1pZXRmLW5ldGNvbmYtcmZjNzg5NWJpcyAoaW4g
V0cgTEMpPGJyPg0KICAgICAgICAgICAgICAgICAgICDCoMKgwqAgwqDCoMKgIFN0YXR1czog
VW5kZXIgZGlzY3Vzc2lvbiBpbiBORVRDT05GPGJyPg0KICAgICAgICAgICAgICAgICAgICA8
YnI+DQogICAgICAgICAgICAgICAgICAgIDx1PkxJTUU6PC91Pjxicj4NCiAgICAgICAgICAg
ICAgICAgICAgwqDCoMKgDQogICAgICAgICAgICAgICAgICAgIGRyYWZ0LWlldGYtbGltZS15
YW5nLWNvbm5lY3Rpb24tb3JpZW50ZWQtb2FtLW1vZGVsLTA1DQogICAgICAgICAgICAgICAg
ICAgIChuZXh0IElFU0cgdGVsZWNoYXQpPGJyPg0KICAgICAgICAgICAgICAgICAgICA8YnI+
DQogICAgICAgICAgICAgICAgICAgIDx1Pk9QU0FXRzo8L3U+PGJyPg0KICAgICAgICAgICAg
ICAgICAgICDCoMKgwqAgPGENCiAgICAgICAgICAgICAgICAgICAgICBocmVmPSJodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLW9wc2F3Zy1uYXQteWFuZy8i
PmRyYWZ0LWlldGYtb3BzYXdnLW5hdC15YW5nLTEyPC9hPg0KICAgICAgICAgICAgICAgICAg
ICAoaW4gV0cgTEMpPGJyPg0KICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAg
ICAgICAgICAgIDx1PkwyU006PC91Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgwqDCoMKg
IDxhDQpocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRm
LWwyc20tbDJ2cG4tc2VydmljZS1tb2RlbC8iPmRyYWZ0LWlldGYtbDJzbS1sMnZwbi1zZXJ2
aWNlLW1vZGVsLTA2PC9hPg0KICAgICAgICAgICAgICAgICAgICAoaW4gV0cgTEMpPGJyPg0K
ICAgICAgICAgICAgICAgICAgICA8YnI+DQogICAgICAgICAgICAgICAgICAgIDx1PkkyUlM6
PC91Pjxicj4NCiAgICAgICAgICAgICAgICAgICAgwqDCoMKgIDxhDQpocmVmPSJodHRwczov
L2RhdGF0cmFja2VyLmlldGYub3JnL2RvYy9kcmFmdC1pZXRmLWkycnMteWFuZy1kYy1mYWJy
aWMtbmV0d29yay10b3BvbG9neS8iPmRyYWZ0LWlldGYtaTJycy15YW5nLWRjLWZhYnJpYy1u
ZXR3b3JrLXRvcG9sb2d5LTA2PC9hPg0KICAgICAgICAgICAgICAgICAgICAob24gdGhlIElF
U0cgdGVsZWNoYXQpPGJyPg0KICAgICAgICAgICAgICAgICAgICDCoMKgwqAgPGENCiAgICAg
ICAgICAgICAgICAgICAgICBocmVmPSJodHRwczovL2RhdGF0cmFja2VyLmlldGYub3JnL2Rv
Yy9kcmFmdC1pZXRmLWkycnMtcmliLWRhdGEtbW9kZWwvIj5kcmFmdC1pZXRmLWkycnMtcmli
LWRhdGEtbW9kZWwtMTA8L2E+DQogICAgICAgICAgICAgICAgICAgIChvbiB0aGUgSUVTRyB0
ZWxlY2hhdCk8YnI+DQogICAgICAgICAgICAgICAgICAgIMKgwqDCoCA8YnI+DQogICAgICAg
ICAgICAgICAgICAgIFJlZ2FyZHMsIEJlbm9pdDxicj4NCiAgICAgICAgICAgICAgICAgIDwv
ZGl2Pg0KICAgICAgICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgICAgICA8L2Rpdj4NCiAg
ICAgICAgICAgIDwvZGl2Pg0KICAgICAgICAgIDwvZGl2Pg0KICAgICAgICA8L2Rpdj4NCiAg
ICAgIDwvZGl2Pg0KICAgIDwvZGl2Pg0KICA8L2JvZHk+DQo8L2h0bWw+DQo=
--------------D7A329188AF94DB6EA62CBAF--


From nobody Fri Feb 16 03:20:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A07BA126D46; Fri, 16 Feb 2018 03:20:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OrrIJjwDVWn7; Fri, 16 Feb 2018 03:20:47 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 482C21201F8; Fri, 16 Feb 2018 03:20:46 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13671; q=dns/txt; s=iport; t=1518780046; x=1519989646; h=subject:to:references:from:message-id:date:mime-version: in-reply-to; bh=MR3+zP86uRN+m+toYIg4pVQHiCV9WN/8+yP5jpBJ1Tc=; b=jdBlT4PMV12ijGsGA6k/WEofa5O4kmr7KLL+vPit0enKLLgZSYTP8PnH 6ai+qg4pqRDY1XqHQtp9fJbhUYpc2taAyTIfhwToobdO+aPTvMPNd+2KZ pCxb5umElhdDF0IGdpY/WLNUxyCzdiogDZvJh9G4ORpG4pSNdClVBIIhH I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0A+AQCUvYZa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJagVtwKINUiiV0jmongReQbYVcghYKGAEJhEpPAoMZGAECAQE?= =?us-ascii?q?BAQEBAmsoCQWFFQEBAQECAQEBIUsbCw4KJwMCAicfEQYBDAYCAQGKFQgQrgiCJ?= =?us-ascii?q?yaEW4N7ghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEYBYUEg3+CEQyCeYMwAQEBARm?= =?us-ascii?q?BNgEBCIMtgmUFpDUJiCSNZoIghiqDcyaHZY4GgX+IGoE8HzmBUTMaCBsVOoJDh?= =?us-ascii?q?HZBNwEBAYs+gj4BAQE?=
X-IronPort-AV: E=Sophos;i="5.46,519,1511827200"; d="scan'208,217";a="2054311"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2018 11:20:42 +0000
Received: from [10.63.23.94] (dhcp-ensft1-uk-vla370-10-63-23-94.cisco.com [10.63.23.94]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1GBKfnw029264; Fri, 16 Feb 2018 11:20:42 GMT
To: Kent Watsen , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com> <87y3jtjob5.fsf@nic.cz>
From: Robert Wilton 
Message-ID: <11a7c859-6d8c-2f67-9918-b3aa5cc77dfa@cisco.com>
Date: Fri, 16 Feb 2018 11:20:41 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <87y3jtjob5.fsf@nic.cz>
Content-Type: multipart/alternative; boundary="------------933F974A5891E924EAD53E30"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Feb 2018 11:20:49 -0000

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

Hi Lada,


On 16/02/2018 09:06, Ladislav Lhotka wrote:
> Robert Wilton  writes:
>
>> I should add, as a contributor, I have read this document and think that
>> is ready for advancement.
>>
>> I have three minor comments:
>>
>> 1) module "feature" in YANG library is a leaf-list, but currently it is
>> a list in YANG libary bis. I suspect that this is due to one of the
>> incarnations when it contained additional information.  I think that we
>> should revert it back to being a leaf list for consistency.
>>
>> 2) Lada recommended that module "deviation" be made a leaf-list. I also
>> support changing this for consistency with "feature" above, but don't
>> feel too strongly on this one.
> I agree to have both as leaf-lists.
>
>> 3) I think the "modules" list is also allowed to included modules that
>> don't actually contain any nodes that require implementation.  Hence, it
>> might be useful of the "modules" description statement explicitly stated
>> this.  I.e. perhaps something like:
>>
>> "This list may contain modules that do not contain any schema nodes that
>> require implementation.  For example, it could contain a module that
>> only defines types and not any data nodes, RPCs, actions, notifications,
>> or deviations."
> Hmm, such modules belong to the other list "import-only-modules", don't
> they?
So my reasoning is that either is valid.

I.e. a module being listed under "modules" means that it implements all 
data nodes, RPCs, actions, notifications, deviations, etc.  If a module 
doesn't contain any data nodes, RPCs, actions, notifications, 
deviations, etc then it is trivially implemented :-)

As an aside, RFC 7950 states in 5.6.5:

  A server implements a module if it implements the module's data
    nodes, RPCs, actions, notifications, and deviations.


I wonder whether identities shouldn't also be on this list, since 
section 9.10.2 states:

On a particular server, the valid values are further restricted
to the set of identities defined in the modules implemented by the server.


Thanks,
Rob


>
> Lada
>
>> Thanks,
>> Rob
>>
>>
>> On 02/02/2018 13:51, Kent Watsen wrote:
>>> As co-author, I am not aware of any IPR related to this document.
>>>
>>> As a contributor, I have read this document and think that it is ready
>>> for advancement.
>>>
>>> Kent
>>>
>>> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
>>>  on behalf
>>> of rwilton@cisco.com > wrote:
>>>
>>> I am not aware of any IPR related to this document.
>>>
>>> Thanks,
>>> Rob
>>>
>>> On 01/02/2018 18:59, Mahesh Jethanandani wrote:
>>>
>>>      WG,
>>>
>>>      The authors of rfc7895bis have indicated that they believe the
>>>      document is ready for LC[1].
>>>
>>>      This starts a two week LC on the draft
>>>      .
>>>      The LC will end on February 15.
>>>
>>>      Please send your comments on this thread. Reviews of the document,
>>>      and statement of support are particularly helpful to the authors.
>>>      If you have concerns about the document, please state those too.
>>>
>>>      Authors please indicate if you are aware of any IPR on the document.
>>>
>>>      Thanks.
>>>
>>>      [1]
>>>      https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>>>      
>>>
>>>      Mahesh & Kent
>>>
>>>
>>>
>>>
>>>      _______________________________________________
>>>
>>>      Netconf mailing list
>>>
>>>      Netconf@ietf.org 
>>>
>>>      https://www.ietf.org/mailman/listinfo/netconf
>>>      
>>>
>>>
>>>
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf


--------------933F974A5891E924EAD53E30
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 8bit


  
    
  
  
    
Hi Lada,

    

    

    
On 16/02/2018 09:06, Ladislav Lhotka
      wrote:

    

    

      
Robert Wilton <rwilton@cisco.com> writes:



      

        
I should add, as a contributor, I have read this document and think that 
is ready for advancement.

I have three minor comments:

1) module "feature" in YANG library is a leaf-list, but currently it is 
a list in YANG libary bis. I suspect that this is due to one of the 
incarnations when it contained additional information.  I think that we 
should revert it back to being a leaf list for consistency.

2) Lada recommended that module "deviation" be made a leaf-list. I also 
support changing this for consistency with "feature" above, but don't 
feel too strongly on this one.


      

      
I agree to have both as leaf-lists.



      

        
3) I think the "modules" list is also allowed to included modules that 
don't actually contain any nodes that require implementation.  Hence, it 
might be useful of the "modules" description statement explicitly stated 
this.  I.e. perhaps something like:

"This list may contain modules that do not contain any schema nodes that 
require implementation.  For example, it could contain a module that 
only defines types and not any data nodes, RPCs, actions, notifications, 
or deviations."


      

      
Hmm, such modules belong to the other list "import-only-modules", don't
they?

    

    So my reasoning is that either is valid.

    

    I.e. a module being listed under "modules" means that it implements
    all data nodes, RPCs, actions, notifications, deviations, etc.  If a
    module doesn't contain any data nodes, RPCs, actions, notifications,
    deviations, etc then it is trivially implemented :-)

    

    As an aside, RFC 7950 states in 5.6.5:

    
 A server implements a module if it implements the module's data
   nodes, RPCs, actions, notifications, and deviations.

    

    I wonder whether identities shouldn't also be on this list, since
    section 9.10.2 states:

    

    
On a particular server, the valid values are further restricted
to the set of identities defined in the modules implemented by the server.

    

    Thanks,

    Rob

    

    

    

      

Lada



      

        
Thanks,
Rob


On 02/02/2018 13:51, Kent Watsen wrote:


        

          
As co-author, I am not aware of any IPR related to this document.

As a contributor, I have read this document and think that it is ready 
for advancement.

Kent

On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton" 
<netconf-bounces@ietf.org <mailto:netconf-bounces@ietf.org> on behalf 
of rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:

I am not aware of any IPR related to this document.

Thanks,
Rob

On 01/02/2018 18:59, Mahesh Jethanandani wrote:

    WG,

    The authors of rfc7895bis have indicated that they believe the
    document is ready for LC[1].

    This starts a two week LC on the draft
    <https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dnetconf-2Drfc7895bis-2D04&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&s=MqbVljnYqIk9w78kcfp7oUqGR-qVoNV90njyTwLAdpc&e=>.
    The LC will end on February 15.

    Please send your comments on this thread. Reviews of the document,
    and statement of support are particularly helpful to the authors.
    If you have concerns about the document, please state those too.

    Authors please indicate if you are aware of any IPR on the document.

    Thanks.

    [1]
    https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
    <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mail-2Darchive_web_netconf_current_msg13980.html&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&s=XhRSSTWifO-SkPi2CWK5Z5aUni2F1qRQ8Moj7T7gI-Y&e=>

    Mahesh & Kent




    _______________________________________________

    Netconf mailing list

    Netconf@ietf.org <mailto:Netconf@ietf.org>

    https://www.ietf.org/mailman/listinfo/netconf
    <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_netconf&d=DwMD-g&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=fi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&s=mcDF-v5I4epgsuWLHvr32pZ5mRonROKN8zpKcZWBC0o&e=>





        

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


      

      

    

    

  


--------------933F974A5891E924EAD53E30--


From nobody Fri Feb 16 07:34:01 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5927A1270A7; Fri, 16 Feb 2018 07:34:00 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id stkggRiKLhYS; Fri, 16 Feb 2018 07:33:57 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id B26E1120725; Fri, 16 Feb 2018 07:33:56 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id CB1211820413; Fri, 16 Feb 2018 16:31:47 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id E6DAE18203DE; Fri, 16 Feb 2018 16:31:44 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , Kent Watsen , Mahesh Jethanandani , NETCONF WG ,  NETMOD WG 
In-Reply-To: <11a7c859-6d8c-2f67-9918-b3aa5cc77dfa@cisco.com>
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com> <87y3jtjob5.fsf@nic.cz> <11a7c859-6d8c-2f67-9918-b3aa5cc77dfa@cisco.com>
Mail-Followup-To: Robert Wilton , Kent Watsen , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
Date: Fri, 16 Feb 2018 16:33:52 +0100
Message-ID: <87po55ne3j.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Feb 2018 15:34:00 -0000

Robert Wilton  writes:

> Hi Lada,
>
>
> On 16/02/2018 09:06, Ladislav Lhotka wrote:
>> Robert Wilton  writes:
>>
>>> I should add, as a contributor, I have read this document and think that
>>> is ready for advancement.
>>>
>>> I have three minor comments:
>>>
>>> 1) module "feature" in YANG library is a leaf-list, but currently it is
>>> a list in YANG libary bis. I suspect that this is due to one of the
>>> incarnations when it contained additional information.=C2=A0 I think th=
at we
>>> should revert it back to being a leaf list for consistency.
>>>
>>> 2) Lada recommended that module "deviation" be made a leaf-list. I also
>>> support changing this for consistency with "feature" above, but don't
>>> feel too strongly on this one.
>> I agree to have both as leaf-lists.
>>
>>> 3) I think the "modules" list is also allowed to included modules that
>>> don't actually contain any nodes that require implementation.=C2=A0 Hen=
ce, it
>>> might be useful of the "modules" description statement explicitly stated
>>> this.=C2=A0 I.e. perhaps something like:
>>>
>>> "This list may contain modules that do not contain any schema nodes that
>>> require implementation.=C2=A0 For example, it could contain a module th=
at
>>> only defines types and not any data nodes, RPCs, actions, notifications,
>>> or deviations."
>> Hmm, such modules belong to the other list "import-only-modules", don't
>> they?
> So my reasoning is that either is valid.
>
> I.e. a module being listed under "modules" means that it implements all=20
> data nodes, RPCs, actions, notifications, deviations, etc.=C2=A0 If a mod=
ule=20
> doesn't contain any data nodes, RPCs, actions, notifications,=20
> deviations, etc then it is trivially implemented :-)

OK, so if a module contains only groupings and typedefs, it can appear
either in "modules" or in "import-only-modules", and the effect is the
same, right?

This sounds reasonable.

>
> As an aside, RFC 7950 states in 5.6.5:
>
>   A server implements a module if it implements the module's data
>     nodes, RPCs, actions, notifications, and deviations.
>
>
> I wonder whether identities shouldn't also be on this list, since=20
> section 9.10.2 states:

Yes, and extensions as well.

Lada

>
> On a particular server, the valid values are further restricted
> to the set of identities defined in the modules implemented by the server.
>
>
> Thanks,
> Rob
>
>
>>
>> Lada
>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 02/02/2018 13:51, Kent Watsen wrote:
>>>> As co-author, I am not aware of any IPR related to this document.
>>>>
>>>> As a contributor, I have read this document and think that it is ready
>>>> for advancement.
>>>>
>>>> Kent
>>>>
>>>> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
>>>>  on behalf
>>>> of rwilton@cisco.com > wrote:
>>>>
>>>> I am not aware of any IPR related to this document.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>> On 01/02/2018 18:59, Mahesh Jethanandani wrote:
>>>>
>>>>      WG,
>>>>
>>>>      The authors of rfc7895bis have indicated that they believe the
>>>>      document is ready for LC[1].
>>>>
>>>>      This starts a two week LC on the draft
>>>>      .
>>>>      The LC will end on February 15.
>>>>
>>>>      Please send your comments on this thread. Reviews of the document,
>>>>      and statement of support are particularly helpful to the authors.
>>>>      If you have concerns about the document, please state those too.
>>>>
>>>>      Authors please indicate if you are aware of any IPR on the docume=
nt.
>>>>
>>>>      Thanks.
>>>>
>>>>      [1]
>>>>      https://www.ietf.org/mail-archive/web/netconf/current/msg13980.ht=
ml
>>>>      
>>>>
>>>>      Mahesh & Kent
>>>>
>>>>
>>>>
>>>>
>>>>      _______________________________________________
>>>>
>>>>      Netconf mailing list
>>>>
>>>>      Netconf@ietf.org 
>>>>
>>>>      https://www.ietf.org/mailman/listinfo/netconf
>>>>      
>>>>
>>>>
>>>>
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf
>
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> https://www.ietf.org/mailman/listinfo/netconf

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


From nobody Fri Feb 16 08:04:16 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD6C126579; Fri, 16 Feb 2018 08:04:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gyGw2BiFgfxR; Fri, 16 Feb 2018 08:04:13 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 57092120454; Fri, 16 Feb 2018 08:04:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5566; q=dns/txt; s=iport; t=1518797052; x=1520006652; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=JmdvFMn6xGNrskL/oO9zCwwl23ZAY8RJPYpQL27Gu7w=; b=I/znh6jAFr1EysQxr3ApXt5FDGiEtke+OiBlEyp2Vu0mdJCAt/7MCWUU yP7lHcsic5EknUtGaRjhIYZwSDEW2JocKlldRQU0HhdSiEt1SrbAj/4Vz ysIY28okbm0jB80j+JgpIwLm7UBk4pYsT7WGSh5hMONhKkrE/G5lWYPs6 Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CjAAAvAIda/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ1cCiDVIoldI5rJ4EXlkmCFgoYC4RJTwKDGhgBAgEBAQEBAQJ?= =?us-ascii?q?rKIUjAQEBAQIBAQEhDwEFNhsLDgoCAiMDAgInHxEGAQwGAgEBihUIEK1EgieFA?= =?us-ascii?q?YN6ghMBAQEBAQEBAQEBAQEBAQEBAQEBARkFgQ+DeIN/ghEMgnmDMAEBAYFQAQE?= =?us-ascii?q?Igy2CZQWkNQmWCgKCHoYqg3Mmh2WQBYgagTwfOYFRMxoIGxU6gkOEdkE3AYtng?= =?us-ascii?q?j4BAQE?=
X-IronPort-AV: E=Sophos;i="5.46,519,1511827200";  d="scan'208";a="2063962"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Feb 2018 16:04:08 +0000
Received: from [10.63.23.94] (dhcp-ensft1-uk-vla370-10-63-23-94.cisco.com [10.63.23.94]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1GG48XV022593; Fri, 16 Feb 2018 16:04:08 GMT
To: Kent Watsen , Mahesh Jethanandani , NETCONF WG , NETMOD WG 
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com> <87y3jtjob5.fsf@nic.cz> <11a7c859-6d8c-2f67-9918-b3aa5cc77dfa@cisco.com> <87po55ne3j.fsf@nic.cz>
From: Robert Wilton 
Message-ID: <98935845-4f6d-230a-9aba-7eff7ed0cef4@cisco.com>
Date: Fri, 16 Feb 2018 16:04:08 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <87po55ne3j.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 16 Feb 2018 16:04:15 -0000

On 16/02/2018 15:33, Ladislav Lhotka wrote:
> Robert Wilton  writes:
>
>> Hi Lada,
>>
>>
>> On 16/02/2018 09:06, Ladislav Lhotka wrote:
>>> Robert Wilton  writes:
>>>
>>>> I should add, as a contributor, I have read this document and think that
>>>> is ready for advancement.
>>>>
>>>> I have three minor comments:
>>>>
>>>> 1) module "feature" in YANG library is a leaf-list, but currently it is
>>>> a list in YANG libary bis. I suspect that this is due to one of the
>>>> incarnations when it contained additional information.  I think that we
>>>> should revert it back to being a leaf list for consistency.
>>>>
>>>> 2) Lada recommended that module "deviation" be made a leaf-list. I also
>>>> support changing this for consistency with "feature" above, but don't
>>>> feel too strongly on this one.
>>> I agree to have both as leaf-lists.
>>>
>>>> 3) I think the "modules" list is also allowed to included modules that
>>>> don't actually contain any nodes that require implementation.  Hence, it
>>>> might be useful of the "modules" description statement explicitly stated
>>>> this.  I.e. perhaps something like:
>>>>
>>>> "This list may contain modules that do not contain any schema nodes that
>>>> require implementation.  For example, it could contain a module that
>>>> only defines types and not any data nodes, RPCs, actions, notifications,
>>>> or deviations."
>>> Hmm, such modules belong to the other list "import-only-modules", don't
>>> they?
>> So my reasoning is that either is valid.
>>
>> I.e. a module being listed under "modules" means that it implements all
>> data nodes, RPCs, actions, notifications, deviations, etc.  If a module
>> doesn't contain any data nodes, RPCs, actions, notifications,
>> deviations, etc then it is trivially implemented :-)
> OK, so if a module contains only groupings and typedefs, it can appear
> either in "modules" or in "import-only-modules", and the effect is the
> same, right?
Yes.

>
> This sounds reasonable.
>
>> As an aside, RFC 7950 states in 5.6.5:
>>
>>    A server implements a module if it implements the module's data
>>      nodes, RPCs, actions, notifications, and deviations.
>>
>>
>> I wonder whether identities shouldn't also be on this list, since
>> section 9.10.2 states:
> Yes, and extensions as well.
>
> Lada
Thanks,
Rob

>
>> On a particular server, the valid values are further restricted
>> to the set of identities defined in the modules implemented by the server.
>>
>>
>> Thanks,
>> Rob
>>
>>
>>> Lada
>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> On 02/02/2018 13:51, Kent Watsen wrote:
>>>>> As co-author, I am not aware of any IPR related to this document.
>>>>>
>>>>> As a contributor, I have read this document and think that it is ready
>>>>> for advancement.
>>>>>
>>>>> Kent
>>>>>
>>>>> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
>>>>>  on behalf
>>>>> of rwilton@cisco.com > wrote:
>>>>>
>>>>> I am not aware of any IPR related to this document.
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>> On 01/02/2018 18:59, Mahesh Jethanandani wrote:
>>>>>
>>>>>       WG,
>>>>>
>>>>>       The authors of rfc7895bis have indicated that they believe the
>>>>>       document is ready for LC[1].
>>>>>
>>>>>       This starts a two week LC on the draft
>>>>>       .
>>>>>       The LC will end on February 15.
>>>>>
>>>>>       Please send your comments on this thread. Reviews of the document,
>>>>>       and statement of support are particularly helpful to the authors.
>>>>>       If you have concerns about the document, please state those too.
>>>>>
>>>>>       Authors please indicate if you are aware of any IPR on the document.
>>>>>
>>>>>       Thanks.
>>>>>
>>>>>       [1]
>>>>>       https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>>>>>       
>>>>>
>>>>>       Mahesh & Kent
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>       _______________________________________________
>>>>>
>>>>>       Netconf mailing list
>>>>>
>>>>>       Netconf@ietf.org 
>>>>>
>>>>>       https://www.ietf.org/mailman/listinfo/netconf
>>>>>       
>>>>>
>>>>>
>>>>>
>>>> _______________________________________________
>>>> Netconf mailing list
>>>> Netconf@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netconf
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org
>> https://www.ietf.org/mailman/listinfo/netconf


From nobody Sat Feb 17 17:20:54 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B530B12D872; Sat, 17 Feb 2018 17:20:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.099
X-Spam-Level: 
X-Spam-Status: No, score=-0.099 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Y1BpHA6d8PBf; Sat, 17 Feb 2018 17:20:49 -0800 (PST)
Received: from mail-pl0-x231.google.com (mail-pl0-x231.google.com [IPv6:2607:f8b0:400e:c01::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 7FFEB12D874; Sat, 17 Feb 2018 17:20:49 -0800 (PST)
Received: by mail-pl0-x231.google.com with SMTP id p5so3731722plo.12; Sat, 17 Feb 2018 17:20:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=psFK7Viwdpj3ykUPulgDUPGbYJzcv6ulDIL7UWa2ykg=; b=fcOsVIK27EH9l3Wu+zURiWO+luVdS0koA7wrgWLxfrGr2B3DpwtJbQqA+w33ulgh7B 6W+46xy0QudP0Eece9z/7cxkj6utpyPAPHcjwmGLkJuUubWBkDekS6Nlz1hYZf+S3n2U 2qU4SoVQG1rz0ManwSrqNfbIec8HsuWX8Fh0Jbp/8ouGn+emeHiQbOgHkpO6twzormIR 5LEGvKYuU266brCYEivKO/2hHdlCHIGT58JfFs0fiN0eE4cvGrmxRHPzZ0/SvKLLACBE Zv78UUXbKwTU+Lbx70mrE2cz2O9W4mln4C+oxYT9EcuBflKOVywDE0FQPI7UCxpaPKvJ tudg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=psFK7Viwdpj3ykUPulgDUPGbYJzcv6ulDIL7UWa2ykg=; b=SJWlaA2q5ZJ5c8g5LS0cdM8ZtoeiTaq0gd2LsV8XA/RhXvpIoO+6Vp+Zkcy5W2phuo HZdsNJdNgLtzcX+F/MSlxEf4Yzho2jE1KyHmv5nfHJXXOLhGoDNV4QuGTG6bKAJzt+He y3rl2h5l4ZnnqEioAXdnmv38JO4/fjo3cNYCpfZjlA6uoY7TIgmarM6N1y1NnYrVEl6w CBqtlT1u0gqjn6QrNFPlEpJ/ohIUkv+np4UxsENCe59D/XO9DcOGR6ZBFSlzT6GW/iTR usBO5BdNhxdfXxlw8n9fCUKe/ZAHJ71KF4yaD6D5lNC3U0nqN+7WRfCUiIFp3e4a7Dyu COJA==
X-Gm-Message-State: APf1xPBtncb4dOOYF3A6aGFZqdzz5XDe7yTIIYDvK3s+cVeCLf6+sfpo S1X1J7b44S3coXb5xWR42S8zu9Me
X-Google-Smtp-Source: AH8x2241tmklhZ/MKdhNct/L6rMpiT2h4rtAiZUah7frJEZoJhFrYTqp7kJJFuiyiUkBGYEnDryftw==
X-Received: by 2002:a17:902:f81:: with SMTP id 1-v6mr9817381plz.265.1518916848798;  Sat, 17 Feb 2018 17:20:48 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:91a0:5e0b:a8bb:ae? ([2601:647:4700:1280:91a0:5e0b:a8bb:ae]) by smtp.gmail.com with ESMTPSA id k13sm9427042pfk.22.2018.02.17.17.20.47 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sat, 17 Feb 2018 17:20:48 -0800 (PST)
From: Mahesh Jethanandani 
Message-Id: <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_B437985A-7462-4213-8708-2A8397C4C07C"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Sat, 17 Feb 2018 17:26:13 -0800
In-Reply-To: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net>
Cc: "draft-ietf-netmod-acl-model@ietf.org" ,  "netmod@ietf.org" 
To: Kent Watsen 
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Feb 2018 01:20:53 -0000

--Apple-Mail=_B437985A-7462-4213-8708-2A8397C4C07C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Kent,

Thanks for a detailed review. See inline.

> On Feb 13, 2018, at 2:30 PM, Kent Watsen  wrote:
>=20
> [sorry, wrong WG, moving netconf to BCC!]
>=20
>=20
> ACL Authors,
>=20
> Below are some issues I found while looking at doing the Shepherd
> write-up today.  Please take a look.
>=20
> Also, with regards to the request for those having Last Call comments
> to please verify that their comments were addressed, I only saw one
> response from Kristian, but should we be expecting respeonses from
> others too, perhaps Einar or Elliot?

Eliot can confirm if he feels his issues have been addressed.

>=20
>=20
> 1 IDNITS
>=20
>  - some issues found by idnits
>  - using =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_tools_=
idnits_&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zk=
P0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7Bx3hgofSFxvNRV7Xz7FuaJcKKfzE=
B0sBJzN_KOCtSg&s=3D_5f-lxCoJW2TidcrjW_KbDkdPhfxLoL67kn1A2okgs0&e=3D
>  - without selecting "verbose output"
>=20
>=20
> 1.1
>=20
>  ** There are 5 instances of too long lines in the document, the =
longest one
>     being 5 characters in excess of 72.

Fixed.

>=20
>=20
>  This "**" is being flagged as an "error". =20
>  Idnits label, not mine.  Please fix.
>=20
>=20
> 1.2
>=20
>  =3D=3D There are 7 instances of lines with non-RFC6890-compliant IPv4 =
addresses
>     in the document.  If these are example addresses, they should be =
changed.
>=20
>  This is just a warning, but given that there are seven occurrences, =
it
>  might be a good idea to fix.  Please see Section 3, point #6 in this
>  document for details: =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_id-2Di=
nfo_checklist&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=
=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7Bx3hgofSFxvNRV7Xz7FuaJ=
cKKfzEB0sBJzN_KOCtSg&s=3DAYo8ZHPY4SAHMqcy1qV9yr7BjoxGy_C9zcJ_ZbwXBT4&e=3D.=


Fixed.

>=20
>=20
> 1.3
>=20
>  ** The document seems to lack a both a reference to RFC 2119 and the
>     recommended RFC 2119 boilerplate, even if it appears to use RFC =
2119
>     keywords.=20
>=20
>     RFC 2119 keyword, line 797: '...s-list. A device MAY restrict the =
leng...'
>=20
>=20
>  There needs to be a section that looks like RFC 8174, paragraph 11:
>=20
>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =
NOT",
>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
>     and "OPTIONAL" in this document are to be interpreted as
>     described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>     appear in all capitals, as shown here.

Added.

>=20
>=20
> 1.4.
>=20
>  -- The document date (February 2, 2018) is 11 days in the past.  Is =
this
>     intentional?
>=20
>  This is fine, ignore it.
>=20
> 1.5
>=20
>  ** Obsolete normative reference: RFC 2460
>=20
>  This needs to be fixed.

Updated the reference to RFC 8200.

>=20
> 1.6
>=20
>  ** Downref: Normative reference to an Historic RFC: RFC 3540
>=20
>  Hmmmm, another HISTORIC document, but this time not due to an IESG
>  action.  The question is how important this reference is, is this
>  "ns" bit (ECN-nonce concealment protection) commonly used in the=20
>  industry?  =20

I do not know enough to know it is not used. If the consensus is that we =
do not use it, I can drop it from the model.

>=20
> 1.7
>=20
>  =3D=3D Outdated reference: A later version (-06) exists of
>     draft-ietf-netmod-yang-tree-diagrams-04
>=20
>  Please update to -06

This might be because the draft was last published when -04 was around. =
I do not reference any particular version. My reference is to=20
. =
The tool pulls in the latest when it generates the draft.

>=20
> 1.8
>=20
>  -- Obsolete informational reference (is this intentional?): RFC 5101
>     (Obsoleted by RFC 7011)
>=20
>  Please update to RFC 7011

Done.

>=20
>=20
>=20
> 2  YANG VALIDATION
>=20
> 2.1 Normative Modules
>=20
>  All of the following passed:
>=20
>    pyang --ietf ietf-access-control-list\@2018-02-02.yang=20
>    pyang --ietf ietf-packet-fields\@2018-02-02.yang=20
>    pyang --ietf ietf-ethertypes\@2018-02-02.yang
>=20
>    yanglint -s ietf-access-control-list\@2018-02-02.yang=20
>    yanglint -s ietf-packet-fields\@2018-02-02.yang=20
>    yanglint -s ietf-ethertypes\@2018-02-02.yang=20
>=20
> 2.2 Example Module
>=20
>  Example module passed `yanglint -s`, but not `pyang --lint`:
>=20
>    yanglint -s example-newco-acl.yang
>    pyang --lint example-newco-acl.yang=20
>=20
>    example-newco-acl.yang:78: error: keyword "description" not in
>    canonical order, expected "type", (See RFC 6020, Section 12)
>=20
>    example-newco-acl.yang:79: error: keyword "type" not in=20
>    canonical order, (See RFC 6020, Section 12)
>=20
>    example-newco-acl.yang:82: error: keyword "default" not in=20
>    canonical order, (See RFC 6020, Section 12)
>=20
>  Please fix.

Fixed.

>=20
>=20
> 2.3 XML Examples from Section 4.3
>=20
>  yanglint didn't find any issues:
>=20
>    yanglint ietf-access-control-list\@2018-02-02.yang ex-4.3.xml=20
>=20
>=20
> 2.4 Examples from Section 4.4
>=20
>  I had to stitch these into the 4.3 example.  It found one issue, a =
typo
>  in the last closing tag in the first example in this section:
>=20
>    yanglint ietf-access-control-list\@2018-02-02.yang ex-4.4++.xml=20
>    err : Invalid (mixed names) opening (source-port-range-or-operator) =
and closing (tcp) element tags. =
(/data/access-lists/acl/aces/ace/matches/l4/tcp/source-port-range-or-opera=
tor/source-port-range-or-operator)
>=20
>  Please fix.

Made them complete examples so you do not have to stitch them anymore. =
And made sure yanglint validated the examples before it includes it in =
the draft.

>=20
>=20
>  PS: And this is not a shepherd directive, but I found the whole=20
>      "source-port-range-or-operator" syntax clumsy.  I'm surprised
>      it didn't look something like:
>=20
>          OLD
>                
>                   
>                     
>                       16384
>                       65535
>                     
>                   
>                
>=20
>                
>                  
>                    
>                      eq
>                      21
>                    
>                  
>                
>=20
>          NEW
>=20
>                
>                  
>                    16384
>                    65535
>                  
>                
>=20
>                
>                  
>                    eq
>                    21
>                  
>                
>=20

Did you try making the change in the model to see if it work? It will =
complain that  is already used within the container and that it =
cannot be repeated (for destination-port).

>=20
>=20
> 3 Key Draft Sections
>=20
>=20
> 3.1 Abstract
>=20
>  First, I'm unsure if that first "sentence" is properly worded, but I
>  definitely think that it is a bit too much on the terse side.  Can =
you
>  embellish it a little?

How about this:

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

  This document describes a data model for Access Control List (ACL). =20=

  ACL is a ordered-by-user set of rules, used to configure the =
forwarding=20
  behavior in device.  Each rule is used to find a match on a packet,=20
  and define actions that will be performed on the packet.

>=20
>  Second, am I reading it correct? - is the "Editorial Note" in the
>  Abstract section.  I strongly advise moving=20

Moved it to Introduction section.

>=20
> 3.2 RFC Editor Note
>=20
>  There is no request to replace "I-D.ietf-netmod-yang-tree-diagrams" =
with
>  the final RFC assignment.

Added.

>=20
>  You might want to add what the current date value used in the draft =
is
>  (i.e., 2018-02-02).   PS: my draft build tools, which I think you're
>  using, should set the value for you automatically if you put =
YYYY-MM-DD
>  into the text.

Added text to replace the revision date in the model with the date the =
draft gets published.

>=20
> 3.3 Import statements missing references
>=20
>  All import statements in all modules are missing reference statements
>     - why wasn't this caught by the tools?!
>=20
>  Please see rfc6087bis Section 4.7. =20

Adding reference implies import by revision, which we want to avoid, =
specially since we do not want to import by revision. Right?

>=20
>=20
> 3.4 Security Considerations
>=20
>  Please reformat the last paragraph so the "aces" path is more =
pronounced.
>  Perhaps use hangText.

What is hangText? I italicized it.

>=20
>=20
> 3.5 IANA Considerations
>=20
>  This section is hard to read.
>=20
>  Consideration breaking up the "XML" and the "YANG Module Names" =
registry
>  requests into two subsections.
>=20
>  Consider making the registration entry requests themselves artwork so
>  they're line-spaced and indented as such.
>=20
>  The first paragraph of the "XML" registry request says "a URI", but =
it=20
>  should be "two URIs"
>=20
>  The first paragraph of the "YANG Module Names" registry request says=20=

>  "a YANG module", but it should be "two YANG modules=E2=80=9D

Split into two sections and upped the count of URIs and YANG models to =
three (was missing the ietf-ethertypes module).

>=20
>=20
> 3.6 References
>=20
>  I haven't checked yet, but please verify that all the references are
>  properly sorted as to being Normative or Informative.
>=20
>=20
> 3.7 Appendix A
>=20
>  It took me awhile to figure out what I was looking at.  The =
tree-diagram
>  is poorly indented and there is no text preceding the example module.=20=


I have moved the example module after the first paragraph, that =
describes the module. Let me know if that looks ok.

>=20
>  I recommend you fold the lines of your tree diagram at a certain =
column
>  whilst adding a '\' character.  I've since added this ability to my =
draft
>  build tools, let me know if interested in an update.  You might also =
want
>  to look at draft-wu-netmod-yang-xml-doc-conventions.

Shortened the prefix so the augment statement fits within 72 columns.=20

BTW, I use 'pyang  -f tree =E2=80=94tree-line-length=3D69' to generate =
the tree. Plus I use fold -w 71 to fold the diagram, but I guess it does =
not work for augment statement.

>=20
>  Also, please fix the example module's namespace per the end of=20
>  rfc6087bis Section 4.9.

Updated the namespace to =E2=80=9Chttp://example.com/ns/example-newco-acl=E2=
=80=9D

Cheers.

>=20
>=20
>=20
> Thanks,
> Kent
>=20
>=20
>=20
>=20
> _______________________________________________
> Netconf mailing list
> Netconf@ietf.org
> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_netconf&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWz=
oCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7Bx3hgofSFxvNRV7Xz=
7FuaJcKKfzEB0sBJzN_KOCtSg&s=3DXknLqgAu3Z9t1ME6FO-_mZY2oCN61867VB0ubLeiv3Q&=
e=3D
>=20
>=20
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_B437985A-7462-4213-8708-2A8397C4C07C
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Kent,

Thanks for a detailed review. See inline.

On Feb 13, 2018, at 2:30 PM, Kent Watsen <kwatsen@juniper.net>=
 wrote:

[sorry, wrong WG, moving netconf to BCC!]


ACL Authors,

Below =
are some issues I found while looking at doing the Shepherd
write-up today.  Please take a look.

Also, with regards to the request for those having Last Call =
comments
to please verify that their comments were =
addressed, I only saw one
response from Kristian, but =
should we be expecting respeonses from
others too, perhaps =
Einar or Elliot?

Eliot can confirm if he feels his issues have been =
addressed.



1=
 IDNITS

  - some issues found by =
idnits
  - using https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_tools_idnits_&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3=
voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7B=
x3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg&s=3D_5f-lxCoJW2TidcrjW_KbDkd=
PhfxLoL67kn1A2okgs0&e=3D
  - without =
selecting "verbose output"


1.1

  ** There are 5 =
instances of too long lines in the document, the longest one
     being 5 characters in excess of =
72.

Fixed.



=
  This "**" is being flagged as an "error".  
 =
 Idnits label, not mine.  Please fix.


1.2

  =3D=3D =
There are 7 instances of lines with non-RFC6890-compliant IPv4 =
addresses
     in the document. =
 If these are example addresses, they should be changed.

  This is just a warning, but given that =
there are seven occurrences, it
  might be a good =
idea to fix.  Please see Section 3, point #6 in this
 =
 document for details: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_id-2Dinfo_checklist&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeM=
K-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&=
m=3D7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg&s=3DAYo8ZHPY4SAHMqcy1q=
V9yr7BjoxGy_C9zcJ_ZbwXBT4&e=3D.

Fixed.



1.3

  ** The document seems =
to lack a both a reference to RFC 2119 and the
 =
    recommended RFC 2119 boilerplate, even if it =
appears to use RFC 2119
     keywords. =


     RFC 2119 keyword, =
line 797: '...s-list. A device MAY restrict the leng...'

  There needs to be a section that looks =
like RFC 8174, paragraph 11:

 =
    The key words "MUST", "MUST NOT", "REQUIRED", =
"SHALL", "SHALL NOT",
     "SHOULD", =
"SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
 =
    and "OPTIONAL" in this document are to be =
interpreted as
     described in BCP =
14 [RFC2119] [RFC8174] when, and only when, they
 =
    appear in all capitals, as shown here.

Added.



1.4.

  -- The document date =
(February 2, 2018) is 11 days in the past.  Is this
 =
    intentional?

 =
 This is fine, ignore it.

1.5

  ** Obsolete normative reference: RFC =
2460

  This needs to be fixed.

Updated =
the reference to RFC 8200.


1.6

  ** Downref: Normative =
reference to an Historic RFC: RFC 3540

 =
 Hmmmm, another HISTORIC document, but this time not due to an =
IESG
  action.  The question is how important =
this reference is, is this
  "ns" bit (ECN-nonce =
concealment protection) commonly used in the 
 =
 industry?   

I do not =
know enough to know it is not used. If the consensus is that we do not =
use it, I can drop it from the model.


1.7

  =3D=3D Outdated =
reference: A later version (-06) exists of
 =
    draft-ietf-netmod-yang-tree-diagrams-04

  Please update to -06

This might =
be because the draft was last published when -04 was around. I do not =
reference any particular version. My reference is to 
<?rfc =
include=3D'reference.I-D.ietf-netmod-yang-tree-diagrams=E2=80=99?>. =
The tool pulls in the latest when it generates the draft.


1.8

  -- =
Obsolete informational reference (is this intentional?): RFC 5101
     (Obsoleted by RFC 7011)

  Please update to RFC 7011

Done.




2  YANG VALIDATION

2.1 Normative Modules

  All =
of the following passed:

 =
   pyang --ietf ietf-access-control-list\@2018-02-02.yang =

    pyang --ietf =
ietf-packet-fields\@2018-02-02.yang 
 =
   pyang --ietf ietf-ethertypes\@2018-02-02.yang

    yanglint -s =
ietf-access-control-list\@2018-02-02.yang 
 =
   yanglint -s ietf-packet-fields\@2018-02-02.yang 
    yanglint -s =
ietf-ethertypes\@2018-02-02.yang 

2.2 =
Example Module

  Example module passed =
`yanglint -s`, but not `pyang --lint`:

 =
   yanglint -s example-newco-acl.yang
 =
   pyang --lint example-newco-acl.yang 

    example-newco-acl.yang:78: error: keyword =
"description" not in
    canonical order, =
expected "type", (See RFC 6020, Section 12)

 =
   example-newco-acl.yang:79: error: keyword "type" not =
in 
    canonical order, (See RFC 6020, =
Section 12)

 =
   example-newco-acl.yang:82: error: keyword "default" =
not in 
    canonical order, (See RFC 6020, =
Section 12)

  Please fix.

Fixed.



2.3 XML Examples from Section 4.3

=
  yanglint didn't find any issues:

 =
   yanglint ietf-access-control-list\@2018-02-02.yang =
ex-4.3.xml 


2.4 Examples =
from Section 4.4

  I had to stitch =
these into the 4.3 example.  It found one issue, a typo
  in the last closing tag in the first example in this =
section:

    yanglint =
ietf-access-control-list\@2018-02-02.yang ex-4.4++.xml 
 =
   err : Invalid (mixed names) opening =
(source-port-range-or-operator) and closing (tcp) element tags. =
(/data/access-lists/acl/aces/ace/matches/l4/tcp/source-port-range-or-opera=
tor/source-port-range-or-operator)

 =
 Please fix.

Made them complete examples so you do not have to =
stitch them anymore. And made sure yanglint validated the examples =
before it includes it in the draft.



  PS: And this is not a shepherd =
directive, but I found the whole 
 =
     "source-port-range-or-operator" syntax =
clumsy.  I'm surprised
 =
     it didn't look something like:

 =
         OLD
 =
            &n=
bsp;  <source-port-range-or-operator>
 =
            &n=
bsp;     <port-range-or-operator>
 =
            &n=
bsp;       <range>
=
 =
            &n=
bsp;         <lower-port&g=
t;16384</lower-port>
 =
            &n=
bsp;         <upper-port&g=
t;65535</upper-port>
 =
            &n=
bsp;       </range>
 =
            &n=
bsp;     </port-range-or-operator>
 =
            &n=
bsp;  </source-port-range-or-operator>

 =
            &n=
bsp;  <source-port-range-or-operator>
 =
            &n=
bsp;    <port-range-or-operator>
 =
            &n=
bsp;      <operator>
 =
            &n=
bsp;        <operator>eq<=
/operator>
 =
            &n=
bsp;        <port>21</por=
t>
 =
            &n=
bsp;      </operator>
 =
            &n=
bsp;    </port-range-or-operator>
=
 =
            &n=
bsp;  </source-port-range-or-operator>

          NEW

 =
            &n=
bsp;  <source-port>
 =
            &n=
bsp;    <range>
 =
            &n=
bsp;      <lower>16384</lower> =
            &n=
bsp;      <upper>65535</upper> =
            &n=
bsp;    </range>
 =
            &n=
bsp;  </source-port>

 =
            &n=
bsp;  <source-port>
 =
            &n=
bsp;    <operator>
 =
            &n=
bsp;      <operator>eq</operator>=
;
 =
            &n=
bsp;      <port>21</port>
 =
            &n=
bsp;    </operator>
 =
            &n=
bsp;  </source-port>


Did you =
try making the change in the model to see if it work? It will complain =
that <range> is already used within the container and that it =
cannot be repeated (for destination-port).



3 Key Draft Sections


3.1 Abstract

  First, I'm unsure if that first "sentence" is properly =
worded, but I
  definitely think that it is a bit too =
much on the terse side.  Can you
  embellish it =
a little?

How about this:

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

  This document describes a data model =
for Access Control List (ACL).  
  ACL is a =
ordered-by-user set of rules, used to configure the =
forwarding 
  behavior in device.  Each rule is =
used to find a match on a packet, 
  and define =
actions that will be performed on the packet.


  Second, am I reading it correct? - is =
the "Editorial Note" in the
  Abstract section. =
 I strongly advise moving 

Moved it =
to Introduction section.


3.2 RFC Editor Note

  There =
is no request to replace "I-D.ietf-netmod-yang-tree-diagrams" with
  the final RFC assignment.

Added.


  You =
might want to add what the current date value used in the draft is
  (i.e., 2018-02-02).   PS: my draft build =
tools, which I think you're
  using, should set the =
value for you automatically if you put YYYY-MM-DD
 =
 into the text.

Added text to replace the revision date in the model =
with the date the draft gets published.


3.3 Import statements missing references

  All import statements in all modules =
are missing reference statements
 =
    - why wasn't this caught by the tools?!

  Please see rfc6087bis Section 4.7. =
 

Adding reference implies import by revision, which we =
want to avoid, specially since we do not want to import by revision. =
Right?



3.4 Security =
Considerations

  Please reformat the =
last paragraph so the "aces" path is more pronounced.
 =
 Perhaps use hangText.

What is =
hangText? I italicized it.



3.5 IANA Considerations

  This section is hard to read.

  Consideration breaking up the "XML" and the "YANG =
Module Names" registry
  requests into two =
subsections.

  Consider making the =
registration entry requests themselves artwork so
 =
 they're line-spaced and indented as such.

  The first paragraph of the "XML" registry request says =
"a URI", but it 
  should be "two URIs"

  The first paragraph of the "YANG Module =
Names" registry request says 
  "a YANG module", but =
it should be "two YANG modules=E2=80=9D

Split into two sections and upped the count of URIs and =
YANG models to three (was missing the ietf-ethertypes =
module).



3.6 References

  I haven't =
checked yet, but please verify that all the references are
 =
 properly sorted as to being Normative or Informative.


3.7 Appendix A

  It took me awhile to figure out what I was looking at. =
 The tree-diagram
  is poorly indented and there =
is no text preceding the example module. 

I have =
moved the example module after the first paragraph, that describes the =
module. Let me know if that looks ok.


 =
 I recommend you fold the lines of your tree diagram at a certain =
column
  whilst adding a '\' character.  I've =
since added this ability to my draft
  build tools, =
let me know if interested in an update.  You might also want
  to look at =
draft-wu-netmod-yang-xml-doc-conventions.

Shortened =
the prefix so the augment statement fits within 72 =
columns. 

BTW, I use 'pyang =
 -f tree =E2=80=94tree-line-length=3D69' to generate the tree. Plus =
I use fold -w 71 to fold the diagram, but I guess it does not work for =
augment statement.


  Also, =
please fix the example module's namespace per the end of 
 =
 rfc6087bis Section 4.9.

Updated =
the namespace to =E2=80=9Chttp://example.com/ns/example-newco-acl=E2=80=9D
=

Cheers.




Thanks,
Kent




_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman_listinfo_netconf&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0U=
jBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=
&m=3D7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg&s=3DXknLqgAu3Z9t1=
ME6FO-_mZY2oCN61867VB0ubLeiv3Q&e=3D


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



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_B437985A-7462-4213-8708-2A8397C4C07C--


From nobody Sun Feb 18 06:31:03 2018
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 736DF124BE8; Sun, 18 Feb 2018 06:30:57 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Yaron Sheffer 
To: 
Cc: draft-ietf-netmod-syslog-model.all@ietf.org, ietf@ietf.org, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151896425742.27914.9664814474838013064@ietfa.amsl.com>
Date: Sun, 18 Feb 2018 06:30:57 -0800
Archived-At: 
Subject: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 18 Feb 2018 14:30:57 -0000

Reviewer: Yaron Sheffer
Review result: Has Issues

General Comments

* The semantics of pattern matching is not clear: "and/or the message text" -
are there cases where you only match the text but not the facility/severity? *
It's very confusing to specify rollover in minutes, but retention in hours.
People are bound to get this one wrong. * Interface selection: the feature
makes sense, but I think the description is incorrect. "This leaf sets the
source interface to be used to send messages to the remote syslog server. If
not set, messages sent to a remote syslog server will contain the IP address of
the interface the syslog message uses to exit the network element". AFAIK the
source IP will always correspond to the interface, but this feature allows you
to select a particular one. * Usage examples: the second example lists a
specific IPv6 address, but the Yang snippet shows a domain name. * A generic
question (I am new to the Yang ecosystem): I understand most implementers will
use this module from
https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-syslog.yang
- is this the expectation? If so, why not add a link from the RFC into the
repo, to make it easier for people to find?

Security Comments

* I think almost all writable data nodes here are sensitive, because a network
attacker's first move is to block any logging on the host, and many of the data
nodes here can be used for this purpose. * Re: readable data nodes, I'm not
sure which are sensitive, and the document should give an example or two rather
than just say "some". Otherwise the security advice is not actionable. One
example: "remote" sections leak information about other hosts in the network. *
Write operations... can have a negative effect on network operations. - I would
add "and on network security", because logs are often used to detect security
breaches. * Also add an advice, similar to the one on "pattern match", that the
private key used for signing log messages MUST NOT be used for any other
purpose, and that the implementation of this data node must ensure this
property (I'm not sure how). The rationale: if the TLS private key is used, for
example, this could result in a signing oracle for TLS and eventually a MITM
attack.


From nobody Sun Feb 18 22:52:51 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA713127058 for ; Sun, 18 Feb 2018 22:52:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AjxT8g8dUFPo for ; Sun, 18 Feb 2018 22:52:48 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8CC23126D0C for ; Sun, 18 Feb 2018 22:52:48 -0800 (PST)
Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w1J6qlbJ071435 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Mon, 19 Feb 2018 06:52:48 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mb.local
From: joel jaeggli 
To: netmod@ietf.org
References:  <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com>
Message-ID: 
Date: Sun, 18 Feb 2018 22:52:41 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com>
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="aIty4mC7QY8Wh2QaFZfOdTW9NRCpMkmoq"
Archived-At: 
Subject: Re: [netmod] Correction, date It ends Feb 20th Re: Adoption Poll: draft-rtgyangdt-netmod-module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 06:52:50 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--aIty4mC7QY8Wh2QaFZfOdTW9NRCpMkmoq
Content-Type: multipart/mixed; boundary="DRudH9us8f6PDhRelgu9H2fRr2ZZbFfAH";
 protected-headers="v1"
From: joel jaeggli 
To: netmod@ietf.org
Message-ID: 
Subject: Re: Correction, date It ends Feb 20th Re: [netmod] Adoption Poll:
 draft-rtgyangdt-netmod-module-tags-02
References: 
 <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com>
In-Reply-To: <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com>

--DRudH9us8f6PDhRelgu9H2fRr2ZZbFfAH
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

Note that this poll ends in a couple days.

thanks
joel

On 2/6/18 15:57, joel jaeggli wrote:
> Sorry, Feb 20th is the end date for the adoption call.
>=20
> regards
>=20
> joel
>=20
>=20
> On 2/6/18 3:47 PM, joel jaeggli wrote:
>>
>> Hi,
>>
>> This is the start of a *two* week poll on making
>> draft-rtgyangdt-netmod-module-tags-02 a working group document.=C2=A0=C2=
=A0
>>
>> https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02
>>
>> This document was most recently discussed at IETF 100.
>>
>> Please send email to the list indicating "yes/support" or "no/do not
>> support".=C2=A0 If indicating no, please state your reservations with =
the
>> document.=C2=A0 If yes, please also feel free to provide comments you'=
d
>> like to see addressed once the document is a WG document.
>>
>> This poll ends on February 8.
>>
>> Thank you!
>>
>> Joel Jaeggli and IETF NETMOD Co-Chairs
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>=20



--DRudH9us8f6PDhRelgu9H2fRr2ZZbFfAH--

--aIty4mC7QY8Wh2QaFZfOdTW9NRCpMkmoq
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCWop0OgAKCRDwADWrtn9W
sqmeAJ91jIctotQ/TP5+/WObOWjcHaZ6qQCeJtJkEa3osOHl6kDvUStg6UR1Gmc=
=6GJr
-----END PGP SIGNATURE-----

--aIty4mC7QY8Wh2QaFZfOdTW9NRCpMkmoq--


From nobody Mon Feb 19 00:22:59 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 077B9127058; Mon, 19 Feb 2018 00:22:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 52ctkrXBXgXc; Mon, 19 Feb 2018 00:22:54 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 99F751201FA; Mon, 19 Feb 2018 00:22:53 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=55153; q=dns/txt; s=iport; t=1519028573; x=1520238173; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=MEBTWAELPYsYnxZk6aqi8+F9cGtzxK5XDj6wHkqg9hE=; b=XdRWy2xiCTDBZyA/UtUQo3PT/uffyjoG7J/YTrD7SqhhGDkerAjk0/cC Ud8jTMtnbbu19WmJ8wTqbpfi3/3au5XkqmMPB9/rulqX13DVUn7O1doVZ YGyprf/TH9ZMlSCZN33OdUDDbhVysSqqdZ0qVr2LpydIYKJ6cZoAO5z/k A=;
X-Files: signature.asc : 488
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B6AQDFiIpa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ1cCiDZ4sZjxGBF4d/jkqCEwMHAxgBCYRKTwIagwoXAQIBAQE?= =?us-ascii?q?BAQECayiFJAEBBAEBGAlLCxAJAg4KIAEGAwICAh8GHxEGAQwGAgEBigYDFRCMc?= =?us-ascii?q?J10gicmhFuCMw2BMoITAQEBAQEBAQEBAQEBAQEBAQEBAQEBDg+FC4VmASmDBYJ?= =?us-ascii?q?sRAEBAhmBbYMAgmUFmiyJVDUJhGyCMoEGhAiEU4ULgiBnhUODciaHZYsWgnBIi?= =?us-ascii?q?VGBPCEDNIFRMxoIGxU6gkMJgkscggdANwEBjAUsgh8BAQE?=
X-IronPort-AV: E=Sophos;i="5.46,534,1511827200";  d="asc'?scan'208,217";a="2157285"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2018 08:22:51 +0000
Received: from [10.61.241.21] ([10.61.241.21]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1J8Mofd007206; Mon, 19 Feb 2018 08:22:50 GMT
To: Mahesh Jethanandani , Kent Watsen 
Cc: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" 
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net> <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com>
From: Eliot Lear 
Message-ID: <80db8f1c-519d-d0f4-515e-e9e89f049e16@cisco.com>
Date: Mon, 19 Feb 2018 09:22:49 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="uqctt9kFWw0UGEpCdVMQApb6p0MQxlaRC"
Archived-At: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 08:22:58 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--uqctt9kFWw0UGEpCdVMQApb6p0MQxlaRC
Content-Type: multipart/mixed; boundary="bV67nLr2siJurxfi4NCurHhGQdtUODQne";
 protected-headers="v1"
From: Eliot Lear 
To: Mahesh Jethanandani ,
 Kent Watsen 
Cc: "draft-ietf-netmod-acl-model@ietf.org"
 , "netmod@ietf.org" 
Message-ID: <80db8f1c-519d-d0f4-515e-e9e89f049e16@cisco.com>
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net>
 <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com>
In-Reply-To: <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com>

--bV67nLr2siJurxfi4NCurHhGQdtUODQne
Content-Type: multipart/alternative;
 boundary="------------A4D51EC0B70C15013EF6F52D"
Content-Language: en-US

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

CgpPbiAxOC4wMi4xOCAwMjoyNiwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZToKPiBLZW50
LAo+Cj4gVGhhbmtzIGZvciBhIGRldGFpbGVkIHJldmlldy4gU2VlIGlubGluZS4KPgo+PiBP
biBGZWIgMTMsIDIwMTgsIGF0IDI6MzAgUE0sIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlw
ZXIubmV0Cj4+IDxtYWlsdG86a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOgo+Pgo+PiBb
c29ycnksIHdyb25nIFdHLCBtb3ZpbmcgbmV0Y29uZiB0byBCQ0MhXQo+Pgo+Pgo+PiBBQ0wg
QXV0aG9ycywKPj4KPj4gQmVsb3cgYXJlIHNvbWUgaXNzdWVzIEkgZm91bmQgd2hpbGUgbG9v
a2luZyBhdCBkb2luZyB0aGUgU2hlcGhlcmQKPj4gd3JpdGUtdXAgdG9kYXkuIMKgUGxlYXNl
IHRha2UgYSBsb29rLgo+Pgo+PiBBbHNvLCB3aXRoIHJlZ2FyZHMgdG8gdGhlIHJlcXVlc3Qg
Zm9yIHRob3NlIGhhdmluZyBMYXN0IENhbGwgY29tbWVudHMKPj4gdG8gcGxlYXNlIHZlcmlm
eSB0aGF0IHRoZWlyIGNvbW1lbnRzIHdlcmUgYWRkcmVzc2VkLCBJIG9ubHkgc2F3IG9uZQo+
PiByZXNwb25zZSBmcm9tIEtyaXN0aWFuLCBidXQgc2hvdWxkIHdlIGJlIGV4cGVjdGluZyBy
ZXNwZW9uc2VzIGZyb20KPj4gb3RoZXJzIHRvbywgcGVyaGFwcyBFaW5hciBvciBFbGxpb3Q/
Cj4KPiBFbGlvdCBjYW4gY29uZmlybSBpZiBoZSBmZWVscyBoaXMgaXNzdWVzIGhhdmUgYmVl
biBhZGRyZXNzZWQuCgpZZXMsIEkgZG8uwqAgVGhlIGNoYW5nZXMgYmVsb3cgYXJlIGVxdWFs
bHkgYWNjZXB0YWJsZS4KClRoYW5rcywKCkVsaW90Cgo+Cj4+Cj4+Cj4+IDEgSUROSVRTCj4+
Cj4+IMKgLSBzb21lIGlzc3VlcyBmb3VuZCBieSBpZG5pdHMKPj4gwqAtIHVzaW5nCj4+IGh0
dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3
LmlldGYub3JnX3Rvb2xzX2lkbml0c18mZD1Ed0lDQWcmYz1IQWtZdWg2M3JzdWhyNlNjYmZo
MFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdz
QllhR1R2aklTbGFKZGNabyZtPTdCeDNoZ29mU0Z4dk5SVjdYejdGdWFKY0tLZnpFQjBzQkp6
Tl9LT0N0U2cmcz1fNWYtbHhDb0pXMlRpZGNyaldfS2JEa2RQaGZ4TG9MNjdrbjFBMm9rZ3Mw
JmU9Cj4+IMKgLSB3aXRob3V0IHNlbGVjdGluZyAidmVyYm9zZSBvdXRwdXQiCj4+Cj4+Cj4+
IDEuMQo+Pgo+PiDCoCoqIFRoZXJlIGFyZSA1IGluc3RhbmNlcyBvZiB0b28gbG9uZyBsaW5l
cyBpbiB0aGUgZG9jdW1lbnQsIHRoZQo+PiBsb25nZXN0IG9uZQo+PiDCoMKgwqDCoGJlaW5n
IDUgY2hhcmFjdGVycyBpbiBleGNlc3Mgb2YgNzIuCj4KPiBGaXhlZC4KPgo+Pgo+Pgo+PiDC
oFRoaXMgIioqIiBpcyBiZWluZyBmbGFnZ2VkIGFzIGFuICJlcnJvciIuIMKgCj4+IMKgSWRu
aXRzIGxhYmVsLCBub3QgbWluZS4gwqBQbGVhc2UgZml4Lgo+Pgo+Pgo+PiAxLjIKPj4KPj4g
wqA9PSBUaGVyZSBhcmUgNyBpbnN0YW5jZXMgb2YgbGluZXMgd2l0aCBub24tUkZDNjg5MC1j
b21wbGlhbnQgSVB2NAo+PiBhZGRyZXNzZXMKPj4gwqDCoMKgwqBpbiB0aGUgZG9jdW1lbnQu
IMKgSWYgdGhlc2UgYXJlIGV4YW1wbGUgYWRkcmVzc2VzLCB0aGV5IHNob3VsZCBiZQo+PiBj
aGFuZ2VkLgo+Pgo+PiDCoFRoaXMgaXMganVzdCBhIHdhcm5pbmcsIGJ1dCBnaXZlbiB0aGF0
IHRoZXJlIGFyZSBzZXZlbiBvY2N1cnJlbmNlcywgaXQKPj4gwqBtaWdodCBiZSBhIGdvb2Qg
aWRlYSB0byBmaXguIMKgUGxlYXNlIHNlZSBTZWN0aW9uIDMsIHBvaW50ICM2IGluIHRoaXMK
Pj4gwqBkb2N1bWVudCBmb3IgZGV0YWlsczoKPj4gaHR0cHM6Ly91cmxkZWZlbnNlLnByb29m
cG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaWQtMkRpbmZvX2No
ZWNrbGlzdCZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9E
VFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pv
Jm09N0J4M2hnb2ZTRnh2TlJWN1h6N0Z1YUpjS0tmekVCMHNCSnpOX0tPQ3RTZyZzPUFZbzha
SFBZNFNBSE1xY3kxcVY5eXI3QmpveEd5X0M5emNKX1pid1hCVDQmZT0uCj4KPiBGaXhlZC4K
Pgo+Pgo+Pgo+PiAxLjMKPj4KPj4gwqAqKiBUaGUgZG9jdW1lbnQgc2VlbXMgdG8gbGFjayBh
IGJvdGggYSByZWZlcmVuY2UgdG8gUkZDIDIxMTkgYW5kIHRoZQo+PiDCoMKgwqDCoHJlY29t
bWVuZGVkIFJGQyAyMTE5IGJvaWxlcnBsYXRlLCBldmVuIGlmIGl0IGFwcGVhcnMgdG8gdXNl
IFJGQyAyMTE5Cj4+IMKgwqDCoMKga2V5d29yZHMuCj4+Cj4+IMKgwqDCoMKgUkZDIDIxMTkg
a2V5d29yZCwgbGluZSA3OTc6ICcuLi5zLWxpc3QuIEEgZGV2aWNlIE1BWSByZXN0cmljdCB0
aGUKPj4gbGVuZy4uLicKPj4KPj4KPj4gwqBUaGVyZSBuZWVkcyB0byBiZSBhIHNlY3Rpb24g
dGhhdCBsb29rcyBsaWtlIFJGQyA4MTc0LCBwYXJhZ3JhcGggMTE6Cj4+Cj4+IMKgwqDCoMKg
VGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIsICJSRVFVSVJFRCIsICJTSEFMTCIs
ICJTSEFMTCBOT1QiLAo+PiDCoMKgwqDCoCJTSE9VTEQiLCAiU0hPVUxEIE5PVCIsICJSRUNP
TU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwKPj4gwqDCoMKgwqBhbmQgIk9Q
VElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcwo+PiDC
oMKgwqDCoGRlc2NyaWJlZCBpbiBCQ1AgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBh
bmQgb25seSB3aGVuLCB0aGV5Cj4+IMKgwqDCoMKgYXBwZWFyIGluIGFsbCBjYXBpdGFscywg
YXMgc2hvd24gaGVyZS4KPgo+IEFkZGVkLgo+Cj4+Cj4+Cj4+IDEuNC4KPj4KPj4gwqAtLSBU
aGUgZG9jdW1lbnQgZGF0ZSAoRmVicnVhcnkgMiwgMjAxOCkgaXMgMTEgZGF5cyBpbiB0aGUg
cGFzdC4gwqBJcyB0aGlzCj4+IMKgwqDCoMKgaW50ZW50aW9uYWw/Cj4+Cj4+IMKgVGhpcyBp
cyBmaW5lLCBpZ25vcmUgaXQuCj4+Cj4+IDEuNQo+Pgo+PiDCoCoqIE9ic29sZXRlIG5vcm1h
dGl2ZSByZWZlcmVuY2U6IFJGQyAyNDYwCj4+Cj4+IMKgVGhpcyBuZWVkcyB0byBiZSBmaXhl
ZC4KPgo+IFVwZGF0ZWQgdGhlIHJlZmVyZW5jZSB0byBSRkMgODIwMC4KPgo+Pgo+PiAxLjYK
Pj4KPj4gwqAqKiBEb3ducmVmOiBOb3JtYXRpdmUgcmVmZXJlbmNlIHRvIGFuIEhpc3Rvcmlj
IFJGQzogUkZDIDM1NDAKPj4KPj4gwqBIbW1tbSwgYW5vdGhlciBISVNUT1JJQyBkb2N1bWVu
dCwgYnV0IHRoaXMgdGltZSBub3QgZHVlIHRvIGFuIElFU0cKPj4gwqBhY3Rpb24uIMKgVGhl
IHF1ZXN0aW9uIGlzIGhvdyBpbXBvcnRhbnQgdGhpcyByZWZlcmVuY2UgaXMsIGlzIHRoaXMK
Pj4gwqAibnMiIGJpdCAoRUNOLW5vbmNlIGNvbmNlYWxtZW50IHByb3RlY3Rpb24pIGNvbW1v
bmx5IHVzZWQgaW4gdGhlCj4+IMKgaW5kdXN0cnk/IMKgwqAKPgo+IEkgZG8gbm90IGtub3cg
ZW5vdWdoIHRvIGtub3cgaXQgaXMgbm90IHVzZWQuIElmIHRoZSBjb25zZW5zdXMgaXMgdGhh
dAo+IHdlIGRvIG5vdCB1c2UgaXQsIEkgY2FuIGRyb3AgaXQgZnJvbSB0aGUgbW9kZWwuCj4K
Pj4KPj4gMS43Cj4+Cj4+IMKgPT0gT3V0ZGF0ZWQgcmVmZXJlbmNlOiBBIGxhdGVyIHZlcnNp
b24gKC0wNikgZXhpc3RzIG9mCj4+IMKgwqDCoMKgZHJhZnQtaWV0Zi1uZXRtb2QteWFuZy10
cmVlLWRpYWdyYW1zLTA0Cj4+Cj4+IMKgUGxlYXNlIHVwZGF0ZSB0byAtMDYKPgo+IFRoaXMg
bWlnaHQgYmUgYmVjYXVzZSB0aGUgZHJhZnQgd2FzIGxhc3QgcHVibGlzaGVkIHdoZW4gLTA0
IHdhcwo+IGFyb3VuZC4gSSBkbyBub3QgcmVmZXJlbmNlIGFueSBwYXJ0aWN1bGFyIHZlcnNp
b24uIE15IHJlZmVyZW5jZSBpcyB0b8KgCj4gPD9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLkkt
RC5pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXPigJk/Pi4gVGhlCj4gdG9vbCBwdWxs
cyBpbiB0aGUgbGF0ZXN0IHdoZW4gaXQgZ2VuZXJhdGVzIHRoZSBkcmFmdC4KPgo+Pgo+PiAx
LjgKPj4KPj4gwqAtLSBPYnNvbGV0ZSBpbmZvcm1hdGlvbmFsIHJlZmVyZW5jZSAoaXMgdGhp
cyBpbnRlbnRpb25hbD8pOiBSRkMgNTEwMQo+PiDCoMKgwqDCoChPYnNvbGV0ZWQgYnkgUkZD
IDcwMTEpCj4+Cj4+IMKgUGxlYXNlIHVwZGF0ZSB0byBSRkMgNzAxMQo+Cj4gRG9uZS4KPgo+
Pgo+Pgo+Pgo+PiAyIMKgWUFORyBWQUxJREFUSU9OCj4+Cj4+IDIuMSBOb3JtYXRpdmUgTW9k
dWxlcwo+Pgo+PiDCoEFsbCBvZiB0aGUgZm9sbG93aW5nIHBhc3NlZDoKPj4KPj4gwqDCoMKg
cHlhbmcgLS1pZXRmIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdFxAMjAxOC0wMi0wMi55YW5n
Cj4+IMKgwqDCoHB5YW5nIC0taWV0ZiBpZXRmLXBhY2tldC1maWVsZHNcQDIwMTgtMDItMDIu
eWFuZwo+PiDCoMKgwqBweWFuZyAtLWlldGYgaWV0Zi1ldGhlcnR5cGVzXEAyMDE4LTAyLTAy
LnlhbmcKPj4KPj4gwqDCoMKgeWFuZ2xpbnQgLXMgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0
XEAyMDE4LTAyLTAyLnlhbmcKPj4gwqDCoMKgeWFuZ2xpbnQgLXMgaWV0Zi1wYWNrZXQtZmll
bGRzXEAyMDE4LTAyLTAyLnlhbmcKPj4gwqDCoMKgeWFuZ2xpbnQgLXMgaWV0Zi1ldGhlcnR5
cGVzXEAyMDE4LTAyLTAyLnlhbmcKPj4KPj4gMi4yIEV4YW1wbGUgTW9kdWxlCj4+Cj4+IMKg
RXhhbXBsZSBtb2R1bGUgcGFzc2VkIGB5YW5nbGludCAtc2AsIGJ1dCBub3QgYHB5YW5nIC0t
bGludGA6Cj4+Cj4+IMKgwqDCoHlhbmdsaW50IC1zIGV4YW1wbGUtbmV3Y28tYWNsLnlhbmcK
Pj4gwqDCoMKgcHlhbmcgLS1saW50IGV4YW1wbGUtbmV3Y28tYWNsLnlhbmcKPj4KPj4gwqDC
oMKgZXhhbXBsZS1uZXdjby1hY2wueWFuZzo3ODogZXJyb3I6IGtleXdvcmQgImRlc2NyaXB0
aW9uIiBub3QgaW4KPj4gwqDCoMKgY2Fub25pY2FsIG9yZGVyLCBleHBlY3RlZCAidHlwZSIs
IChTZWUgUkZDIDYwMjAsIFNlY3Rpb24gMTIpCj4+Cj4+IMKgwqDCoGV4YW1wbGUtbmV3Y28t
YWNsLnlhbmc6Nzk6IGVycm9yOiBrZXl3b3JkICJ0eXBlIiBub3QgaW4KPj4gwqDCoMKgY2Fu
b25pY2FsIG9yZGVyLCAoU2VlIFJGQyA2MDIwLCBTZWN0aW9uIDEyKQo+Pgo+PiDCoMKgwqBl
eGFtcGxlLW5ld2NvLWFjbC55YW5nOjgyOiBlcnJvcjoga2V5d29yZCAiZGVmYXVsdCIgbm90
IGluCj4+IMKgwqDCoGNhbm9uaWNhbCBvcmRlciwgKFNlZSBSRkMgNjAyMCwgU2VjdGlvbiAx
MikKPj4KPj4gwqBQbGVhc2UgZml4Lgo+Cj4gRml4ZWQuCj4KPj4KPj4KPj4gMi4zIFhNTCBF
eGFtcGxlcyBmcm9tIFNlY3Rpb24gNC4zCj4+Cj4+IMKgeWFuZ2xpbnQgZGlkbid0IGZpbmQg
YW55IGlzc3VlczoKPj4KPj4gwqDCoMKgeWFuZ2xpbnQgaWV0Zi1hY2Nlc3MtY29udHJvbC1s
aXN0XEAyMDE4LTAyLTAyLnlhbmcgZXgtNC4zLnhtbAo+Pgo+Pgo+PiAyLjQgRXhhbXBsZXMg
ZnJvbSBTZWN0aW9uIDQuNAo+Pgo+PiDCoEkgaGFkIHRvIHN0aXRjaCB0aGVzZSBpbnRvIHRo
ZSA0LjMgZXhhbXBsZS4gwqBJdCBmb3VuZCBvbmUgaXNzdWUsIGEgdHlwbwo+PiDCoGluIHRo
ZSBsYXN0IGNsb3NpbmcgdGFnIGluIHRoZSBmaXJzdCBleGFtcGxlIGluIHRoaXMgc2VjdGlv
bjoKPj4KPj4gwqDCoMKgeWFuZ2xpbnQgaWV0Zi1hY2Nlc3MtY29udHJvbC1saXN0XEAyMDE4
LTAyLTAyLnlhbmcgZXgtNC40KysueG1sCj4+IMKgwqDCoGVyciA6IEludmFsaWQgKG1peGVk
IG5hbWVzKSBvcGVuaW5nCj4+IChzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcikgYW5k
IGNsb3NpbmcgKHRjcCkgZWxlbWVudCB0YWdzLgo+PiAoL2RhdGEvYWNjZXNzLWxpc3RzL2Fj
bC9hY2VzL2FjZS9tYXRjaGVzL2w0L3RjcC9zb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRv
ci9zb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcikKPj4KPj4gwqBQbGVhc2UgZml4Lgo+
Cj4gTWFkZSB0aGVtIGNvbXBsZXRlIGV4YW1wbGVzIHNvIHlvdSBkbyBub3QgaGF2ZSB0byBz
dGl0Y2ggdGhlbSBhbnltb3JlLgo+IEFuZCBtYWRlIHN1cmUgeWFuZ2xpbnQgdmFsaWRhdGVk
IHRoZSBleGFtcGxlcyBiZWZvcmUgaXQgaW5jbHVkZXMgaXQgaW4KPiB0aGUgZHJhZnQuCj4K
Pj4KPj4KPj4gwqBQUzogQW5kIHRoaXMgaXMgbm90IGEgc2hlcGhlcmQgZGlyZWN0aXZlLCBi
dXQgSSBmb3VuZCB0aGUgd2hvbGUKPj4gwqDCoMKgwqDCoCJzb3VyY2UtcG9ydC1yYW5nZS1v
ci1vcGVyYXRvciIgc3ludGF4IGNsdW1zeS4gwqBJJ20gc3VycHJpc2VkCj4+IMKgwqDCoMKg
wqBpdCBkaWRuJ3QgbG9vayBzb21ldGhpbmcgbGlrZToKPj4KPj4gwqDCoMKgwqDCoMKgwqDC
oMKgT0xECj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxzb3VyY2UtcG9ydC1y
YW5nZS1vci1vcGVyYXRvcj4KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgPHBvcnQtcmFuZ2Utb3Itb3BlcmF0b3I+Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqA8cmFuZ2U+Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgPGxvd2VyLXBvcnQ+MTYzODQ8L2xvd2VyLXBvcnQ+Cj4+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHVwcGVyLXBvcnQ+
NjU1MzU8L3VwcGVyLXBvcnQ+Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqA8L3JhbmdlPgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqA8L3BvcnQtcmFuZ2Utb3Itb3BlcmF0b3I+Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoDwvc291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3I+Cj4+Cj4+IMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcj4K
Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxwb3J0LXJhbmdlLW9yLW9w
ZXJhdG9yPgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxvcGVy
YXRvcj4KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPG9w
ZXJhdG9yPmVxPC9vcGVyYXRvcj4KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgPHBvcnQ+MjE8L3BvcnQ+Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgPC9vcGVyYXRvcj4KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoDwvcG9ydC1yYW5nZS1vci1vcGVyYXRvcj4KPj4gwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgPC9zb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcj4KPj4KPj4g
wqDCoMKgwqDCoMKgwqDCoMKgTkVXCj4+Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoDxzb3VyY2UtcG9ydD4KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oDxyYW5nZT4KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8bG93
ZXI+MTYzODQ8L2xvd2VyPgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoDx1cHBlcj42NTUzNTwvdXBwZXI+Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqA8L3JhbmdlPgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L3Nv
dXJjZS1wb3J0Pgo+Pgo+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8c291cmNl
LXBvcnQ+Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8b3BlcmF0b3I+
Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPG9wZXJhdG9yPmVx
PC9vcGVyYXRvcj4KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8
cG9ydD4yMTwvcG9ydD4KPj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwv
b3BlcmF0b3I+Cj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwvc291cmNlLXBv
cnQ+Cj4+Cj4KPiBEaWQgeW91IHRyeSBtYWtpbmcgdGhlIGNoYW5nZSBpbiB0aGUgbW9kZWwg
dG8gc2VlIGlmIGl0IHdvcms/IEl0IHdpbGwKPiBjb21wbGFpbiB0aGF0IDxyYW5nZT4gaXMg
YWxyZWFkeSB1c2VkIHdpdGhpbiB0aGUgY29udGFpbmVyIGFuZCB0aGF0IGl0Cj4gY2Fubm90
IGJlIHJlcGVhdGVkIChmb3IgZGVzdGluYXRpb24tcG9ydCkuCj4KPj4KPj4KPj4gMyBLZXkg
RHJhZnQgU2VjdGlvbnMKPj4KPj4KPj4gMy4xIEFic3RyYWN0Cj4+Cj4+IMKgRmlyc3QsIEkn
bSB1bnN1cmUgaWYgdGhhdCBmaXJzdCAic2VudGVuY2UiIGlzIHByb3Blcmx5IHdvcmRlZCwg
YnV0IEkKPj4gwqBkZWZpbml0ZWx5IHRoaW5rIHRoYXQgaXQgaXMgYSBiaXQgdG9vIG11Y2gg
b24gdGhlIHRlcnNlIHNpZGUuIMKgQ2FuIHlvdQo+PiDCoGVtYmVsbGlzaCBpdCBhIGxpdHRs
ZT8KPgo+IEhvdyBhYm91dCB0aGlzOgo+Cj4gT0xEOgo+IFRoaXMgZG9jdW1lbnQgZGVzY3Jp
YmVzIGEgZGF0YSBtb2RlbCBvZiBBY2Nlc3MgQ29udHJvbCBMaXN0IChBQ0wpCj4gYmFzaWMg
YnVpbGRpbmcgYmxvY2tzLgo+IE5FVzoKPgo+IMKgIFRoaXMgZG9jdW1lbnQgZGVzY3JpYmVz
IGEgZGF0YSBtb2RlbCBmb3IgQWNjZXNzIENvbnRyb2wgTGlzdCAoQUNMKS4gwqAKPiDCoCBB
Q0wgaXMgYSBvcmRlcmVkLWJ5LXVzZXIgc2V0IG9mIHJ1bGVzLCB1c2VkIHRvIGNvbmZpZ3Vy
ZSB0aGUgZm9yd2FyZGluZ8KgCj4gwqAgYmVoYXZpb3IgaW4gZGV2aWNlLiDCoEVhY2ggcnVs
ZSBpcyB1c2VkIHRvIGZpbmQgYSBtYXRjaCBvbiBhIHBhY2tldCzCoAo+IMKgIGFuZCBkZWZp
bmUgYWN0aW9ucyB0aGF0IHdpbGwgYmUgcGVyZm9ybWVkIG9uIHRoZSBwYWNrZXQuCj4KPj4K
Pj4gwqBTZWNvbmQsIGFtIEkgcmVhZGluZyBpdCBjb3JyZWN0PyAtIGlzIHRoZSAiRWRpdG9y
aWFsIE5vdGUiIGluIHRoZQo+PiDCoEFic3RyYWN0IHNlY3Rpb24uIMKgSSBzdHJvbmdseSBh
ZHZpc2UgbW92aW5nCj4KPiBNb3ZlZCBpdCB0byBJbnRyb2R1Y3Rpb24gc2VjdGlvbi4KPgo+
Pgo+PiAzLjIgUkZDIEVkaXRvciBOb3RlCj4+Cj4+IMKgVGhlcmUgaXMgbm8gcmVxdWVzdCB0
byByZXBsYWNlICJJLUQuaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRpYWdyYW1zIiB3aXRoCj4+
IMKgdGhlIGZpbmFsIFJGQyBhc3NpZ25tZW50Lgo+Cj4gQWRkZWQuCj4KPj4KPj4gwqBZb3Ug
bWlnaHQgd2FudCB0byBhZGQgd2hhdCB0aGUgY3VycmVudCBkYXRlIHZhbHVlIHVzZWQgaW4g
dGhlIGRyYWZ0IGlzCj4+IMKgKGkuZS4sIDIwMTgtMDItMDIpLiDCoMKgUFM6IG15IGRyYWZ0
IGJ1aWxkIHRvb2xzLCB3aGljaCBJIHRoaW5rIHlvdSdyZQo+PiDCoHVzaW5nLCBzaG91bGQg
c2V0IHRoZSB2YWx1ZSBmb3IgeW91IGF1dG9tYXRpY2FsbHkgaWYgeW91IHB1dCBZWVlZLU1N
LURECj4+IMKgaW50byB0aGUgdGV4dC4KPgo+IEFkZGVkIHRleHQgdG8gcmVwbGFjZSB0aGUg
cmV2aXNpb24gZGF0ZSBpbiB0aGUgbW9kZWwgd2l0aCB0aGUgZGF0ZSB0aGUKPiBkcmFmdCBn
ZXRzIHB1Ymxpc2hlZC4KPgo+Pgo+PiAzLjMgSW1wb3J0IHN0YXRlbWVudHMgbWlzc2luZyBy
ZWZlcmVuY2VzCj4+Cj4+IMKgQWxsIGltcG9ydCBzdGF0ZW1lbnRzIGluIGFsbCBtb2R1bGVz
IGFyZSBtaXNzaW5nIHJlZmVyZW5jZSBzdGF0ZW1lbnRzCj4+IMKgwqDCoMKgLSB3aHkgd2Fz
bid0IHRoaXMgY2F1Z2h0IGJ5IHRoZSB0b29scz8hCj4+Cj4+IMKgUGxlYXNlIHNlZSByZmM2
MDg3YmlzIFNlY3Rpb24gNC43LiDCoAo+Cj4gQWRkaW5nIHJlZmVyZW5jZSBpbXBsaWVzIGlt
cG9ydCBieSByZXZpc2lvbiwgd2hpY2ggd2Ugd2FudCB0byBhdm9pZCwKPiBzcGVjaWFsbHkg
c2luY2Ugd2UgZG8gbm90IHdhbnQgdG8gaW1wb3J0IGJ5IHJldmlzaW9uLiBSaWdodD8KPgo+
Pgo+Pgo+PiAzLjQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnMKPj4KPj4gwqBQbGVhc2UgcmVm
b3JtYXQgdGhlIGxhc3QgcGFyYWdyYXBoIHNvIHRoZSAiYWNlcyIgcGF0aCBpcyBtb3JlCj4+
IHByb25vdW5jZWQuCj4+IMKgUGVyaGFwcyB1c2UgaGFuZ1RleHQuCj4KPiBXaGF0IGlzIGhh
bmdUZXh0PyBJIGl0YWxpY2l6ZWQgaXQuCj4KPj4KPj4KPj4gMy41IElBTkEgQ29uc2lkZXJh
dGlvbnMKPj4KPj4gwqBUaGlzIHNlY3Rpb24gaXMgaGFyZCB0byByZWFkLgo+Pgo+PiDCoENv
bnNpZGVyYXRpb24gYnJlYWtpbmcgdXAgdGhlICJYTUwiIGFuZCB0aGUgIllBTkcgTW9kdWxl
IE5hbWVzIiByZWdpc3RyeQo+PiDCoHJlcXVlc3RzIGludG8gdHdvIHN1YnNlY3Rpb25zLgo+
Pgo+PiDCoENvbnNpZGVyIG1ha2luZyB0aGUgcmVnaXN0cmF0aW9uIGVudHJ5IHJlcXVlc3Rz
IHRoZW1zZWx2ZXMgYXJ0d29yayBzbwo+PiDCoHRoZXkncmUgbGluZS1zcGFjZWQgYW5kIGlu
ZGVudGVkIGFzIHN1Y2guCj4+Cj4+IMKgVGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgIlhN
TCIgcmVnaXN0cnkgcmVxdWVzdCBzYXlzICJhIFVSSSIsIGJ1dCBpdAo+PiDCoHNob3VsZCBi
ZSAidHdvIFVSSXMiCj4+Cj4+IMKgVGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgIllBTkcg
TW9kdWxlIE5hbWVzIiByZWdpc3RyeSByZXF1ZXN0IHNheXMKPj4gwqAiYSBZQU5HIG1vZHVs
ZSIsIGJ1dCBpdCBzaG91bGQgYmUgInR3byBZQU5HIG1vZHVsZXPigJ0KPgo+IFNwbGl0IGlu
dG8gdHdvIHNlY3Rpb25zIGFuZCB1cHBlZCB0aGUgY291bnQgb2YgVVJJcyBhbmQgWUFORyBt
b2RlbHMgdG8KPiB0aHJlZSAod2FzIG1pc3NpbmcgdGhlIGlldGYtZXRoZXJ0eXBlcyBtb2R1
bGUpLgo+Cj4+Cj4+Cj4+IDMuNiBSZWZlcmVuY2VzCj4+Cj4+IMKgSSBoYXZlbid0IGNoZWNr
ZWQgeWV0LCBidXQgcGxlYXNlIHZlcmlmeSB0aGF0IGFsbCB0aGUgcmVmZXJlbmNlcyBhcmUK
Pj4gwqBwcm9wZXJseSBzb3J0ZWQgYXMgdG8gYmVpbmcgTm9ybWF0aXZlIG9yIEluZm9ybWF0
aXZlLgo+Pgo+Pgo+PiAzLjcgQXBwZW5kaXggQQo+Pgo+PiDCoEl0IHRvb2sgbWUgYXdoaWxl
IHRvIGZpZ3VyZSBvdXQgd2hhdCBJIHdhcyBsb29raW5nIGF0LiDCoFRoZSB0cmVlLWRpYWdy
YW0KPj4gwqBpcyBwb29ybHkgaW5kZW50ZWQgYW5kIHRoZXJlIGlzIG5vIHRleHQgcHJlY2Vk
aW5nIHRoZSBleGFtcGxlIG1vZHVsZS7CoAo+Cj4gSSBoYXZlIG1vdmVkIHRoZSBleGFtcGxl
IG1vZHVsZSBhZnRlciB0aGUgZmlyc3QgcGFyYWdyYXBoLCB0aGF0Cj4gZGVzY3JpYmVzIHRo
ZSBtb2R1bGUuIExldCBtZSBrbm93IGlmIHRoYXQgbG9va3Mgb2suCj4KPj4KPj4gwqBJIHJl
Y29tbWVuZCB5b3UgZm9sZCB0aGUgbGluZXMgb2YgeW91ciB0cmVlIGRpYWdyYW0gYXQgYSBj
ZXJ0YWluIGNvbHVtbgo+PiDCoHdoaWxzdCBhZGRpbmcgYSAnXCcgY2hhcmFjdGVyLiDCoEkn
dmUgc2luY2UgYWRkZWQgdGhpcyBhYmlsaXR5IHRvIG15Cj4+IGRyYWZ0Cj4+IMKgYnVpbGQg
dG9vbHMsIGxldCBtZSBrbm93IGlmIGludGVyZXN0ZWQgaW4gYW4gdXBkYXRlLiDCoFlvdSBt
aWdodCBhbHNvCj4+IHdhbnQKPj4gwqB0byBsb29rIGF0IGRyYWZ0LXd1LW5ldG1vZC15YW5n
LXhtbC1kb2MtY29udmVudGlvbnMuCj4KPiBTaG9ydGVuZWQgdGhlIHByZWZpeCBzbyB0aGUg
YXVnbWVudCBzdGF0ZW1lbnQgZml0cyB3aXRoaW4gNzIgY29sdW1ucy7CoAo+Cj4gQlRXLCBJ
IHVzZSAncHlhbmcgwqAtZiB0cmVlIOKAlHRyZWUtbGluZS1sZW5ndGg9NjknIHRvIGdlbmVy
YXRlIHRoZSB0cmVlLgo+IFBsdXMgSSB1c2UgZm9sZCAtdyA3MSB0byBmb2xkIHRoZSBkaWFn
cmFtLCBidXQgSSBndWVzcyBpdCBkb2VzIG5vdAo+IHdvcmsgZm9yIGF1Z21lbnQgc3RhdGVt
ZW50Lgo+Cj4+Cj4+IMKgQWxzbywgcGxlYXNlIGZpeCB0aGUgZXhhbXBsZSBtb2R1bGUncyBu
YW1lc3BhY2UgcGVyIHRoZSBlbmQgb2YKPj4gwqByZmM2MDg3YmlzIFNlY3Rpb24gNC45Lgo+
Cj4gVXBkYXRlZCB0aGUgbmFtZXNwYWNlIHRvIOKAnGh0dHA6Ly9leGFtcGxlLmNvbS9ucy9l
eGFtcGxlLW5ld2NvLWFjbOKAnQo+Cj4gQ2hlZXJzLgo+Cj4+Cj4+Cj4+Cj4+IFRoYW5rcywK
Pj4gS2VudAo+Pgo+Pgo+Pgo+Pgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXwo+PiBOZXRjb25mIG1haWxpbmcgbGlzdAo+PiBOZXRjb25mQGll
dGYub3JnIDxtYWlsdG86TmV0Y29uZkBpZXRmLm9yZz4KPj4gaHR0cHM6Ly91cmxkZWZlbnNl
LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1h
bl9saXN0aW5mb19uZXRjb25mJmQ9RHdJQ0FnJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJY
ZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdU
dmpJU2xhSmRjWm8mbT03QngzaGdvZlNGeHZOUlY3WHo3RnVhSmNLS2Z6RUIwc0JKek5fS09D
dFNnJnM9WGtuTHFnQXUzWjl0MU1FNkZPLV9tWlkyb0NONjE4NjdWQjB1YkxlaXYzUSZlPQo+
Pgo+Pgo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
Xwo+PiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4+IG5ldG1vZEBpZXRmLm9yZwo+PiBodHRwczov
L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZAo+Cj4gTWFoZXNoIEpldGhh
bmFuZGFuaQo+IG1qZXRoYW5hbmRhbmlAZ21haWwuY29tIDxtYWlsdG86bWpldGhhbmFuZGFu
aUBnbWFpbC5jb20+Cj4KPgo+Cj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX18KPiBuZXRtb2QgbWFpbGluZyBsaXN0Cj4gbmV0bW9kQGlldGYub3Jn
Cj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QKCg==
--------------A4D51EC0B70C15013EF6F52D
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    


    

    

    
On 18.02.18 02:26, Mahesh Jethanandani=

      wrote:

    

    

      
      Kent,
      


      

      
Thanks for a detailed review. See inline.

        


          

            
On Feb 13, 2018, at 2:30 PM, Kent Watsen <=
kwatsen@juniper.net>
              wrote:

            

            

              
[sorry, wrong WG, moving netconf to BCC!]
                

                

                ACL Authors,

                

                Below are some issues I found while looking at doing the
                Shepherd

                write-up today. =C2=A0Please take a look.

                

                Also, with regards to the request for those having Last
                Call comments

                to please verify that their comments were addressed, I
                only saw one

                response from Kristian, but should we be expecting
                respeonses from

                others too, perhaps Einar or Elliot?

              

            

          

          


          

          Eliot can confirm if he feels his issues have been addressed.
      

    

    

    Yes, I do.=C2=A0 The changes below are equally acceptable.

    

    Thanks,

    

    Eliot

    

    

      

        


          

            

              


                

                1 IDNITS

                

                =C2=A0- some issues found by idnits

                =C2=A0- using https://urldefense.=
proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_tools_idnits_&d=3DDw=
ICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJ=
UvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7Bx3hgofSFxvNRV7Xz7FuaJcKKfzE=
B0sBJzN_KOCtSg&s=3D_5f-lxCoJW2TidcrjW_KbDkdPhfxLoL67kn1A2okgs0&e=3D=


                =C2=A0- without selecting "verbose output"
=

                

                

                1.1

                

                =C2=A0** There are 5 instances of too long lines in the
                document, the longest one

                =C2=A0=C2=A0=C2=A0=C2=A0being 5 characters in excess of 7=
2.

              

            

          

          


          

          Fixed.

        


          

            

              


                

                =C2=A0This "**" is being flagged as an "error". =C2=A0
                =C2=A0Idnits label, not mine. =C2=A0Please fix.

                

                

                1.2

                

                =C2=A0=3D=3D There are 7 instances of lines with
                non-RFC6890-compliant IPv4 addresses

                =C2=A0=C2=A0=C2=A0=C2=A0in the document. =C2=A0If these a=
re example addresses,
                they should be changed.

                

                =C2=A0This is just a warning, but given that there are se=
ven
                occurrences, it

                =C2=A0might be a good idea to fix. =C2=A0Please see Secti=
on 3,
                point #6 in this

                =C2=A0document for details: https://urldefense.=
proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_id-2Dinfo_checklist&=
d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9z=
kP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7Bx3hgofSFxvNRV7Xz7FuaJ=
cKKfzEB0sBJzN_KOCtSg&s=3DAYo8ZHPY4SAHMqcy1qV9yr7BjoxGy_C9zcJ_ZbwXBT4&=
amp;e=3D.

              

            

          

          


          

          Fixed.

        


          

            

              


                

                1.3

                

                =C2=A0** The document seems to lack a both a reference to=
 RFC
                2119 and the

                =C2=A0=C2=A0=C2=A0=C2=A0recommended RFC 2119 boilerplate,=
 even if it appears
                to use RFC 2119

                =C2=A0=C2=A0=C2=A0=C2=A0keywords. 

                

                =C2=A0=C2=A0=C2=A0=C2=A0RFC 2119 keyword, line 797: '...s=
-list. A device MAY
                restrict the leng...'

                

                

                =C2=A0There needs to be a section that looks like RFC 817=
4,
                paragraph 11:

                

                =C2=A0=C2=A0=C2=A0=C2=A0The key words "MUST", "MUST NOT",=
 "REQUIRED",
                "SHALL", "SHALL NOT",

                =C2=A0=C2=A0=C2=A0=C2=A0"SHOULD", "SHOULD NOT", "RECOMMEN=
DED", "NOT
                RECOMMENDED", "MAY",

                =C2=A0=C2=A0=C2=A0=C2=A0and "OPTIONAL" in this document a=
re to be
                interpreted as

                =C2=A0=C2=A0=C2=A0=C2=A0described in BCP 14 [RFC2119] [RF=
C8174] when, and
                only when, they

                =C2=A0=C2=A0=C2=A0=C2=A0appear in all capitals, as shown =
here.

              

            

          

          


          

          Added.

        


          

            

              


                

                1.4.

                

                =C2=A0-- The document date (February 2, 2018) is 11 days =
in
                the past. =C2=A0Is this

                =C2=A0=C2=A0=C2=A0=C2=A0intentional?

                

                =C2=A0This is fine, ignore it.

                

                1.5

                

                =C2=A0** Obsolete normative reference: RFC 2460

                

                =C2=A0This needs to be fixed.

              

            

          

          


          

          Updated the reference to RFC 8200.

        


          

            

              


                1.6

                

                =C2=A0** Downref: Normative reference to an Historic RFC:=
 RFC
                3540

                

                =C2=A0Hmmmm, another HISTORIC document, but this time not=
 due
                to an IESG

                =C2=A0action. =C2=A0The question is how important this re=
ference
                is, is this

                =C2=A0"ns" bit (ECN-nonce concealment protection) commonl=
y
                used in the 

                =C2=A0industry? =C2=A0=C2=A0

              

            

          

          


          

          I do not know enough to know it is not used. If the consensus
          is that we do not use it, I can drop it from the model.

        


          

            

              


                1.7

                

                =C2=A0=3D=3D Outdated reference: A later version (-06) ex=
ists of

                =C2=A0=C2=A0=C2=A0=C2=A0draft-ietf-netmod-yang-tree-diagr=
ams-04

                

                =C2=A0Please update to -06

              

            

          

          


          

          This might be because the draft was last published when -04
          was around. I do not reference any particular version. My
          reference is to=C2=A0
          
<?rfc
            include=3D'reference.I-D.ietf-netmod-yang-tree-diagrams=E2=80=
=99?>.
            The tool pulls in the latest when it generates the draft.
          


          

          

            

              


                1.8

                

                =C2=A0-- Obsolete informational reference (is this
                intentional?): RFC 5101

                =C2=A0=C2=A0=C2=A0=C2=A0(Obsoleted by RFC 7011)

                

                =C2=A0Please update to RFC 7011

              

            

          

          


          

          Done.

        


          

            

              


                

                

                2 =C2=A0YANG VALIDATION

                

                2.1 Normative Modules

                

                =C2=A0All of the following passed:

                

                =C2=A0=C2=A0=C2=A0pyang --ietf
                ietf-access-control-list\@2018-02-02.yang 
=

                =C2=A0=C2=A0=C2=A0pyang --ietf ietf-packet-fields\@2018-0=
2-02.yang 

                =C2=A0=C2=A0=C2=A0pyang --ietf ietf-ethertypes\@2018-02-0=
2.yang

                

                =C2=A0=C2=A0=C2=A0yanglint -s ietf-access-control-list\@2=
018-02-02.yang
                

                =C2=A0=C2=A0=C2=A0yanglint -s ietf-packet-fields\@2018-02=
-02.yang 

                =C2=A0=C2=A0=C2=A0yanglint -s ietf-ethertypes\@2018-02-02=
=2Eyang 

                

                2.2 Example Module

                

                =C2=A0Example module passed `yanglint -s`, but not `pyang=

                --lint`:

                

                =C2=A0=C2=A0=C2=A0yanglint -s example-newco-acl.yang

                =C2=A0=C2=A0=C2=A0pyang --lint example-newco-acl.yang 
                

                =C2=A0=C2=A0=C2=A0example-newco-acl.yang:78: error: keywo=
rd
                "description" not in

                =C2=A0=C2=A0=C2=A0canonical order, expected "type", (See =
RFC 6020,
                Section 12)

                

                =C2=A0=C2=A0=C2=A0example-newco-acl.yang:79: error: keywo=
rd "type" not
                in 

                =C2=A0=C2=A0=C2=A0canonical order, (See RFC 6020, Section=
 12)

                

                =C2=A0=C2=A0=C2=A0example-newco-acl.yang:82: error: keywo=
rd "default"
                not in 

                =C2=A0=C2=A0=C2=A0canonical order, (See RFC 6020, Section=
 12)

                

                =C2=A0Please fix.

              

            

          

          


          

          Fixed.

        


          

            

              


                

                2.3 XML Examples from Section 4.3

                

                =C2=A0yanglint didn't find any issues:

                

                =C2=A0=C2=A0=C2=A0yanglint ietf-access-control-list\@2018=
-02-02.yang
                ex-4.3.xml 

                

                

                2.4 Examples from Section 4.4

                

                =C2=A0I had to stitch these into the 4.3 example. =C2=A0I=
t found
                one issue, a typo

                =C2=A0in the last closing tag in the first example in thi=
s
                section:

                

                =C2=A0=C2=A0=C2=A0yanglint ietf-access-control-list\@2018=
-02-02.yang
                ex-4.4++.xml 

                =C2=A0=C2=A0=C2=A0err : Invalid (mixed names) opening
                (source-port-range-or-operator) and closing (tcp)
                element tags.
(/data/access-lists/acl/aces/ace/matches/l4/tcp/source-port-range-or-oper=
ator/source-port-range-or-operator)

                

                =C2=A0Please fix.

              

            

          

          


          

          Made them complete examples so you do not have to stitch them
          anymore. And made sure yanglint validated the examples before
          it includes it in the draft.

        


          

            

              


                

                =C2=A0PS: And this is not a shepherd directive, but I fou=
nd
                the whole 

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"source-port-range-or-opera=
tor" syntax clumsy. =C2=A0I'm
                surprised

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0it didn't look something li=
ke:

                

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0OLD=


                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<source-port-range-or-operator>
                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<port-range-or-oper=
ator>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<range&=
gt;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<lower-port&g=
t;16384</lower-port>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<upper-port&g=
t;65535</upper-port>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</range=
>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</port-range-or-ope=
rator>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</source-port-range-or-operator>
                

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<source-port-range-or-operator>
                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<port-range-or-operator&g=
t;

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<operator>=


                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<=
operator>eq</operator>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<=
port>21</port>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</operator>=
;

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</port-range-or-operator&=
gt;

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</source-port-range-or-operator>
                

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0NEW=


                

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<source-port>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<range>
=

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<lower>163=
84</lower>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<upper>655=
35</upper>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</range>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</source-port>

                

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<source-port>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<operator>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<operator>=
eq</operator>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<port>21&l=
t;/port>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</operator>

                =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</source-port>

                

              

            

          

          


          

          Did you try making the change in the model to see if it work?
          It will complain that <range> is already used within the
          container and that it cannot be repeated (for
          destination-port).

        


          

            

              


                

                3 Key Draft Sections

                

                

                3.1 Abstract

                

                =C2=A0First, I'm unsure if that first "sentence" is prope=
rly
                worded, but I

                =C2=A0definitely think that it is a bit too much on the t=
erse
                side. =C2=A0Can you

                =C2=A0embellish it a little?

              

            

          

          


          

          How about this:

        


        

        
OLD:

        

          
  This document describes a data model of Acce=
ss Control List (ACL)
  basic building blocks.

        

        
NEW:

        


        

        

          
=C2=A0 This document describes a data model for Access Con=
trol
            List (ACL). =C2=A0

          
=C2=A0 ACL is a ordered-by-user set of rules, used to
            configure the forwarding=C2=A0

          
=C2=A0 behavior in device. =C2=A0Each rule is used to find=
 a match
            on a packet,=C2=A0

          
=C2=A0 and define actions that will be performed on the
            packet.

          


          

          

            

              


                =C2=A0Second, am I reading it correct? - is the "Editoria=
l
                Note" in the

                =C2=A0Abstract section. =C2=A0I strongly advise moving 
              

            

          

          


          

          Moved it to Introduction section.

        


        

        

          

            

              


                3.2 RFC Editor Note

                

                =C2=A0There is no request to replace
                "I-D.ietf-netmod-yang-tree-diagrams" with

                =C2=A0the final RFC assignment.

              

            

          

          


          

          Added.

        


          

            

              


                =C2=A0You might want to add what the current date value u=
sed
                in the draft is

                =C2=A0(i.e., 2018-02-02). =C2=A0=C2=A0PS: my draft build =
tools, which I
                think you're

                =C2=A0using, should set the value for you automatically i=
f
                you put YYYY-MM-DD

                =C2=A0into the text.

              

            

          

          


          

          Added text to replace the revision date in the model with the
          date the draft gets published.

        


          

            

              


                3.3 Import statements missing references

                

                =C2=A0All import statements in all modules are missing
                reference statements

                =C2=A0=C2=A0=C2=A0=C2=A0- why wasn't this caught by the t=
ools?!

                

                =C2=A0Please see rfc6087bis Section 4.7. =C2=A0

              

            

          

          


          

          Adding reference implies import by revision, which we want to
          avoid, specially since we do not want to import by revision.
          Right?

        


          

            

              


                

                3.4 Security Considerations

                

                =C2=A0Please reformat the last paragraph so the "aces" pa=
th
                is more pronounced.

                =C2=A0Perhaps use hangText.

              

            

          

          


          

          What is hangText? I italicized it.

        


          

            

              


                

                3.5 IANA Considerations

                

                =C2=A0This section is hard to read.

                

                =C2=A0Consideration breaking up the "XML" and the "YANG
                Module Names" registry

                =C2=A0requests into two subsections.

                

                =C2=A0Consider making the registration entry requests
                themselves artwork so

                =C2=A0they're line-spaced and indented as such.

                

                =C2=A0The first paragraph of the "XML" registry request s=
ays
                "a URI", but it 

                =C2=A0should be "two URIs"

                

                =C2=A0The first paragraph of the "YANG Module Names" regi=
stry
                request says 

                =C2=A0"a YANG module", but it should be "two YANG modules=
=E2=80=9D

            

          

          


          

          Split into two sections and upped the count of URIs and YANG
          models to three (was missing the ietf-ethertypes module).
=

        


          

            

              


                

                3.6 References

                

                =C2=A0I haven't checked yet, but please verify that all t=
he
                references are

                =C2=A0properly sorted as to being Normative or Informativ=
e.

                

                

                3.7 Appendix A

                

                =C2=A0It took me awhile to figure out what I was looking =
at.
                =C2=A0The tree-diagram

                =C2=A0is poorly indented and there is no text preceding t=
he
                example module.=C2=A0

              

            

          

          


          

          I have moved the example module after the first paragraph,
          that describes the module. Let me know if that looks ok.

        


          

            

              


                =C2=A0I recommend you fold the lines of your tree diagram=
 at
                a certain column

                =C2=A0whilst adding a '\' character. =C2=A0I've since add=
ed this
                ability to my draft

                =C2=A0build tools, let me know if interested in an update=
=2E
                =C2=A0You might also want

                =C2=A0to look at draft-wu-netmod-yang-xml-doc-conventions=
=2E

              

            

          

          


          

          Shortened the prefix so the augment statement fits within 72
          columns.=C2=A0

        


        

        
BTW, I use 'pyang =C2=A0-f tree =E2=80=94tree-line-length=3D=
69' to
          generate the tree. Plus I use fold -w 71 to fold the diagram,
          but I guess it does not work for augment statement.

        


          

            

              


                =C2=A0Also, please fix the example module's namespace per=
 the
                end of 

                =C2=A0rfc6087bis Section 4.9.

              

            

          

          


          

          Updated the namespace to =E2=80=9Chttp://example.com/ns/example-newco-=
acl=E2=80=9D

        


        

        
Cheers.

        
        

        

          
Mahesh Jethanandani

          
mjethanandani@gmail.com=


        

        

      

      

      

      

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


    

    

  


--------------A4D51EC0B70C15013EF6F52D--

--bV67nLr2siJurxfi4NCurHhGQdtUODQne--

--uqctt9kFWw0UGEpCdVMQApb6p0MQxlaRC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlqKiVoACgkQh7ZrRtnS
ejOqmwf/czQZ3jj+e2Fsr2P9HINI1JdpMV/8TKP/4XGIYMUtfxO423MRTtvzWpeh
bhbn6fLyH0mesLg6taKkotuBRJujsemoEaiRN9LXKJNCncifz47+4jffEJDrdqqW
6S4FpNgZGHWe9Gym4Q1Q422frH3htiEe/z76dDsHoqbWjfkUQpO5EwBUs2Ttik51
OdNeZHRjAegaxkHEdWjl5qHBU7a9u+s9V3dv3Ht+SZf7/S+bqrR+OKBxr4UEuYHA
iTaP+GAka3+FgotbSfRmeBpqyTU7rJKCaw8+zY1iU6pQ7YkXgP+GaboY5oUEtFH4
5uvnM+pZFxWd/tsW+y3P3ThxFmsNBA==
=MOR8
-----END PGP SIGNATURE-----

--uqctt9kFWw0UGEpCdVMQApb6p0MQxlaRC--


From nobody Mon Feb 19 09:06:09 2018
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 5C843126CD8; Mon, 19 Feb 2018 09:06:03 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151905996331.18682.1857499241557228932@ietfa.amsl.com>
Date: Mon, 19 Feb 2018 09:06:03 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-yang-data-ext-00.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 17:06:03 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : YANG Data Extensions
        Authors         : Andy Bierman
                          Martin Bjorklund
                          Kent Watsen
	Filename        : draft-ietf-netmod-yang-data-ext-00.txt
	Pages           : 10
	Date            : 2018-02-19

Abstract:
   This document describes YANG mechanisms for defining abstract data
   structures with YANG.  It is intended to replace and extend the
   "yang-data" extension statement defined in RFC 8040.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-yang-data-ext/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-yang-data-ext-00
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-yang-data-ext-00


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Mon Feb 19 09:11:33 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9FD6A1243F6 for ; Mon, 19 Feb 2018 09:11:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=unavailable autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WsuIn8s1naJL for ; Mon, 19 Feb 2018 09:11:30 -0800 (PST)
Received: from mail-lf0-x229.google.com (mail-lf0-x229.google.com [IPv6:2a00:1450:4010:c07::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 01C0C126CD8 for ; Mon, 19 Feb 2018 09:11:30 -0800 (PST)
Received: by mail-lf0-x229.google.com with SMTP id y19so450009lfd.4 for ; Mon, 19 Feb 2018 09:11:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bmvSd2o2Z6sQj9MTEr3KnAV4HqnbcBaWQ0CIyqRRq1Q=; b=ypecK31bytc6J6z6abl7n/OMLbrmpoa1je4i/ARFde6hWal9XhBpS1tRlKfSYXJqW2 p45kf9sk611Qr+CSLjAISKPxxXW//1QQ+XuuVjmVhmpu7X+Y/aZCe7pL90SpuFOSnh08 sG6Xk64uudvGr0FI//pBPt/vx1Q01wVkFfptzEmDTBdgkwO6qcq2Uytl5HPR9JPJVcTF MDlar3cBNjIyY1X7tuBKcbxBBEn05lS6nCesZrfpy2577/36HTNSoINFltqF8Mn3qpPC EnIzVHiZpAfGu1cQj1OG5PyTjVkweoCsOFqEjZAvV6uwhy9Rp9dk4MG2GiIQwWbd2VGr jqgA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=bmvSd2o2Z6sQj9MTEr3KnAV4HqnbcBaWQ0CIyqRRq1Q=; b=Z5z9IUhy2aJEd5/nl/S9StmGFmF46sSY/kG8Pwm/0eDVD3Ub7CuoBQLM/TDYzLBD3b QvnI/Uc9nzu+cJQtKSTAsSJir9nRF8VrPSX3UC6jEdJK5exnzIHYZrMoyP/fJKrKBZpa WMyAIzL7ckH+bOrk1wBe+uh3M6gqjGuknLmgbVXdugk6TeGaSE+3o6tKjX+CRyhoDCHP N6Jp8fSWwuVU8W/SjJRRSh8HWQfVCc0L/CSj2+Vdv6LfZL+ICGW6Iixx0toSUvce3+wL 1cww9MJcs7JpnqWCG5CurtDz8YlL4tU5z1J7vTrF8HBWU2qzuZnlx3UTzyhsEZGcr9/i 60Ug==
X-Gm-Message-State: APf1xPCGtTvrymwt50K+krPMIm0sFmJhkTKiEVtqEJeazMrra0pCLwNA n1C6WCVNghEkSWu9ba+zGx91v4PsMgdVi/mTqIpTQw==
X-Google-Smtp-Source: AH8x2242ABmtHN+OfWbSbznxMfD9FBIqcLNsoSlHLudOQetG+Xl7h88W/ovkAGPPiUlEjYmvN0JjOcWJM3yKXeoolBU=
X-Received: by 10.25.115.79 with SMTP id o76mr5350172lfc.67.1519060288223; Mon, 19 Feb 2018 09:11:28 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Mon, 19 Feb 2018 09:11:27 -0800 (PST)
In-Reply-To: <84afbbd3-685c-ebac-f7cf-c3238f5fa7a6@labn.net>
References: <78d9e3d5-e096-49cf-f3c5-acaf9fc8303a@labn.net> <84afbbd3-685c-ebac-f7cf-c3238f5fa7a6@labn.net>
From: Andy Bierman 
Date: Mon, 19 Feb 2018 09:11:27 -0800
Message-ID: 
To: Lou Berger 
Cc: NetMod WG , draft-bierman-netmod-yang-data-ext@ietf.org,  NetMod WG Chairs 
Content-Type: multipart/alternative; boundary="001a113c36b2df5260056593c80e"
Archived-At: 
Subject: Re: [netmod] WG: Adoption Poll: draft-bierman-netmod-yang-data-ext-01
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 17:11:31 -0000

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

On Thu, Feb 15, 2018 at 5:32 AM, Lou Berger  wrote:

> All,
>
>     The adoption call for this document closed on Feb 8th.
>
> Authors,
>
> Please repost your document with only the 'filename' and date updated as
> draft-ietf-netmod-yang-data-ext-00. Please discuss on list any comments
> received during the adoption call and then capture the results of the
> discussions in the -01 rev. Finally, I believe the -01 rev should indicate
> that the document updates RFC8040.
>
>
I updated the module name and namespace URI from yang-data-ext to
ietf-yang-data-ext.

(IMO the ietf- prefix should not be used unless and until a YANG module is
accepted as a WG draft).



Thank you,
>
> Lou (and co-chairs)
>
>
>
Andy


> On 1/25/2018 8:26 AM, Lou Berger wrote:
>
>> Hi,
>>
>> This is the start of a *two* week poll on making
>> draft-bierman-netmod-yang-data-ext a working group document. Please send
>> email to the list indicating "yes/support" or "no/do not support".  If
>> indicating no, please state your reservations with the document.  If
>> yes, please also feel free to provide comments you'd like to see
>> addressed once the document is a WG document.
>>
>> This poll ends on February 8.
>>
>> Thank you!
>>
>> Lou (and Co-chairs)
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>>
>>
>

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




On Thu, Feb 15, 2018 at 5:32 AM, Lou Berger <lberger@labn.net> wrote:
All,



=C2=A0=C2=A0=C2=A0 The adoption call for this document closed on Feb 8th.


Authors,



Please repost your document with only the 'filename' and date updat=
ed as draft-ietf-netmod-yang-data-ext-00. Please discuss on list any c=
omments received during the adoption call and then capture the results of t=
he discussions in the -01 rev. Finally, I believe the -01 rev should indica=
te that the document updates RFC8040.



I updated the module name and namespac=
e URI from yang-data-ext to ietf-yang-data-ext.

(I=
MO the ietf- prefix should not be used unless and until a YANG module is ac=
cepted as a WG draft).




Thank you,



Lou (and co-chairs)





Andy
=C2=A0

On 1/25/2018 8:26 AM, Lou Berger wrote:



Hi,



This is the start of a *two* week poll on making

draft-bierman-netmod-yang-data-ext a working group document. Please se=
nd

email to the list indicating "yes/support" or "no/do not sup=
port".=C2=A0 If

indicating no, please state your reservations with the document.=C2=A0 If
yes, please also feel free to provide comments you'd like to see

addressed once the document is a WG document.



This poll ends on February 8.



Thank you!



Lou (and Co-chairs)



_______________________________________________

netmod mailing list

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










--001a113c36b2df5260056593c80e--


From nobody Mon Feb 19 13:02:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B8B28124E15; Mon, 19 Feb 2018 13:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.512
X-Spam-Level: 
X-Spam-Status: No, score=-14.512 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_H2=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JfyTvtP0Cy22; Mon, 19 Feb 2018 13:02:35 -0800 (PST)
Received: from alln-iport-1.cisco.com (alln-iport-1.cisco.com [173.37.142.88]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E80EC1200B9; Mon, 19 Feb 2018 13:02:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4928; q=dns/txt; s=iport; t=1519074155; x=1520283755; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=/yCfbAmTmkbCAKl83ZW8xBGkSK+deaNnrcZfYRHn+J0=; b=ZiiXr73ozCsdv9Z2Gboji8daUev0+e2ELp1nFzwfTWbxqVDI0K8AL8zh 4tOvJEuf5xQ51moGQxWJr9gncord3RjELof+E+fvqZNR9EqOb7WZKUy+S LbJ6/Ek1XexLGbYBJZmEyEw39tYPpwwCc4iDqwGXNIMbfXpKlnNp2YOHb w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DmAADTOota/5NdJa1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAoCoNdiiWOBIMZh3+OSoIWCiWFFgIagkFUGAECAQEBAQE?= =?us-ascii?q?BAmsohSQGIxFFEAIBCBoCJgICAh8RFRACBAENBYoKAxUQtm2CJ4c6DYEyghMBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEYBYEPg3gEgiiBV4FoKYMFgmxEAoFbFoMXMYI?= =?us-ascii?q?0BZJSkS41CQKIIohbhQuCIJInixaCcEiJJAIRGQGBOwEfOYFRcBVkAYIYhHZ4j?= =?us-ascii?q?EqBGQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.46,536,1511827200"; d="scan'208";a="72968250"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 19 Feb 2018 21:02:34 +0000
Received: from xch-rcd-011.cisco.com (xch-rcd-011.cisco.com [173.37.102.21]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w1JL2Yvl009232 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 19 Feb 2018 21:02:34 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-011.cisco.com (173.37.102.21) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Mon, 19 Feb 2018 15:02:26 -0600
Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1320.000; Mon, 19 Feb 2018 15:02:26 -0600
From: "Clyde Wildes (cwildes)" 
To: Yaron Sheffer , "secdir@ietf.org" 
CC: "draft-ietf-netmod-syslog-model.all@ietf.org" , "ietf@ietf.org" , "netmod@ietf.org" 
Thread-Topic: Secdir last call review of draft-ietf-netmod-syslog-model-21
Thread-Index: AQHTqMUZsEq/edddJ0uDZKwhfsdUyqOsnO2A
Date: Mon, 19 Feb 2018 21:02:26 +0000
Message-ID: <6E582464-6EDB-4D55-9E8B-BEC68929DF9A@cisco.com>
References: <151896425742.27914.9664814474838013064@ietfa.amsl.com>
In-Reply-To: <151896425742.27914.9664814474838013064@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.154.131.4]
Content-Type: text/plain; charset="utf-8"
Content-ID: <2C52E5A62AB9A447BD783A3B7E4DA356@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 19 Feb 2018 21:02:37 -0000

WWFyb24sDQoNClRoYW5rcyBmb3IgeW91ciByZXZpZXcuIE15IGFuc3dlcnMgYXJlIGlubGluZSBh
cyBbY2x3MV0uDQoNCk9uIDIvMTgvMTgsIDY6MzEgQU0sICJZYXJvbiBTaGVmZmVyIiA8eWFyb25m
LmlldGZAZ21haWwuY29tPiB3cm90ZToNCg0KICAgIFJldmlld2VyOiBZYXJvbiBTaGVmZmVyDQog
ICAgUmV2aWV3IHJlc3VsdDogSGFzIElzc3Vlcw0KICAgIA0KICAgIEdlbmVyYWwgQ29tbWVudHMN
CiAgICANCiAgICAqIFRoZSBzZW1hbnRpY3Mgb2YgcGF0dGVybiBtYXRjaGluZyBpcyBub3QgY2xl
YXI6ICJhbmQvb3IgdGhlIG1lc3NhZ2UgdGV4dCIgLQ0KICAgIGFyZSB0aGVyZSBjYXNlcyB3aGVy
ZSB5b3Ugb25seSBtYXRjaCB0aGUgdGV4dCBidXQgbm90IHRoZSBmYWNpbGl0eS9zZXZlcml0eT8g
Kg0KICAgIA0KW2NsdzFdIFllcy4gVGhlcmUgYXJlIHRocmVlIGNhc2VzOiAxLiBNYXRjaCBvbiBm
YWNpbGl0eS9zZXZlcml0eTsgMi4gTWF0Y2ggb24gdGhlIHJlZ2V4IHBhdHRlcm47IDMuIE1hdGNo
IG9uIGJvdGggZmFjaWxpdHkvc2V2ZXJpdHkgYW5kIHRoZSByZWdleCBwYXR0ZXJuLg0KDQogICAg
SXQncyB2ZXJ5IGNvbmZ1c2luZyB0byBzcGVjaWZ5IHJvbGxvdmVyIGluIG1pbnV0ZXMsIGJ1dCBy
ZXRlbnRpb24gaW4gaG91cnMuDQogICAgUGVvcGxlIGFyZSBib3VuZCB0byBnZXQgdGhpcyBvbmUg
d3JvbmcuDQoNCltjbHcxXSBJIHdpbGwgY2hhbmdlIHRoZSByZXRlbnRpb24gdG8gbWludXRlcyB1
bmxlc3Mgb3RoZXJzIG9iamVjdC4NCg0KICAgICogSW50ZXJmYWNlIHNlbGVjdGlvbjogdGhlIGZl
YXR1cmUNCiAgICBtYWtlcyBzZW5zZSwgYnV0IEkgdGhpbmsgdGhlIGRlc2NyaXB0aW9uIGlzIGlu
Y29ycmVjdC4gIlRoaXMgbGVhZiBzZXRzIHRoZQ0KICAgIHNvdXJjZSBpbnRlcmZhY2UgdG8gYmUg
dXNlZCB0byBzZW5kIG1lc3NhZ2VzIHRvIHRoZSByZW1vdGUgc3lzbG9nIHNlcnZlci4gSWYNCiAg
ICBub3Qgc2V0LCBtZXNzYWdlcyBzZW50IHRvIGEgcmVtb3RlIHN5c2xvZyBzZXJ2ZXIgd2lsbCBj
b250YWluIHRoZSBJUCBhZGRyZXNzIG9mDQogICAgdGhlIGludGVyZmFjZSB0aGUgc3lzbG9nIG1l
c3NhZ2UgdXNlcyB0byBleGl0IHRoZSBuZXR3b3JrIGVsZW1lbnQiLiBBRkFJSyB0aGUNCiAgICBz
b3VyY2UgSVAgd2lsbCBhbHdheXMgY29ycmVzcG9uZCB0byB0aGUgaW50ZXJmYWNlLCBidXQgdGhp
cyBmZWF0dXJlIGFsbG93cyB5b3UNCiAgICB0byBzZWxlY3QgYSBwYXJ0aWN1bGFyIG9uZS4NCg0K
W2NsdzFdIFlvdSBhcmUgY29ycmVjdC4gSSB3aWxsIG1vZGlmeSB0aGUgZGVzY3JpcHRpb24gdG8g
bWFrZSB0aGlzIGNsZWFyZXIuIEhvdyBhYm91dDoNCg0KIlRoaXMgbGVhZiBzZXRzIHRoZSBzb3Vy
Y2UgaW50ZXJmYWNlIHRvIGJlIHVzZWQgdG8gc2VuZCBtZXNzYWdlcyB0byB0aGUgcmVtb3RlIHN5
c2xvZyBzZXJ2ZXIuIElmDQpub3Qgc2V0LCBtZXNzYWdlcyBjYW4gYmUgc2VudCBvbiBhbnkgaW50
ZXJmYWNlLiINCg0KICAgICogVXNhZ2UgZXhhbXBsZXM6IHRoZSBzZWNvbmQgZXhhbXBsZSBsaXN0
cyBhDQogICAgc3BlY2lmaWMgSVB2NiBhZGRyZXNzLCBidXQgdGhlIFlhbmcgc25pcHBldCBzaG93
cyBhIGRvbWFpbiBuYW1lLiANCg0KW2NsdzFdIFRoYW5rcyBmb3IgY2F0Y2hpbmcgdGhpcyBlcnJv
ci4gSSB3aWxsIGZpeCB0aGlzIGluIHRoZSBuZXh0IHJldmlzaW9uLg0KDQogICAgKiBBIGdlbmVy
aWMNCiAgICBxdWVzdGlvbiAoSSBhbSBuZXcgdG8gdGhlIFlhbmcgZWNvc3lzdGVtKTogSSB1bmRl
cnN0YW5kIG1vc3QgaW1wbGVtZW50ZXJzIHdpbGwNCiAgICB1c2UgdGhpcyBtb2R1bGUgZnJvbQ0K
ICAgIGh0dHBzOi8vZ2l0aHViLmNvbS9ZYW5nTW9kZWxzL3lhbmcvYmxvYi9tYXN0ZXIvc3RhbmRh
cmQvaWV0Zi9EUkFGVC9pZXRmLXN5c2xvZy55YW5nDQogICAgLSBpcyB0aGlzIHRoZSBleHBlY3Rh
dGlvbj8gSWYgc28sIHdoeSBub3QgYWRkIGEgbGluayBmcm9tIHRoZSBSRkMgaW50byB0aGUNCiAg
ICByZXBvLCB0byBtYWtlIGl0IGVhc2llciBmb3IgcGVvcGxlIHRvIGZpbmQ/DQoNCltjbHcxXSBJ
dCBpcyBzdGFuZGFyZCBwcmFjdGljZSB0byBpbmNsdWRlIHRoZSBtb2RlbCBpbiB0aGUgUkZDIEFG
QUlLLiBJIGhhdmUgbm90IHNlZW4gZ2l0aHViIGxpbmtzIHB1Ymxpc2hlZCBpbiBhbnkgb3RoZXIg
UkZDcy4NCiAgICANCiAgICBTZWN1cml0eSBDb21tZW50cw0KICAgIA0KICAgICogSSB0aGluayBh
bG1vc3QgYWxsIHdyaXRhYmxlIGRhdGEgbm9kZXMgaGVyZSBhcmUgc2Vuc2l0aXZlLCBiZWNhdXNl
IGEgbmV0d29yaw0KICAgIGF0dGFja2VyJ3MgZmlyc3QgbW92ZSBpcyB0byBibG9jayBhbnkgbG9n
Z2luZyBvbiB0aGUgaG9zdCwgYW5kIG1hbnkgb2YgdGhlIGRhdGENCiAgICBub2RlcyBoZXJlIGNh
biBiZSB1c2VkIGZvciB0aGlzIHB1cnBvc2UuDQoNCltjbHcxXSBJIHdpbGwgcmV3b3JkIHRoZSBz
ZWN1cml0eSBzZWN0aW9uIHRvIGluY2x1ZGUgYWxsIHdyaXRlYWJsZSBub2RlcyBhcyBzZW5zaXRp
dmUuDQoNCiAgICAqIFJlOiByZWFkYWJsZSBkYXRhIG5vZGVzLCBJJ20gbm90DQogICAgc3VyZSB3
aGljaCBhcmUgc2Vuc2l0aXZlLCBhbmQgdGhlIGRvY3VtZW50IHNob3VsZCBnaXZlIGFuIGV4YW1w
bGUgb3IgdHdvIHJhdGhlcg0KICAgIHRoYW4ganVzdCBzYXkgInNvbWUiLiBPdGhlcndpc2UgdGhl
IHNlY3VyaXR5IGFkdmljZSBpcyBub3QgYWN0aW9uYWJsZS4gT25lDQogICAgZXhhbXBsZTogInJl
bW90ZSIgc2VjdGlvbnMgbGVhayBpbmZvcm1hdGlvbiBhYm91dCBvdGhlciBob3N0cyBpbiB0aGUg
bmV0d29yay4NCg0KW2NsdzFdIFRoaXMgdGV4dCB3YXMgbGlmdGVkIGZyb20gYW5vdGhlciBtb2Rl
bC4gSSB3aWxsIHJldmlldyB0aGUgcmVhZGFibGUgbm9kZXMgYW5kIHVwZGF0ZS4NCg0KICAgICog
V3JpdGUgb3BlcmF0aW9ucy4uLiBjYW4gaGF2ZSBhIG5lZ2F0aXZlIGVmZmVjdCBvbiBuZXR3b3Jr
IG9wZXJhdGlvbnMuIC0gSSB3b3VsZA0KICAgIGFkZCAiYW5kIG9uIG5ldHdvcmsgc2VjdXJpdHki
LCBiZWNhdXNlIGxvZ3MgYXJlIG9mdGVuIHVzZWQgdG8gZGV0ZWN0IHNlY3VyaXR5DQogICAgYnJl
YWNoZXMuIA0KDQpbY2x3MV0gSSB3aWxsIGFkZCB0aGlzIHBocmFzZS4NCg0KICAgICogQWxzbyBh
ZGQgYW4gYWR2aWNlLCBzaW1pbGFyIHRvIHRoZSBvbmUgb24gInBhdHRlcm4gbWF0Y2giLCB0aGF0
IHRoZQ0KICAgIHByaXZhdGUga2V5IHVzZWQgZm9yIHNpZ25pbmcgbG9nIG1lc3NhZ2VzIE1VU1Qg
Tk9UIGJlIHVzZWQgZm9yIGFueSBvdGhlcg0KICAgIHB1cnBvc2UsIGFuZCB0aGF0IHRoZSBpbXBs
ZW1lbnRhdGlvbiBvZiB0aGlzIGRhdGEgbm9kZSBtdXN0IGVuc3VyZSB0aGlzDQogICAgcHJvcGVy
dHkgKEknbSBub3Qgc3VyZSBob3cpLiBUaGUgcmF0aW9uYWxlOiBpZiB0aGUgVExTIHByaXZhdGUg
a2V5IGlzIHVzZWQsIGZvcg0KICAgIGV4YW1wbGUsIHRoaXMgY291bGQgcmVzdWx0IGluIGEgc2ln
bmluZyBvcmFjbGUgZm9yIFRMUyBhbmQgZXZlbnR1YWxseSBhIE1JVE0NCiAgICBhdHRhY2suDQoN
CltjbHcxXSBJIHdpbGwgYWRkIHRoaXMgYWR2aWNlLg0KDQpUaGFua3MsDQoNCkNseWRlICAgIA0K
ICAgIA0KDQo=


From nobody Mon Feb 19 18:18:04 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 81BA0126BF3; Mon, 19 Feb 2018 18:17:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.407
X-Spam-Level: 
X-Spam-Status: No, score=-0.407 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DATE_IN_PAST_03_06=1.592, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q75Yrt6w6uDl; Mon, 19 Feb 2018 18:17:57 -0800 (PST)
Received: from mail-pg0-x233.google.com (mail-pg0-x233.google.com [IPv6:2607:f8b0:400e:c05::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 6B34B1243FE; Mon, 19 Feb 2018 18:17:57 -0800 (PST)
Received: by mail-pg0-x233.google.com with SMTP id y8so6563182pgr.9; Mon, 19 Feb 2018 18:17:57 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=T0uJ5I3ZkxWILYpcGW636VG16zpNV2elAKzNIASHxHo=; b=UbW6ZQcBhO1tiGsAnJ4Hy32mmivMHHrkfsKNEQo1kLVBuwm7ariaYd9lBeFQoUWYsi AxNt1mZigF1sz86KjwUwnGkZx7tqAGllKWh1/ro4/6AxnCKbK62SBAwmi4LqX6Wt0xRU 5YqljwBIXFobnOXuRrwGCx7vTRJRKy6uhkTqU5DY++zjTN57UcGmMz8PUAEs12QiN7FV z92R8GuChfPnlKVr50+EyFF84cv6YyiZ9i1LZNyCIH9TtbiMA9FF94PbHQaENbs9IVB2 yDcINuItDXXnb5AAo+tu6/GGurimsugpezdQbkZbx1ZD5MYYoRW1EBAEEXZCX4PTwVD0 eedA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=T0uJ5I3ZkxWILYpcGW636VG16zpNV2elAKzNIASHxHo=; b=efs/3nPa1xHGViEEKuonubYObxZlt5/6j16ExjNNQyScLQ7Q34Usk13lH2pNrgvQru McYLcv5gwy6SN2+XMNzasU31X7u35STYs6HYRbyIiuBGQov6rOkiKd9BiKIR3f7LQvwn Z9xVbRqvijy+1XZ9N3i1UiZa+irtjrUy1AlFRofffZ8rElRPMgK6rEpYpN8VS/Pz4p7E 5LJI06AmpPCbpS5VGuS7ZPVaTfna1v4vTX8jFgg9PGgsC94GcJszCz2fsgvklsxNtap2 udc6oRALtQZ0rONiDjrSMXlhj60HPdUoBp8tbpESV26DGw/9KCVf/Htac8N72u7i5h8K ulbw==
X-Gm-Message-State: APf1xPAAHYPQwpWnVT2tNVhAMYarUMiRLcckOyxqvaMKYtW70IeOzU6z /JGqR+N65j77McFbCoDwgpWubkxZ
X-Google-Smtp-Source: AH8x226ZwRLfSJNDj/b49Wz2K4LvjpdEoYbNF3BFqI+W/0ipK5YIdC9VFvmNbRfjpjrrnfZ1oTNgxw==
X-Received: by 10.98.103.136 with SMTP id t8mr11504724pfj.177.1519093076571; Mon, 19 Feb 2018 18:17:56 -0800 (PST)
Received: from [10.255.69.75] (c-67-180-23-75.hsd1.ca.comcast.net. [67.180.23.75]) by smtp.gmail.com with ESMTPSA id n17sm17354564pfj.67.2018.02.19.18.17.55 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 19 Feb 2018 18:17:55 -0800 (PST)
To: "Clyde Wildes (cwildes)" , "secdir@ietf.org" 
Cc: "draft-ietf-netmod-syslog-model.all@ietf.org" , "ietf@ietf.org" , "netmod@ietf.org" 
References: <151896425742.27914.9664814474838013064@ietfa.amsl.com> <6E582464-6EDB-4D55-9E8B-BEC68929DF9A@cisco.com>
From: Yaron Sheffer 
Message-ID: <4694018c-0be5-e78c-38ed-8745da01d019@gmail.com>
Date: Mon, 19 Feb 2018 14:55:56 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <6E582464-6EDB-4D55-9E8B-BEC68929DF9A@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 02:17:58 -0000

Hi Clyde,

Thank you for responding to my comments. I am OK with all of your responses.

Best,
	Yaron

On 19/02/18 13:02, Clyde Wildes (cwildes) wrote:
> Yaron,
> 
> Thanks for your review. My answers are inline as [clw1].
> 
> On 2/18/18, 6:31 AM, "Yaron Sheffer"  wrote:
> 
>      Reviewer: Yaron Sheffer
>      Review result: Has Issues
>      
>      General Comments
>      
>      * The semantics of pattern matching is not clear: "and/or the message text" -
>      are there cases where you only match the text but not the facility/severity? *
>      
> [clw1] Yes. There are three cases: 1. Match on facility/severity; 2. Match on the regex pattern; 3. Match on both facility/severity and the regex pattern.
> 
>      It's very confusing to specify rollover in minutes, but retention in hours.
>      People are bound to get this one wrong.
> 
> [clw1] I will change the retention to minutes unless others object.
> 
>      * Interface selection: the feature
>      makes sense, but I think the description is incorrect. "This leaf sets the
>      source interface to be used to send messages to the remote syslog server. If
>      not set, messages sent to a remote syslog server will contain the IP address of
>      the interface the syslog message uses to exit the network element". AFAIK the
>      source IP will always correspond to the interface, but this feature allows you
>      to select a particular one.
> 
> [clw1] You are correct. I will modify the description to make this clearer. How about:
> 
> "This leaf sets the source interface to be used to send messages to the remote syslog server. If
> not set, messages can be sent on any interface."
> 
>      * Usage examples: the second example lists a
>      specific IPv6 address, but the Yang snippet shows a domain name.
> 
> [clw1] Thanks for catching this error. I will fix this in the next revision.
> 
>      * A generic
>      question (I am new to the Yang ecosystem): I understand most implementers will
>      use this module from
>      https://github.com/YangModels/yang/blob/master/standard/ietf/DRAFT/ietf-syslog.yang
>      - is this the expectation? If so, why not add a link from the RFC into the
>      repo, to make it easier for people to find?
> 
> [clw1] It is standard practice to include the model in the RFC AFAIK. I have not seen github links published in any other RFCs.
>      
>      Security Comments
>      
>      * I think almost all writable data nodes here are sensitive, because a network
>      attacker's first move is to block any logging on the host, and many of the data
>      nodes here can be used for this purpose.
> 
> [clw1] I will reword the security section to include all writeable nodes as sensitive.
> 
>      * Re: readable data nodes, I'm not
>      sure which are sensitive, and the document should give an example or two rather
>      than just say "some". Otherwise the security advice is not actionable. One
>      example: "remote" sections leak information about other hosts in the network.
> 
> [clw1] This text was lifted from another model. I will review the readable nodes and update.
> 
>      * Write operations... can have a negative effect on network operations. - I would
>      add "and on network security", because logs are often used to detect security
>      breaches.
> 
> [clw1] I will add this phrase.
> 
>      * Also add an advice, similar to the one on "pattern match", that the
>      private key used for signing log messages MUST NOT be used for any other
>      purpose, and that the implementation of this data node must ensure this
>      property (I'm not sure how). The rationale: if the TLS private key is used, for
>      example, this could result in a signing oracle for TLS and eventually a MITM
>      attack.
> 
> [clw1] I will add this advice.
> 
> Thanks,
> 
> Clyde
>      
> 


From nobody Tue Feb 20 08:51:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDE1412D887 for ; Tue, 20 Feb 2018 08:51:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.91
X-Spam-Level: 
X-Spam-Status: No, score=-2.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7wumg6taAsPe for ; Tue, 20 Feb 2018 08:51:31 -0800 (PST)
Received: from EUR01-VE1-obe.outbound.protection.outlook.com (mail-ve1eur01on0138.outbound.protection.outlook.com [104.47.1.138]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4603D127876 for ; Tue, 20 Feb 2018 08:51:30 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=F/ZWBWShinBXoxJWrMnf+PRr2hr6/c42iIOl9MhImWc=; b=RQwjETxWwTmvxj538a0ieJvATZL9CK5KcA/P3x5R9wILAHO0yJk5AYdlgFnzOmGlH3PnK9G33FopMTIje5WXGVJKYYEQdfi0HAihDn+WOGsEgFkmHimAd/uKQtI2gAABQLHpsBojSN63HTtj7grfATUwwi/XADkTgKB0el/S/hk=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.176.21.219) by HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Tue, 20 Feb 2018 16:51:27 +0000
Message-ID: <022001d3aa6a$c31895e0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Kent Watsen" , "NETMOD Working Group" 
References:  <922E608D-951A-459A-B515-B53834C805C1@juniper.net>
Date: Tue, 20 Feb 2018 16:43:50 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.176.21.219]
X-ClientProxiedBy: HE1PR05CA0214.eurprd05.prod.outlook.com (2603:10a6:3:fa::14) To HE1PR0701MB3003.eurprd07.prod.outlook.com (2603:10a6:3:4d::9)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 4a3d7bcc-c180-4965-be37-08d578822f79
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:HE1PR0701MB3003; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 3:wr0CdEdNlOMmHFa/wVQQocdqwTab8zWXMsCmWoM2wzbEVK+EOFlc/7A6SiAYCBfH6U252osaBWrB/uKRbVg10dVfeQWiycZMfKi11kazBCRzq73eaYD0rut4xicKyhqFbTNy7oFLG+etl2zL94Cao4Mc7/wuYdYdwr5NlCUchyUaJ4dOgSV87+U90KB01HRE/xd9SYUc+u2B+WRCb/OFFEj7de6HRg7jwS8AklXQdC5vh66bxNqriMskP3MDX61A; 25:fV9VP+7bMPXTccgsDVxkjUDuDjTWZ1+Wc9EHWtaDgCFYwFPe55+dv7Vgh8OZyekRuS6oqvMrxjRBmkmCH7+p6a5EIv8HBsXMPq3+13J46/tzH4VRKAAuJAsz45ojdZgzwxCqc6U4BemuTEcYuuAEV81Xv5a7vnRFAKQxRFjeZdRr+zR0ZYIRktQPXcupYoWPb//gYT9J89Jh1mpRQPV4S3EK+pWdtZwAPM3+vszhyQnLV5oSduQ3r+pt1TRsC3S6XgowbLZg3JWTki/NFpxliKYccXyjHi97yLmj+/9BUz34hqL7YQkhyCFOukkSWx70fmXodppncSD79qlXhDKNVA==; 31:YvEeXOUWGu2PESRHFcNtEYxuc3ozpbEH5HEAxRXIKvFAwfpwW0Nj7LBov3muOM16tMkzeBTMugbq1gvDw1MUoY6rwQj8J/gbJKs/ytwFUQQsb/V2hB+WSacBN9P5IZbvCsGm9HKIAsKtgm9Bhlc2kh0qnHAyJcybpsq2WmXWBk/URJJDsKRAi5vymlK8JIKC3PknKSzTgZUP8co1wsKWZy9DjMuVVd0dHtrZQ1A8gWw=
X-MS-TrafficTypeDiagnostic: HE1PR0701MB3003:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(138986009662008)(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3002001)(10201501046)(3231101)(944501161)(93006095)(93001095)(6055026)(61426038)(61427038)(6041288)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(20161123562045)(20161123558120)(6072148)(201708071742011); SRVR:HE1PR0701MB3003; BCL:0; PCL:0; RULEID:; SRVR:HE1PR0701MB3003; 
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 4:N/c5Z5vNR4NFrLygInVhooWpxxv4oFMpSGKEZv5TsdKM6qGUG2SCI+P9rjr2XIBFt1E9wgMM0fmdjlrPSbHOW/BnXyZaL+n5+VlRc5HVyIZEVgON7wwgTzZKQroJ88RhU08VX73B+S/sUVHa4Dgtr0SPIQlm29hSKvPytsoCLKnGNkff0lrDocob9M9v+PrfP5Aea4mR/ltV9L8WjGizx+Dvir2BafgqjCt4TI6xRhnoC2Mvz/IQrRUKJ5Xt9dBecy9Ek6bugEEE44N65DeG3a559H3QXI/FbdU31HVC5x6Wz/cFZb9PHK6G3zMEmIsZSBYZqjk2TwsSPBvShAeKANBu4mkL/n6rCxdsgwhftQ4=
X-Forefront-PRVS: 05891FB07F
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(396003)(346002)(39860400002)(366004)(376002)(189003)(199004)(13464003)(81686011)(229853002)(966005)(97736004)(1941001)(3846002)(84392002)(81166006)(81156014)(8676002)(6116002)(50226002)(1556002)(6246003)(8936002)(61296003)(52116002)(23676004)(6496006)(53936002)(478600001)(68736007)(230700001)(44716002)(2906002)(62236002)(47776003)(4720700003)(6666003)(86362001)(5660300001)(66066001)(14496001)(106356001)(33896004)(25786009)(6486002)(7736002)(305945005)(50466002)(44736005)(76176011)(81816011)(105586002)(6306002)(9686003)(8666007)(316002)(26005)(110136005)(386003)(5820100001)(59450400001)(186003)(16526019)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:HE1PR0701MB3003; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtIRTFQUjA3MDFNQjMwMDM7MjM6Vmsxa2IrWGc0bVozVVQ2TVRIODNQN2NW?= =?utf-8?B?a2NLdDFLTVdpS0NZQ1JhMjRjYTkxMng1TnBNVzNuQU1PM2xHdUpvSjNIRWlk?= =?utf-8?B?MjhKRHVkbk9YNFo2RVZTdFIxREN0dkIvNlpyMEhML05VSDZpN0ZpODU1TWZs?= =?utf-8?B?S05ibXFnSjlRWlpZNlk3SnFKZGhRYUU3eG1meTNtTTB4WFFQTFpoZktsWEVN?= =?utf-8?B?NXJQcjJITFBXSTFXYmNRMXkxVVk5T3RvVnJiTlRieTJuN3BpZFhvZkEyWThm?= =?utf-8?B?S2pYM01TdDVtZ3FiaUlkdWtBa05ZZG9pMEZJdW05ak0xWjRoTng1RHlTNDRq?= =?utf-8?B?ZmZ5c2hQR3Y5Nk9YcWtIelNVT2lpN1NvU2F5eXJlQzRSOUliZjZiejRXWllz?= =?utf-8?B?UzJzK1E4dGdmNnZZditrS0ExVUR2VUp1WkVNSWgrUk0vdlllSStNYXdza2Fi?= =?utf-8?B?WTQ5VnFsd1lLaTNIUHVDaFZDdW1VYXNRdjUrRWVtUlo0dVBVYWNCVU9WQjhp?= =?utf-8?B?NlE3TGlJVHpTYlBZNHlmYjZOcXZWOEdTTHByTS9lQnp3WHUzTm1GUy95MmVS?= =?utf-8?B?d1FoT0ZHcFhIdUx5S1k4M0kxU3BtZDVEUDMzbVlKZEhXUVdJQTVzR2gzUkR0?= =?utf-8?B?WnRCUmliR3cxcVdPRXQxMXdISWlsc25scVJFbS91SERXQ1BIcnc1cEZuQUpr?= =?utf-8?B?eHY0azRmQndncWZ6MmRCb2xhK0dkTFdFR3BKZjZucEozanUyL0tUbSsxbEda?= =?utf-8?B?VVlsT3BnaHBFUHNPd1JZMWcxb3JqVndpbVY5ZmQvM1Q5bERVTC9LUXhJVlF4?= =?utf-8?B?SjFTdmpWYzJzanUzOHlOb3VnVVhSU0Uvb1BSc0RLeTAvZ0U4Nkd0MEJ1MFh1?= =?utf-8?B?Zy95Y1VNalBHeTVHZVZEVUZnVGwxS090bDkrTEQ2L20wT2ZHUU0wblYrcm5L?= =?utf-8?B?SHJKbWY2SC9CeUxKU2xhTGJNTm9IcEkyLy9QcWFxcW5WaVREZ0dIVHl3MEh3?= =?utf-8?B?akd5NVVZQ0p0eUxQTlFIR2k1MGFpRXhRNkZwVzVNclVKTWYyZmxYRWc2RjB1?= =?utf-8?B?cFJTeDMvMDZNQ2RmMDlOT3ZSbDhxS0dJZU5PQk04dDdYbVBiQ2RWaVZScU42?= =?utf-8?B?WS9jNDRDSm9SdzNFdWZnMjVRT1FCa3FkZ2hrUUFnTk5rY2dEMHBkQzBma2Fo?= =?utf-8?B?RzBWdW9kVFNZUDVaSXNqVzNwem53d2l2TWZlVFRzY2Z5SE56UUNuOFlPdFhZ?= =?utf-8?B?NTd5QWhOZmtHTVExVDZkdUE5azlpK01JRnE0UTZOa1JXZkNOZ0NDeDczR0pj?= =?utf-8?B?YUFISGpkWUMyTDNlbCtUOEFpSWFjVzEyc29GL0t3K2R4Zi9nc3VpY0pSb0Fh?= =?utf-8?B?aUhxb3Z2WnNjVDRIR3V4OE14QU1NdzY1SGszTWdhSVJWNExGdmR1WkJOQ2RN?= =?utf-8?B?VXRDZXRzWU9rMlEzNklsVlRmYjNaQzlCSkdQeWk0bDl5eFpRYU1zZEpaOHl4?= =?utf-8?B?L1kyTUtJL0ZCYXFDU0pVYk4zQzRudVpncDJIWVpNWDQzZEtaRDVjK0ptbGNm?= =?utf-8?B?VC9hQ0drWnU3Z3MrTVdQb3JBTEhUMzJyeW5hbUc2NjRrV09iVDAxeWtoSzVV?= =?utf-8?B?WHpVU3FaVlJtSU5OSll3WHhwY3NEWWowVGQxNGdEeWFac21LTGxlNDY2cnZK?= =?utf-8?B?T2k4elFGMkFGdFliOWY3dWZDbmNUSEVscmxGNzNEeG95VXorODE3TnYrVVBQ?= =?utf-8?B?eTFHQm5GdWQxMjBPMkM3UmhXY1BGYnh3QmZmdGcwVmd0SURuK1lBY1E2Wmoz?= =?utf-8?B?RXlpaTdWVS9lZi9MUFo0dHJYNGdGNVg3K0ZUbVZqQ2FwRmJWei9wZGFJbUZW?= =?utf-8?B?L0l1MDNESmNyZ2QzbkJEVE9LMUNhZno4SERmQ1RGaERZYm1TNzVUclZtZXhj?= =?utf-8?B?eDlnTEx3MjlLWkdwVnNXOFNVTG9XdkNWb2w5MmsyUHN0T2VDT2svV0RkMlhy?= =?utf-8?B?SHArS2tYS2R0S2xZLzZJb1VMczdXcmR0aGVWWmFnPT0=?=
X-Microsoft-Exchange-Diagnostics: 1; HE1PR0701MB3003; 6:qlmHCSU8Ig3ZvGxfRNqgqS0yVjAenR5LDVH9zbFPAVsXbx2we1QsGhZsTcVO8gvLpt5iS8FBSD1TVIA+l04Iz6O0OsrpW90tLtQz2osgfEPvmjFHuLOs/vV/B6Ss6WHIC+nxVddNEsClAKIf0Fw0Oq10UjgWOVkgW+reorM3Pp2LYb/yseLcPhyXcsInePAPAjU+FLUYVujvURf2rKblIMnhPBNBDawrVVSNw6Lj2m4Bx60cfJ4iX+73JcNLbjtkNavxhd0T7pgPTj84pmqFtBmATD+4SqiYnd4NCvvulXYeGEc4S4cOImZ5xS6HBLkhGGR5E5ezo5SO/4H5vQNgFftokelg/K+oo0zuUywYJQw=; 5:ItzSI0fl1w69Q8s9p3KOQE1KgEiem8NjG/6lc1JZF9IpqQA6mcBaKqslIFBqhq7Mdzzzh2R90kiAWl41HFEcBRdHTLC0HJzrGOeXznS1Vm1ee768kuRsV9tVx5k6Gpry2ymWe8qrFF36DLFU1ZUTnrBG2pgumc6mQHC7wZ3AktE=; 24:o/lv9yLLmwgjvuYsZkQn4CLQOwSIEejkyGvMzICpt9NmQ+ALboafWp/r1E6N6jKOf0mPXXDdpfYmTIjt50rPVE51R3cW4YyWcidqSuAh1yw=; 7:11c5vxXdJoVR+DSc72LGFa5ZbcX541V9WrOPH8gqZ2tkw29AZt/bhRQwQ+2MfFxaVjPy+sPPop+sXy+ReuR/TV1/I+agvWuK7/sqEPtRiBBJq/jd7PpnpEtEkiy2l6mJ4Efm6cA/HMRai7zHTzU1shfdyBcLQOGXI3VSiIoN4NSnXoLPgRGCXutoliunPM/87Qtmv9W4VL8CN544UpJ1C9O3jMh66nXA+UXkZvcjTQK9yTlTdqy9P1NIiImWMDOU
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 20 Feb 2018 16:51:27.6944 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 4a3d7bcc-c180-4965-be37-08d578822f79
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: HE1PR0701MB3003
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 16:51:35 -0000

----- Original Message -----
From: "Kent Watsen" 
Sent: Wednesday, February 14, 2018 6:03 PM

> Buggers, I thought we caught that tree-diagrams informative/normative
thing before.
>
> Regardless, Clyde, please note that I think I was wrong before from
the shepherd write-up regarding idnits having a problem:
>
> """
>   == Unused Reference: 'I-D.ietf-netconf-keystore' is defined on line
1340,
>      but no explicit reference was found in the text
>      '[I-D.ietf-netconf-keystore] Watsen, K., "YANG Data Model for a
"Keys...'
>
>    This is a bug in idnits, whereby a reference that splits two lines
is
>    not found.
> """
>
> Looking at the XML, it seems that references are not specified
correctly.
>
> CURRENT:
>
>         This module imports typedefs from [RFC7223], groupings from
>         [I-D.ietf-netconf-keystore], and
[I-D.ietf-netconf-tls-client-server], and it references [RFC5424],
>         [RFC5425], [RFC5426], and [RFC5848] and [Std-1003.1-2008].
>
> SHOULD BE:
>
>         This module imports typedefs from ,
groupings from
>         , and , and it references ,
>         , , and  and .
>
> Right?
>
> And while you're at it, please update the reference to the
tree-diagrams draft (-06 is current).  Also, missing is an RFC Editor
note requesting that the I-D reference to be updated to reflect the
assigned RFC number.

Kent

You illustrate beautifully the problem I would like a solution to.

The current thinking AFAICT is that
tree-diagrams
should be an Informative Reference.

Therefore, the RFC Editor will not hold publication until an RFC number
is assigned.

Therefore, a note asking the I-D reference to be updated to reflect the
assigned RFC number is null - the RFC can be published with the
reference as an i-d and not as an RFC which is what I expect the RFC
Editor to do.

QED

Note that this is not the case of a Normative i-d reference being buried
in the YANG module and not being.noticed by the RFC Editor; that problem
I am content with.


Tom Petch








>
> Please also address these issues when posting -21 to address Benoit's
issues.  Please post -21 ASAP as Benoit has already placed this draft on
the IESG telechat in a couple weeks.
>
> Thanks,
> Kent // shepherd
>
>
> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
 on behalf of
bclaise@cisco.com> wrote:
>
> Dear all,
>
> - the draft is NMDA compliant, right? It should be mentioned.
> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
>
>    The YANG model in this document conforms to the Network Management
>
>    Datastore Architecture defined in
I-D.ietf-netmod-revised-datastores.
>
>
> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
should be an informative reference, not normative.
>
> - Editorial:
> OLD:
> This draft addresses the common leafs
> NEW:
> This document addresses the common leafs
>
> Please publish a new version asap.
> In the mean time, I'm sending this draft to IETF LC.
>
> Regards, Benoit
>
>
>


------------------------------------------------------------------------
--------


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


From nobody Tue Feb 20 09:06:26 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AD3912D94E for ; Tue, 20 Feb 2018 09:06:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.49
X-Spam-Level: 
X-Spam-Status: No, score=-2.49 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uqU3aVQHpLLT for ; Tue, 20 Feb 2018 09:06:23 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 836EF126CB6 for ; Tue, 20 Feb 2018 09:06:23 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1KGwrMo032739; Tue, 20 Feb 2018 09:06:20 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=g+6ObomNggwgBPMUYmnjeoCsjYlANHc8zQMi2xcdBlE=; b=aHiqoVnydTvN3bTiGR9SsuaCg4nAzRQirE07XsC6PTi815D5o/+SAZkczyWhNKfKnOfw gE8Bc9R7pG1/KloZYU2M2h/aUBesoOct+xg4I4F8vQAbAz2FWntS0AR/QBlKIMZospMB Uf0NqnXFsYeGZ+smXO8LHSYGHzGub9o9Ha3lnt3ix5keepxdBMMCzIq48J0jmPJZy7Q/ xIe69OXSyhigI2TAFXyWv2w+dfiA1FVOEmxMagUv5OYPjnlACzdRukzUiAw7KD7UTlyT f8+mLE+Di/cD/Fj7PiPWfuP258A8OaBymgvSAReZn4AOC40QR6zDcFD1zyNgskY3JJzg pQ== 
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0052.outbound.protection.outlook.com [216.32.180.52]) by mx0a-00273201.pphosted.com with ESMTP id 2g8qecg1g2-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 20 Feb 2018 09:06:19 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3113.namprd05.prod.outlook.com (10.173.219.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Tue, 20 Feb 2018 17:06:18 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b%2]) with mapi id 15.20.0527.014; Tue, 20 Feb 2018 17:06:18 +0000
From: Kent Watsen 
To: "t.petch" , NETMOD Working Group 
Thread-Topic: [netmod] AD review of draft-ietf-netmod-syslog-model-20
Thread-Index: AQHTpZZd5Geu+8X2WUq2NsIzPrmhNqOj3UoAgAmtrxX//7BHAA==
Date: Tue, 20 Feb 2018 17:06:18 +0000
Message-ID: 
References:  <922E608D-951A-459A-B515-B53834C805C1@juniper.net> <022001d3aa6a$c31895e0$4001a8c0@gateway.2wire.net>
In-Reply-To: <022001d3aa6a$c31895e0$4001a8c0@gateway.2wire.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3113; 7:mP/LPswagS5hqin+TpBEhG0a6WQUvRZCsuIqw7bHNxAWAJdtHLbCgfjZ4Xc6TyX+Hb/SMIEqKULTsk6c5dC1VrACzaNyFg9C8fgv4WNlUr3pV5LdzkGmskTDK2NAUR4zG+3SHS94hlQiIeK91+MxCP3U1eT7WzC20++50KnXhz1cKlJ98jnpsSSJUF+S3GGsgjzLt9hC84rgUSMN1qeNNrc1cD/K4z5U8MxlgRdVFS+7JBIbwld0ADUlv9oMWcxe
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: f8243487-7ac0-429a-2f2a-08d578844245
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3113; 
x-ms-traffictypediagnostic: DM5PR05MB3113:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162)(95692535739014);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(6040501)(2401047)(5005006)(8121501046)(93006095)(93001095)(3002001)(3231101)(944501161)(10201501046)(6055026)(6041288)(20161123558120)(20161123562045)(20161123564045)(20161123560045)(201703131423095)(201703031522075)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR05MB3113; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3113; 
x-forefront-prvs: 05891FB07F
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(39380400002)(396003)(346002)(39860400002)(376002)(199004)(189003)(66066001)(3660700001)(6486002)(99286004)(3846002)(2900100001)(26005)(83716003)(6116002)(105586002)(33656002)(2950100002)(6512007)(6246003)(82746002)(53936002)(6436002)(3280700002)(7736002)(76176011)(305945005)(575784001)(8666007)(86362001)(6306002)(25786009)(8936002)(102836004)(53546011)(110136005)(5660300001)(58126008)(6506007)(5250100002)(68736007)(186003)(97736004)(14454004)(966005)(81156014)(81166006)(229853002)(2906002)(106356001)(36756003)(316002)(8676002)(478600001)(296002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3113; H:DM5PR05MB3484.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)
x-microsoft-antispam-message-info: C+q3Icn524BFv6XMFvbkpRiA1/l4Mc3tyhbzFuPbWGcbRVAsknIZf9NC9aDxTUTXB055itCzI6NGAkvvIEKyJRULLRKicQwGBED6hQvXWZkYxsGaBDUPtze6orMrP9kfWHpAwjj0Oy4fx6kz20eNFxnWir9S4lH9pykGr7iGrWg=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: f8243487-7ac0-429a-2f2a-08d578844245
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Feb 2018 17:06:18.4858 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3113
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-20_06:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802200209
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 20 Feb 2018 17:06:25 -0000

DQoNCg0KPiBLZW50DQo+IA0KPiBZb3UgaWxsdXN0cmF0ZSBiZWF1dGlmdWxseSB0aGUgcHJvYmxl
bSBJIHdvdWxkIGxpa2UgYSBzb2x1dGlvbiB0by4NCj4NCj4gVGhlIGN1cnJlbnQgdGhpbmtpbmcg
QUZBSUNUIGlzIHRoYXQgdHJlZS1kaWFncmFtcw0KPiBzaG91bGQgYmUgYW4gSW5mb3JtYXRpdmUg
UmVmZXJlbmNlLg0KPg0KPiBUaGVyZWZvcmUsIHRoZSBSRkMgRWRpdG9yIHdpbGwgbm90IGhvbGQg
cHVibGljYXRpb24gdW50aWwgYW4gUkZDIG51bWJlcg0KPiBpcyBhc3NpZ25lZC4NCj4gDQo+IFRo
ZXJlZm9yZSwgYSBub3RlIGFza2luZyB0aGUgSS1EIHJlZmVyZW5jZSB0byBiZSB1cGRhdGVkIHRv
IHJlZmxlY3QgdGhlDQo+IGFzc2lnbmVkIFJGQyBudW1iZXIgaXMgbnVsbCAtIHRoZSBSRkMgY2Fu
IGJlIHB1Ymxpc2hlZCB3aXRoIHRoZQ0KPiByZWZlcmVuY2UgYXMgYW4gaS1kIGFuZCBub3QgYXMg
YW4gUkZDIHdoaWNoIGlzIHdoYXQgSSBleHBlY3QgdGhlIFJGQw0KPiBFZGl0b3IgdG8gZG8uDQo+
IA0KPiBRRUQNCg0KDQpFeGNlcHQgSSBrbm93IHRoYXQgdGhpcyBkcmFmdCB3aWxsIGJlIHN0dWNr
IGluIE1JU1JFRiBzdGF0ZSBhbmQgdHJlZS1kaWFncmFtcw0Kd2lsbCBpbiBmYWN0IGJlIGFzc2ln
bmVkIGFuIFJGQyBudW1iZXIgYnkgdGhlIHRpbWUgdGhpcyBkcmFmdCBpcyBwdWJsaXNoZWQuDQoN
CksuDQoNCg0KPiBOb3RlIHRoYXQgdGhpcyBpcyBub3QgdGhlIGNhc2Ugb2YgYSBOb3JtYXRpdmUg
aS1kIHJlZmVyZW5jZSBiZWluZyBidXJpZWQNCj4gaW4gdGhlIFlBTkcgbW9kdWxlIGFuZCBub3Qg
YmVpbmcubm90aWNlZCBieSB0aGUgUkZDIEVkaXRvcjsgdGhhdCBwcm9ibGVtDQo+IEkgYW0gY29u
dGVudCB3aXRoLg0KPg0KPg0KPlRvbSBQZXRjaA0KDQoNCg0KDQoNCg0KDQoNCj4NCj4gUGxlYXNl
IGFsc28gYWRkcmVzcyB0aGVzZSBpc3N1ZXMgd2hlbiBwb3N0aW5nIC0yMSB0byBhZGRyZXNzIEJl
bm9pdCdzDQppc3N1ZXMuICBQbGVhc2UgcG9zdCAtMjEgQVNBUCBhcyBCZW5vaXQgaGFzIGFscmVh
ZHkgcGxhY2VkIHRoaXMgZHJhZnQgb24NCnRoZSBJRVNHIHRlbGVjaGF0IGluIGEgY291cGxlIHdl
ZWtzLg0KPg0KPiBUaGFua3MsDQo+IEtlbnQgLy8gc2hlcGhlcmQNCj4NCj4NCj4gT24gMi8xNC8x
OCwgODoxOCBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgQmVub2l0IENsYWlzZSINCjxuZXRtb2Qt
Ym91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFs
ZiBvZg0KYmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPj4gd3JvdGU6
DQo+DQo+IERlYXIgYWxsLA0KPg0KPiAtIHRoZSBkcmFmdCBpcyBOTURBIGNvbXBsaWFudCwgcmln
aHQ/IEl0IHNob3VsZCBiZSBtZW50aW9uZWQuDQo+IEV4OiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM3
MjIzYmlzLTAzLCBpbiB0aGUgYWJzdHJhY3QgYW5kIGludHJvDQo+DQo+ICAgIFRoZSBZQU5HIG1v
ZGVsIGluIHRoaXMgZG9jdW1lbnQgY29uZm9ybXMgdG8gdGhlIE5ldHdvcmsgTWFuYWdlbWVudA0K
Pg0KPiAgICBEYXRhc3RvcmUgQXJjaGl0ZWN0dXJlIGRlZmluZWQgaW4NCkktRC5pZXRmLW5ldG1v
ZC1yZXZpc2VkLWRhdGFzdG9yZXMuDQo+DQo+DQo+IC0gQXMgbWVudGlvbmVkIGluIHRoZSB3cml0
ZXVwLCBbSS1ELmlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtc10NCnNob3VsZCBiZSBhbiBp
bmZvcm1hdGl2ZSByZWZlcmVuY2UsIG5vdCBub3JtYXRpdmUuDQo+DQo+IC0gRWRpdG9yaWFsOg0K
PiBPTEQ6DQo+IFRoaXMgZHJhZnQgYWRkcmVzc2VzIHRoZSBjb21tb24gbGVhZnMNCj4gTkVXOg0K
PiBUaGlzIGRvY3VtZW50IGFkZHJlc3NlcyB0aGUgY29tbW9uIGxlYWZzDQo+DQo+IFBsZWFzZSBw
dWJsaXNoIGEgbmV3IHZlcnNpb24gYXNhcC4NCj4gSW4gdGhlIG1lYW4gdGltZSwgSSdtIHNlbmRp
bmcgdGhpcyBkcmFmdCB0byBJRVRGIExDLg0KPg0KPiBSZWdhcmRzLCBCZW5vaXQNCj4NCj4NCj4N
Cg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0NCi0tLS0tLS0tDQoNCg0KPiBfX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KPiBuZXRtb2QgbWFpbGluZyBsaXN0DQo+IG5l
dG1vZEBpZXRmLm9yZw0KPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJs
P3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUNh
USZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhu
SlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Y0o3TVZuUVZjMWhneHBWRjdv
WWlWbjZSYm0tUWYyZER5cmZZaEwtczlpbyZzPXUwSG45R2tPLUIwalVHbTFNbklRNHg0QWdJWk5Y
SEJJYVpoVFBtdDNkQzgmZT0NCj4NCg0KDQoNCg==


From nobody Tue Feb 20 20:49:59 2018
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 DB1F3126C22; Tue, 20 Feb 2018 20:49:58 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151918859885.9733.17798188627462397476@ietfa.amsl.com>
Date: Tue, 20 Feb 2018 20:49:58 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-rfc6087bis-18.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 04:49:59 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : Guidelines for Authors and Reviewers of YANG Data Model Documents
        Author          : Andy Bierman
	Filename        : draft-ietf-netmod-rfc6087bis-18.txt
	Pages           : 71
	Date            : 2018-02-20

Abstract:
   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.  This document
   obsoletes RFC 6087.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-rfc6087bis-18
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-rfc6087bis-18

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-rfc6087bis-18


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Tue Feb 20 20:52:03 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05B16129C6D for ; Tue, 20 Feb 2018 20:52:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level: 
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=yumaworks-com.20150623.gappssmtp.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sBS2GVeyPnpd for ; Tue, 20 Feb 2018 20:52:00 -0800 (PST)
Received: from mail-lf0-x234.google.com (mail-lf0-x234.google.com [IPv6:2a00:1450:4010:c07::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 7DAE012AF83 for ; Tue, 20 Feb 2018 20:51:59 -0800 (PST)
Received: by mail-lf0-x234.google.com with SMTP id g72so546526lfg.5 for ; Tue, 20 Feb 2018 20:51:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yumaworks-com.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=evbYqBCjF2/Zgs3luYdqjQQL+2ww9WhzXmbXoc9vQdI=; b=FniJM8RK3xnbfwIlWpY1ze6a4eOfCWPulqDYWhnN9uERSgvKErRszgi4NZK7JTPQIO u/JIcA3Wn7TwtqGUG2eNDquie8e/1O989s/vFxk/UJ/hhfy30FZBgcefsLjbEUozEGar 06prcxswEk4fkurtb8qjnVg7vBj62WVZwr/Y7SXEDZOKZMXeDb3ReXFVk/2aXwpd7Vub o129VuxfphsRjhAhjgF4t0cp+BrD8Kxzrw+VktxfU+6J7LnmwU5PWCn8spAbJ0DoafI8 ihR1FOX33vnkPg9880ymvMC3n+HEwFm9T4FkAqrEV4Ni9AS0JWz7DRA+qlk1pJHGGsIa HkuA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=evbYqBCjF2/Zgs3luYdqjQQL+2ww9WhzXmbXoc9vQdI=; b=PxFLgS8PausizvKnpSTcK2n523YoLBa4mfPu4SkDngYVr3TY7oyf0O1XDbm4+3DVA9 V/XKebOvrRf+K8bI+44cSvIEdYYJ9GQl4yTtO6PnhMcLMCT9SHhQbT4KOoUVMLGlEIo9 QutqUYlSEYpsODVRMaLs/dm34rWC1MH4xHcmnsDIeqEYbWKA8y4VjBivafuCvvqELxYZ 55SMqmNC0WFCi/sEMntxAoz+48fuPDHFvbxlm31iikidNK9+OBoQtFjSyRfiB+oZtfTC 8XY7dB3Gaeh/DibpQtH2ZVFgQhtK7dFMFVL4pevODznSwtZViCk1cvhxmFh5hqjfMwCN AkEQ==
X-Gm-Message-State: APf1xPAMW+Kb0oiD8PWDBa5gA5tWEd24GRrMpFvjcHXXus9pnsJpHQ7w JEFPMvu5yU5V9ZebHg5wWvzDjxjQNe+BxjhpqOT10g==
X-Google-Smtp-Source: AH8x226Z/cHI9eODYYGFeDkrtGhP3hzx9NkXhewKQYjPfE+HrsmgAJdQ3MXccLWn9Ym8+umRRYDwbioCQwCfsxgVjcI=
X-Received: by 10.46.69.85 with SMTP id s82mr1367953lja.6.1519188717656; Tue, 20 Feb 2018 20:51:57 -0800 (PST)
MIME-Version: 1.0
Received: by 10.25.21.210 with HTTP; Tue, 20 Feb 2018 20:51:56 -0800 (PST)
In-Reply-To: 
References: 
From: Andy Bierman 
Date: Tue, 20 Feb 2018 20:51:56 -0800
Message-ID: 
To: Benoit Claise 
Cc: NETMOD Working Group 
Content-Type: multipart/alternative; boundary="001a114b0fcedcf0f00565b1af6c"
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis Part 2
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 04:52:02 -0000

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

Hi,

I think draft-18 addresses all these issues.
A guideline about key leaf order has also been added.

Andy


On Wed, Feb 14, 2018 at 7:11 AM, Benoit Claise  wrote:

> Dear all,
>
> Here is the part 2 of the AD review, from section 4.21 on.
>
> Regarding the part 1, thanks Andy for addressing all comments in version 17.
>
> - section 4.22 "Data Correlation.
>
> Not sure what you mean by the section title and "Data can be correlated in various ways"?
> Which data? YANG modules, YANG objects, object instances, from different YANG server, etc.
> I guess I miss a sentence or two regarding this "correlation" objective and which guidelines this section
> is going to provide to "authors and reviewers of Standards Track specifications containing YANG data model modules".
> Note: I read that section multiple times.
>
> - section 4.22
>    It is sometimes useful to separate configuration data and operational
>    state, so that they do not not even share the exact same naming
>    characteristics.  The correlation between configuration the
>    operational state that is affected by changes in configuration is a
>    complex problem.  There may not be a simple 1:1 relationship between
>    a configuration data node and an operational state node.  Further
>    work is needed in YANG to clarify this relationship.  Protocol work
>    may also be needed to allow a client to retrieve this type of
>    information from a server.  At this time the best practice is to
>    clearly document any relationship to other data structures in the
>    "description" statement.
>
> Isn't it clarified with NMDA. It's not inline with 4.23.2, which says:
> 	
>    Designers SHOULD describe and justify any NMDA exceptions in detail,
>    such as the use of separate subtrees and/or separate leafs.
>
> ... and I guess confusing in light of the real guidelines in 4.23.3
> Btw, why is this paragraph in 4.22 and not in 4.23?
>
> - section 4.23
>
> 	Operational state is now modeled using YANG according to new NMDA,
>
> Please add a reference to the draft.
>
> - section 4.26 "YANG 1.1 Guidelines"
> I'm confused by the title. The entire document is about 1.1, right?
> I guess you want to express something such as "YANG 1.1 specific Constructs Guidelines"
>
> - section 4.26.1
>
>  Multiple revisions of the same module can be imported, provided that
>  different prefixes are used.
>
> Reading https://tools.ietf.org/html/rfc7950#section-7.1.5. Any contradiction?
> Then reading:
>    This MAY be done if the authors can
>    demonstrate that the "avoided" definitions from the most recent of
>    the multiple revisions are somehow broken or harmful to
>    interoperability.
>
> "avoided" definitions?
> I simply don't understand this sentence.
>
> - section 4.26.4
>    The NETCONF Access Control Model (NACM) [RFC6536 ] does not support
>    parameter access control for RPC operations.
>
> Let's use draft-ietf-netconf-rfc6536bis
>
>
> - Appendix B
>
>    YANG Module Registry: Register the YANG module name, prefix,
>          namespace, and RFC number, according to the rules specified
>          in [RFC7950 ].
>
> I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" registry is specified in RFC6020/.
> See for example https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6
>
> - Appendix B
> References -- verify that the references are properly divided
>       between normative and informative references, that RFC 2119  is
>       included as a normative reference if the terminology defined
>       therein is used in the document
>
> Refer to RFC8174
>
> - Appendix B (and maybe some more text somewhere else.
> To refer to Tom Petch latest email to NETMOD, we should need a few words about:
>   If a YANG module has a Reference or Description clause specifying an
>   I-D, and the I-D is listed as an Informative Reference.
>
> Regards, Benoit
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
>
>

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


Hi,

I think draft-18 addresses all thes=
e issues.
A guideline about key leaf order has also been added.

Andy


On Wed, Feb 14, 2018 at 7:11 AM, Beno=
it Claise <bclaise@cisco.com> wrote:

 =20

   =20
 =20
  

    
Dear all,

Here is the part 2 of the AD review, from section 4.21 on.

Regarding the part 1, thanks Andy for addressing all comments in version 17=
.

- section 4.22 "Data Correlation.

Not sure what you mean by the section title and "Data can be correlate=
d in various ways"?
Which data? YANG modules, YANG objects, object instances, from different YA=
NG server, etc.
I guess I miss a sentence or two regarding this "correlation" obj=
ective and which guidelines this section=20
is going to provide to "authors and reviewers of Standards Track speci=
fications containing YANG data model modules".
Note: I read that section multiple times.

- section 4.22
   It is sometimes useful to separate configuration data and operational
   state, so that they do not not even share the exact same naming
   characteristics.  The correlation between configuration the
   operational state that is affected by changes in configuration is a
   complex problem.  There may not be a simple 1:1 relationship between
   a configuration data node and an operational state node.  Further
   work is needed in YANG to clarify this relationship.  Protocol work
   may also be needed to allow a client to retrieve this type of
   information from a server.  At this time the best practice is to
   clearly document any relationship to other data structures in the
   "description" statement.

Isn't it clarified with NMDA. It's not inline with 4.23.2, which sa=
ys:
=09
   Designers SHOULD describe and justify any NMDA exceptions in detail,
   such as the use of separate subtrees and/or separate leafs.=20

... and I guess confusing in light of the real guidelines in 4.23.3
Btw, why is this paragraph in 4.22 and not in 4.23?=20

- section 4.23

	Operational state is now modeled using YANG according to new NMDA,

Please add a reference to the draft.

- section 4.26 "YANG 1.1 Guidelines"
I'm confused by the title. The entire document is about 1.1, right?
I guess you want to express something such as "YANG 1.1 specific Const=
ructs Guidelines"

- section 4.26.1=20


    

      
 Multiple revisions of th=
e same module can be imported, provided that
 different prefixes are used.


    

    
Reading https://tools.ietf.org/html/rfc=
7950#section-7.1.5. Any contradiction?
Then reading:
   This MAY be done if the authors can
   demonstrate that the "avoided" definitions from the most recen=
t of
   the multiple revisions are somehow broken or harmful to
   interoperability.=20

"avoided" definitions?=20
I simply don't understand this sentence.


    
- section 4.26.4
   The NETCONF Access Control Model (NACM) [RFC6536] does not support
   parameter access control for RPC operations.

Let's use draft-ietf-netconf-rfc6536bis


- Appendix B

   YANG Module Registry: Register the YANG module name, prefix,
         namespace, and RFC number, according to the rules specified
         in [RFC7950].

I guess this is [RFC6020] in this case. Indeed the "YANG Module Names&=
quot; registry is specified in RFC6020/.
See for example https://tools.ietf.org/html/draft-ietf-netmod-rfc72=
23bis-03#section-6

- Appendix B
References -- verify that the references are properly divided
      between normative and informative references, that RFC 2119 is
      included as a normative reference if the terminology defined
      therein is used in the document

Refer to RFC8174

- Appendix B (and maybe some more text somewhere else.
To refer to Tom Petch latest email to NETMOD, we should need a few words ab=
out:
  If a YANG module has a Reference or Description clause specifying an
  I-D, and the I-D is listed as an Informative Reference.

Regards, Benoit



    
 

  



_______________________________________________

netmod mailing list

netmod@ietf.org

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




--001a114b0fcedcf0f00565b1af6c--


From nobody Wed Feb 21 04:41:42 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 759E2124217 for ; Wed, 21 Feb 2018 04:41:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SwOQNDG4CjvT for ; Wed, 21 Feb 2018 04:41:39 -0800 (PST)
Received: from alln-iport-2.cisco.com (alln-iport-2.cisco.com [173.37.142.89]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FE8D1200FC for ; Wed, 21 Feb 2018 04:41:39 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11836; q=dns/txt; s=iport; t=1519216899; x=1520426499; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=9f4wxh4/JaSQgnHxmaAgF5uzGty3M5o66UfyC8WeMe4=; b=iRlegzPVvEITZOUKO/PQZaS+NnCwFrndCRp3isD8GxRXCcscvwTRUDRB xIzmSHiOZDkfET5xDqH527IHhJrNEBVCw6f8w48NZIvlY4XZaGNeMfvVY +YNjKqn+TesZtYD+p+0hJiYq/iIp+9tSqErZWPZ2vzADSdGGYfe1jN23o Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CVAQAoaI1a/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPZnAog2iKJY12gVALJ4EXkG6FXBSCAgoYAQqEQk8CgnZUGAE?= =?us-ascii?q?CAQEBAQEBAmsohSQBAQQBASFLBAcQCxgnAwICJx8RBg0GAgEBih8QqhaCJyaEW?= =?us-ascii?q?oN9ghMBAQEBAQEBAQEBAQEBAQEBAQEBAQEdhQ6CJ4FXgWcpDIJ5gzABAQIBgTY?= =?us-ascii?q?FARIBCYMtgmUFklaBFJBRCYgnhAiJXoIgZ4VCg3Emh2WOCYIBiByBPB85JTtxM?= =?us-ascii?q?xoIGxUZIYJDCYISgnkjNwEBikiCPgEBAQ?=
X-IronPort-AV: E=Sophos; i="5.46,543,1511827200"; d="scan'208,217"; a="73797887"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by alln-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2018 12:41:38 +0000
Received: from [10.82.217.145] (rtp-vpn3-399.cisco.com [10.82.217.145]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w1LCe2us021277; Wed, 21 Feb 2018 12:41:26 GMT
To: Andy Bierman 
Cc: NETMOD Working Group 
References:  
From: Benoit Claise 
Message-ID: <4b24af79-6fe5-8e4a-2921-b5505a976bbd@cisco.com>
Date: Wed, 21 Feb 2018 07:39:43 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/alternative; boundary="------------CFCFB7436EEB27DDD7DFE2E8"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-rfc6087bis Part 2
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 12:41:41 -0000

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

Thank you Andy.
Sending to IETF LC now.

Regards, Benoit
> Hi,
>
> I think draft-18 addresses all these issues.
> A guideline about key leaf order has also been added.
>
> Andy
>
>
> On Wed, Feb 14, 2018 at 7:11 AM, Benoit Claise  > wrote:
>
>     Dear all,
>
>     Here is the part 2 of the AD review, from section 4.21 on.
>
>     Regarding the part 1, thanks Andy for addressing all comments in version 17.
>
>     - section 4.22 "Data Correlation.
>
>     Not sure what you mean by the section title and "Data can be correlated in various ways"?
>     Which data? YANG modules, YANG objects, object instances, from different YANG server, etc.
>     I guess I miss a sentence or two regarding this "correlation" objective and which guidelines this section
>     is going to provide to "authors and reviewers of Standards Track specifications containing YANG data model modules".
>     Note: I read that section multiple times.
>
>     - section 4.22
>         It is sometimes useful to separate configuration data and operational
>         state, so that they do not not even share the exact same naming
>         characteristics.  The correlation between configuration the
>         operational state that is affected by changes in configuration is a
>         complex problem.  There may not be a simple 1:1 relationship between
>         a configuration data node and an operational state node.  Further
>         work is needed in YANG to clarify this relationship.  Protocol work
>         may also be needed to allow a client to retrieve this type of
>         information from a server.  At this time the best practice is to
>         clearly document any relationship to other data structures in the
>         "description" statement.
>
>     Isn't it clarified with NMDA. It's not inline with 4.23.2, which says:
>     	
>         Designers SHOULD describe and justify any NMDA exceptions in detail,
>         such as the use of separate subtrees and/or separate leafs.
>
>     ... and I guess confusing in light of the real guidelines in 4.23.3
>     Btw, why is this paragraph in 4.22 and not in 4.23?
>
>     - section 4.23
>
>     	Operational state is now modeled using YANG according to new NMDA,
>
>     Please add a reference to the draft.
>
>     - section 4.26 "YANG 1.1 Guidelines"
>     I'm confused by the title. The entire document is about 1.1, right?
>     I guess you want to express something such as "YANG 1.1 specific Constructs Guidelines"
>
>     - section 4.26.1
>
>           Multiple revisions of the same module can be imported, provided that
>           different prefixes are used.
>
>     Readinghttps://tools.ietf.org/html/rfc7950#section-7.1.5
>     . Any contradiction?
>     Then reading:
>         This MAY be done if the authors can
>         demonstrate that the "avoided" definitions from the most recent of
>         the multiple revisions are somehow broken or harmful to
>         interoperability.
>
>     "avoided" definitions?
>     I simply don't understand this sentence.
>
>     - section 4.26.4
>         The NETCONF Access Control Model (NACM) [RFC6536 ] does not support
>         parameter access control for RPC operations.
>
>     Let's use draft-ietf-netconf-rfc6536bis
>
>
>     - Appendix B
>
>         YANG Module Registry: Register the YANG module name, prefix,
>               namespace, and RFC number, according to the rules specified
>               in [RFC7950 ].
>
>     I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" registry is specified in RFC6020/.
>     See for examplehttps://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6
>     
>
>     - Appendix B
>     References -- verify that the references are properly divided
>            between normative and informative references, thatRFC 2119   is
>            included as a normative reference if the terminology defined
>            therein is used in the document
>
>     Refer to RFC8174
>
>     - Appendix B (and maybe some more text somewhere else.
>     To refer to Tom Petch latest email to NETMOD, we should need a few words about:
>        If a YANG module has a Reference or Description clause specifying an
>        I-D, and the I-D is listed as an Informative Reference.
>
>     Regards, Benoit
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org 
>     https://www.ietf.org/mailman/listinfo/netmod
>     
>
>


--------------CFCFB7436EEB27DDD7DFE2E8
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit


  
    
  
  
    
Thank you Andy.

      Sending to IETF LC now.

      

      Regards, Benoit

    

    

      
      
Hi,
        


        

        
I think draft-18 addresses all these issues.

        
A guideline about key leaf order has also been added.

        


        

        
Andy

        


        

      

      


        
On Wed, Feb 14, 2018 at 7:11 AM, Benoit
          Claise <bclaise@cisco.com>
          wrote:

          

            

              
Dear all,

Here is the part 2 of the AD review, from section 4.21 on.

Regarding the part 1, thanks Andy for addressing all comments in version 17.

- section 4.22 "Data Correlation.

Not sure what you mean by the section title and "Data can be correlated in various ways"?
Which data? YANG modules, YANG objects, object instances, from different YANG server, etc.
I guess I miss a sentence or two regarding this "correlation" objective and which guidelines this section 
is going to provide to "authors and reviewers of Standards Track specifications containing YANG data model modules".
Note: I read that section multiple times.

- section 4.22
   It is sometimes useful to separate configuration data and operational
   state, so that they do not not even share the exact same naming
   characteristics.  The correlation between configuration the
   operational state that is affected by changes in configuration is a
   complex problem.  There may not be a simple 1:1 relationship between
   a configuration data node and an operational state node.  Further
   work is needed in YANG to clarify this relationship.  Protocol work
   may also be needed to allow a client to retrieve this type of
   information from a server.  At this time the best practice is to
   clearly document any relationship to other data structures in the
   "description" statement.

Isn't it clarified with NMDA. It's not inline with 4.23.2, which says:
	
   Designers SHOULD describe and justify any NMDA exceptions in detail,
   such as the use of separate subtrees and/or separate leafs. 

... and I guess confusing in light of the real guidelines in 4.23.3
Btw, why is this paragraph in 4.22 and not in 4.23? 

- section 4.23

	Operational state is now modeled using YANG according to new NMDA,

Please add a reference to the draft.

- section 4.26 "YANG 1.1 Guidelines"
I'm confused by the title. The entire document is about 1.1, right?
I guess you want to express something such as "YANG 1.1 specific Constructs Guidelines"

- section 4.26.1 


              

                
 Multiple revisions of the same module can be imported, provided that
 different prefixes are used.


              

              
Reading https://tools.ietf.org/html/rfc7950#section-7.1.5. Any contradiction?
Then reading:
   This MAY be done if the authors can
   demonstrate that the "avoided" definitions from the most recent of
   the multiple revisions are somehow broken or harmful to
   interoperability. 

"avoided" definitions? 
I simply don't understand this sentence.


              
- section 4.26.4
   The NETCONF Access Control Model (NACM) [RFC6536] does not support
   parameter access control for RPC operations.

Let's use draft-ietf-netconf-rfc6536bis


- Appendix B

   YANG Module Registry: Register the YANG module name, prefix,
         namespace, and RFC number, according to the rules specified
         in [RFC7950].

I guess this is [RFC6020] in this case. Indeed the "YANG Module Names" registry is specified in RFC6020/.
See for example https://tools.ietf.org/html/draft-ietf-netmod-rfc7223bis-03#section-6

- Appendix B
References -- verify that the references are properly divided
      between normative and informative references, that RFC 2119 is
      included as a normative reference if the terminology defined
      therein is used in the document

Refer to RFC8174

- Appendix B (and maybe some more text somewhere else.
To refer to Tom Petch latest email to NETMOD, we should need a few words about:
  If a YANG module has a Reference or Description clause specifying an
  I-D, and the I-D is listed as an Informative Reference.

Regards, Benoit



              
 

            

            

            _______________________________________________

            netmod mailing list

            netmod@ietf.org

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

            

          

        

        

      

    

    

  


--------------CFCFB7436EEB27DDD7DFE2E8--


From nobody Wed Feb 21 07:02:55 2018
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 D7B2F1270AB; Wed, 21 Feb 2018 07:02:49 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: The IESG 
To: "IETF-Announce" 
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
CC: bclaise@cisco.com, netmod-chairs@ietf.org, kwatsen@juniper.net, netmod@ietf.org, draft-ietf-netmod-rfc6087bis@ietf.org
Reply-To: ietf@ietf.org
Sender: 
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-ID: <151922536983.9716.5853511976478702830.idtracker@ietfa.amsl.com>
Date: Wed, 21 Feb 2018 07:02:49 -0800
Archived-At: 
Subject: [netmod] Last Call:  (Guidelines for Authors and Reviewers of YANG Data Model Documents) to Best Current Practice
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 15:02:50 -0000

The IESG has received a request from the Network Modeling WG (netmod) to
consider the following document: - 'Guidelines for Authors and Reviewers of
YANG Data Model Documents'
   as Best Current Practice

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2018-03-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


   This memo provides guidelines for authors and reviewers of Standards
   Track specifications containing YANG data model modules.  Applicable
   portions may be used as a basis for reviews of other YANG data model
   documents.  Recommendations and procedures are defined, which are
   intended to increase interoperability and usability of Network
   Configuration Protocol (NETCONF) and RESTCONF protocol
   implementations that utilize YANG data model modules.  This document
   obsoletes RFC 6087.




The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-netmod-rfc6087bis/ballot/


No IPR declarations have been submitted directly on this I-D.


The document contains these normative downward references.
See RFC 3967 for additional information: 
    rfc6021: Common YANG Data Types (Proposed Standard - IETF stream)
    rfc7950: The YANG 1.1 Data Modeling Language (Proposed Standard - IETF stream)
    rfc4741: NETCONF Configuration Protocol (Proposed Standard - IETF stream)
    rfc4742: Using the NETCONF Configuration Protocol over Secure SHell (SSH) (Proposed Standard - IETF stream)




From nobody Wed Feb 21 12:37:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA1912DA00; Wed, 21 Feb 2018 12:37:03 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level: 
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IUqJskvJUtt0; Wed, 21 Feb 2018 12:37:02 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E115A12DA1D; Wed, 21 Feb 2018 12:37:01 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1808; q=dns/txt; s=iport; t=1519245421; x=1520455021; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=WXNGGiIfiNCdrGywNQVNJQUf/9bX4u82iohtJCX5KOo=; b=XDjD5Dq8WY3+X8UMDd8hnDc5/4b6jMEacEEBzq25g3Iljh2xMreLUSCs vMtL5U/b5IoVCcvqMT7Sfk9p5gvuKdiphBFQm2wn/39m7ONBuWCVlAi3y H/YoGpl2pb3Mpt8NDuwXUVnOG7gNQFejkHjYCW88NR6KjxiZIjFbm7TLv 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BHAQAH2I1a/4wNJK1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYNPgVYyg16KJY14ggKBF5ZKghYKhTQCGoJeVBgBAgEBAQEBAQJ?= =?us-ascii?q?rKIUkAQQBIxFFEAIBCBoCJgICAjAVEAIEAQ2KIAiqe4IniHuCEwEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAR2BD4QCgieBV4IQgwWIOjGCNAWkOwkClguCIIpAh2WLGYx?= =?us-ascii?q?gAhEZAYE7AR85gVFwFWQBghmEdYxzgRkBAQE?=
X-IronPort-AV: E=Sophos;i="5.47,375,1515456000"; d="scan'208";a="73489533"
Received: from alln-core-7.cisco.com ([173.36.13.140]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2018 20:37:00 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-7.cisco.com (8.14.5/8.14.5) with ESMTP id w1LKaxt9018594 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Feb 2018 20:36:59 GMT
Received: from xch-rcd-006.cisco.com (173.37.102.16) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 21 Feb 2018 14:36:59 -0600
Received: from xch-rcd-006.cisco.com ([173.37.102.16]) by XCH-RCD-006.cisco.com ([173.37.102.16]) with mapi id 15.00.1320.000; Wed, 21 Feb 2018 14:36:59 -0600
From: "Gary Wu (garywu)" 
To: Yaron Sheffer , "Clyde Wildes (cwildes)" 
CC: "draft-ietf-netmod-syslog-model.all@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
Thread-Index: AQHTqcT/Wj6TPTms9Eu/1STZVbhb16OsuqUAgAJ3uQA=
Date: Wed, 21 Feb 2018 20:36:59 +0000
Message-ID: 
References: <151896425742.27914.9664814474838013064@ietfa.amsl.com> <6E582464-6EDB-4D55-9E8B-BEC68929DF9A@cisco.com> <4694018c-0be5-e78c-38ed-8745da01d019@gmail.com>
In-Reply-To: <4694018c-0be5-e78c-38ed-8745da01d019@gmail.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.154.131.51]
Content-Type: text/plain; charset="utf-8"
Content-ID: <6F6AA6C010300849A02D2268154E6B88@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 20:37:03 -0000

ICAgID4gICAgICBTZWN1cml0eSBDb21tZW50cw0KICAgID4gICAgICANCiAgICA+ICAgICAgKiBJ
IHRoaW5rIGFsbW9zdCBhbGwgd3JpdGFibGUgZGF0YSBub2RlcyBoZXJlIGFyZSBzZW5zaXRpdmUs
IGJlY2F1c2UgYSBuZXR3b3JrDQogICAgPiAgICAgIGF0dGFja2VyJ3MgZmlyc3QgbW92ZSBpcyB0
byBibG9jayBhbnkgbG9nZ2luZyBvbiB0aGUgaG9zdCwgYW5kIG1hbnkgb2YgdGhlIGRhdGENCiAg
ICA+ICAgICAgbm9kZXMgaGVyZSBjYW4gYmUgdXNlZCBmb3IgdGhpcyBwdXJwb3NlLg0KICAgID4g
DQogICAgPiBbY2x3MV0gSSB3aWxsIHJld29yZCB0aGUgc2VjdXJpdHkgc2VjdGlvbiB0byBpbmNs
dWRlIGFsbCB3cml0ZWFibGUgbm9kZXMgYXMgc2Vuc2l0aXZlLg0KICAgID4gDQogICAgPiAgICAg
ICogUmU6IHJlYWRhYmxlIGRhdGEgbm9kZXMsIEknbSBub3QNCiAgICA+ICAgICAgc3VyZSB3aGlj
aCBhcmUgc2Vuc2l0aXZlLCBhbmQgdGhlIGRvY3VtZW50IHNob3VsZCBnaXZlIGFuIGV4YW1wbGUg
b3IgdHdvIHJhdGhlcg0KICAgID4gICAgICB0aGFuIGp1c3Qgc2F5ICJzb21lIi4gT3RoZXJ3aXNl
IHRoZSBzZWN1cml0eSBhZHZpY2UgaXMgbm90IGFjdGlvbmFibGUuIE9uZQ0KICAgID4gICAgICBl
eGFtcGxlOiAicmVtb3RlIiBzZWN0aW9ucyBsZWFrIGluZm9ybWF0aW9uIGFib3V0IG90aGVyIGhv
c3RzIGluIHRoZSBuZXR3b3JrLg0KICAgID4gDQogICAgPiBbY2x3MV0gVGhpcyB0ZXh0IHdhcyBs
aWZ0ZWQgZnJvbSBhbm90aGVyIG1vZGVsLiBJIHdpbGwgcmV2aWV3IHRoZSByZWFkYWJsZSBub2Rl
cyBhbmQgdXBkYXRlLg0KICAgID4gDQogICAgPiAgICAgICogV3JpdGUgb3BlcmF0aW9ucy4uLiBj
YW4gaGF2ZSBhIG5lZ2F0aXZlIGVmZmVjdCBvbiBuZXR3b3JrIG9wZXJhdGlvbnMuIC0gSSB3b3Vs
ZA0KICAgID4gICAgICBhZGQgImFuZCBvbiBuZXR3b3JrIHNlY3VyaXR5IiwgYmVjYXVzZSBsb2dz
IGFyZSBvZnRlbiB1c2VkIHRvIGRldGVjdCBzZWN1cml0eQ0KICAgID4gICAgICBicmVhY2hlcy4N
CiAgICA+IA0KICAgID4gW2NsdzFdIEkgd2lsbCBhZGQgdGhpcyBwaHJhc2UuDQogICAgPiANCg0K
VGhlIGZhY3QgdGhhdCB0aGUgc3lzbG9nIGRhdGEgbm9kZXMgYXJlIHdyaXRlLXNlbnNpdGl2ZSBj
YW4gYmUgbWFkZSBleHBsaWNpdCBpbg0KdGhlIG1vZGVsIGJ5IG1ha2luZyB0aGUgd2hvbGUgY29u
ZmlndXJhdGlvbiB0cmVlIG5hY206ZGVmYXVsdC1kZW55LXdyaXRlLCBhbmQNCm1ha2luZyByZWFk
LXNlbnNpdGl2ZSBzdWJ0cmVlcyBuYWNtOmRlZmF1bHQtZGVueS1hbGwuDQoNClRoYW5rcywNCkdh
cnkgV3UNCg0K


From nobody Wed Feb 21 13:15:21 2018
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 6469F126CE8; Wed, 21 Feb 2018 13:15:20 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: internet-drafts@ietf.org
To: 
Cc: netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151924772036.22729.5323417628125135644@ietfa.amsl.com>
Date: Wed, 21 Feb 2018 13:15:20 -0800
Archived-At: 
Subject: [netmod] I-D Action: draft-ietf-netmod-syslog-model-22.txt
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 21:15:20 -0000

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Network Modeling WG of the IETF.

        Title           : A YANG Data Model for Syslog
    Configuration
        Authors         : Clyde Wildes
                          Kiran Koushik
	Filename        : draft-ietf-netmod-syslog-model-22.txt
	Pages           : 34
	Date            : 2018-02-21

Abstract:
   This document defines a YANG data model for the configuration of a
   syslog process.  It is intended this model be used by vendors who
   implement syslog in their systems.

   The YANG model in this document conforms to the Network Management
   Datastore Architecture defined in [draft-ietf-netmod-revised-
   datastores].


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-netmod-syslog-model/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-netmod-syslog-model-22
https://datatracker.ietf.org/doc/html/draft-ietf-netmod-syslog-model-22

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-netmod-syslog-model-22


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

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


From nobody Wed Feb 21 13:21:33 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C531F124BFA for ; Wed, 21 Feb 2018 13:21:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.531
X-Spam-Level: 
X-Spam-Status: No, score=-14.531 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZQA7Dp0r8NBO for ; Wed, 21 Feb 2018 13:21:29 -0800 (PST)
Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB99212420B for ; Wed, 21 Feb 2018 13:21:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=4508; q=dns/txt; s=iport; t=1519248088; x=1520457688; h=from:to:cc:subject:date:message-id:references: in-reply-to:content-id:content-transfer-encoding: mime-version; bh=1WSbc5LF4QX29DDnnHQbxRIA0OYxBcqhYvpniK8AbDg=; b=ijovn0YPqQAuQvG1gptrCNltfJP/SKm24elNrWEX/Fjf0Ook4+yWYiTn 37e4SIj+GCkX8yAmgN0P5sxjYJ5n/qiR5fgoggujNiILL5O8EV3SEDERC QC7igIIAcF+LWHWd23F9KrMe6j4M72AHQf/iNYQR+HNWAsA5Z1kq11Jgr g=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0BIAQBi4o1a/40NJK1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPZnAoCoNeiiWNd4ICgReWShSCAgoYC4RCTwIagl5UGAE?= =?us-ascii?q?CAQEBAQEBAmsohSMBAQEDAQEBIRE6CxACAQgOBAYCAiMDAgICJQsUAQIOAgQ?= =?us-ascii?q?BDQUbigAIEKpzgieIeYITAQEBAQEBAQEBAQEBAQEBAQEBAQEBHYEPhAKCJ4F?= =?us-ascii?q?XgWcpgwWDMAEBgTmDTzGCNAWKcplJCQKIJY1mDoISZ4VCi3yXeQIRGQGBOwE?= =?us-ascii?q?fOYFRcBU6KgGCGAmEbXiLe4EZAQEB?=
X-IronPort-AV: E=Sophos;i="5.47,375,1515456000"; d="scan'208";a="348368688"
Received: from alln-core-8.cisco.com ([173.36.13.141]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 21 Feb 2018 21:21:28 +0000
Received: from XCH-ALN-013.cisco.com (xch-aln-013.cisco.com [173.36.7.23]) by alln-core-8.cisco.com (8.14.5/8.14.5) with ESMTP id w1LLLSoV009559 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 21 Feb 2018 21:21:28 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-013.cisco.com (173.36.7.23) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 21 Feb 2018 15:21:27 -0600
Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1320.000; Wed, 21 Feb 2018 15:21:27 -0600
From: "Clyde Wildes (cwildes)" 
To: Kent Watsen , "t.petch" , "Yaron Sheffer" , Ron Bonica 
CC: NETMOD Working Group 
Thread-Topic: [netmod] AD review of draft-ietf-netmod-syslog-model-20
Thread-Index: AQHTpZZfUtsO+32u9kKn7+BDeXhjPqOklbWAgAj1UFmAAGiiAIAB2Z6A
Date: Wed, 21 Feb 2018 21:21:27 +0000
Message-ID: 
References:  <922E608D-951A-459A-B515-B53834C805C1@juniper.net> <022001d3aa6a$c31895e0$4001a8c0@gateway.2wire.net> 
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.154.131.4]
Content-Type: text/plain; charset="utf-8"
Content-ID: <5FE70F1397E9AE419356C55B36F2C8A6@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 21 Feb 2018 21:21:31 -0000

S2VudCwgVG9tLCBZYXJvbiwgYW5kIFJvbiwNCg0KQSBuZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQt
aWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsIGhhcyBiZWVuIHB1Ymxpc2hlZCB0aGF0IGFkZHJlc3Nl
cyB5b3VyIGNvbmNlcm5zLg0KDQpUaGFua3MsDQoNCkNseWRlDQoNCk9uIDIvMjAvMTgsIDk6MDYg
QU0sICJuZXRtb2Qgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuIiA8bmV0bW9kLWJvdW5jZXNAaWV0
Zi5vcmcgb24gYmVoYWxmIG9mIGt3YXRzZW5AanVuaXBlci5uZXQ+IHdyb3RlOg0KDQogICAgDQog
ICAgDQogICAgDQogICAgPiBLZW50DQogICAgPiANCiAgICA+IFlvdSBpbGx1c3RyYXRlIGJlYXV0
aWZ1bGx5IHRoZSBwcm9ibGVtIEkgd291bGQgbGlrZSBhIHNvbHV0aW9uIHRvLg0KICAgID4NCiAg
ICA+IFRoZSBjdXJyZW50IHRoaW5raW5nIEFGQUlDVCBpcyB0aGF0IHRyZWUtZGlhZ3JhbXMNCiAg
ICA+IHNob3VsZCBiZSBhbiBJbmZvcm1hdGl2ZSBSZWZlcmVuY2UuDQogICAgPg0KICAgID4gVGhl
cmVmb3JlLCB0aGUgUkZDIEVkaXRvciB3aWxsIG5vdCBob2xkIHB1YmxpY2F0aW9uIHVudGlsIGFu
IFJGQyBudW1iZXINCiAgICA+IGlzIGFzc2lnbmVkLg0KICAgID4gDQogICAgPiBUaGVyZWZvcmUs
IGEgbm90ZSBhc2tpbmcgdGhlIEktRCByZWZlcmVuY2UgdG8gYmUgdXBkYXRlZCB0byByZWZsZWN0
IHRoZQ0KICAgID4gYXNzaWduZWQgUkZDIG51bWJlciBpcyBudWxsIC0gdGhlIFJGQyBjYW4gYmUg
cHVibGlzaGVkIHdpdGggdGhlDQogICAgPiByZWZlcmVuY2UgYXMgYW4gaS1kIGFuZCBub3QgYXMg
YW4gUkZDIHdoaWNoIGlzIHdoYXQgSSBleHBlY3QgdGhlIFJGQw0KICAgID4gRWRpdG9yIHRvIGRv
Lg0KICAgID4gDQogICAgPiBRRUQNCiAgICANCiAgICANCiAgICBFeGNlcHQgSSBrbm93IHRoYXQg
dGhpcyBkcmFmdCB3aWxsIGJlIHN0dWNrIGluIE1JU1JFRiBzdGF0ZSBhbmQgdHJlZS1kaWFncmFt
cw0KICAgIHdpbGwgaW4gZmFjdCBiZSBhc3NpZ25lZCBhbiBSRkMgbnVtYmVyIGJ5IHRoZSB0aW1l
IHRoaXMgZHJhZnQgaXMgcHVibGlzaGVkLg0KICAgIA0KICAgIEsuDQogICAgDQogICAgDQogICAg
PiBOb3RlIHRoYXQgdGhpcyBpcyBub3QgdGhlIGNhc2Ugb2YgYSBOb3JtYXRpdmUgaS1kIHJlZmVy
ZW5jZSBiZWluZyBidXJpZWQNCiAgICA+IGluIHRoZSBZQU5HIG1vZHVsZSBhbmQgbm90IGJlaW5n
Lm5vdGljZWQgYnkgdGhlIFJGQyBFZGl0b3I7IHRoYXQgcHJvYmxlbQ0KICAgID4gSSBhbSBjb250
ZW50IHdpdGguDQogICAgPg0KICAgID4NCiAgICA+VG9tIFBldGNoDQogICAgDQogICAgDQogICAg
DQogICAgDQogICAgDQogICAgDQogICAgDQogICAgDQogICAgPg0KICAgID4gUGxlYXNlIGFsc28g
YWRkcmVzcyB0aGVzZSBpc3N1ZXMgd2hlbiBwb3N0aW5nIC0yMSB0byBhZGRyZXNzIEJlbm9pdCdz
DQogICAgaXNzdWVzLiAgUGxlYXNlIHBvc3QgLTIxIEFTQVAgYXMgQmVub2l0IGhhcyBhbHJlYWR5
IHBsYWNlZCB0aGlzIGRyYWZ0IG9uDQogICAgdGhlIElFU0cgdGVsZWNoYXQgaW4gYSBjb3VwbGUg
d2Vla3MuDQogICAgPg0KICAgID4gVGhhbmtzLA0KICAgID4gS2VudCAvLyBzaGVwaGVyZA0KICAg
ID4NCiAgICA+DQogICAgPiBPbiAyLzE0LzE4LCA4OjE4IEFNLCAibmV0bW9kIG9uIGJlaGFsZiBv
ZiBCZW5vaXQgQ2xhaXNlIg0KICAgIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0
bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBvZg0KICAgIGJjbGFpc2VAY2lzY28uY29t
PG1haWx0bzpiY2xhaXNlQGNpc2NvLmNvbT4+IHdyb3RlOg0KICAgID4NCiAgICA+IERlYXIgYWxs
LA0KICAgID4NCiAgICA+IC0gdGhlIGRyYWZ0IGlzIE5NREEgY29tcGxpYW50LCByaWdodD8gSXQg
c2hvdWxkIGJlIG1lbnRpb25lZC4NCiAgICA+IEV4OiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIz
YmlzLTAzLCBpbiB0aGUgYWJzdHJhY3QgYW5kIGludHJvDQogICAgPg0KICAgID4gICAgVGhlIFlB
TkcgbW9kZWwgaW4gdGhpcyBkb2N1bWVudCBjb25mb3JtcyB0byB0aGUgTmV0d29yayBNYW5hZ2Vt
ZW50DQogICAgPg0KICAgID4gICAgRGF0YXN0b3JlIEFyY2hpdGVjdHVyZSBkZWZpbmVkIGluDQog
ICAgSS1ELmlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy4NCiAgICA+DQogICAgPg0KICAg
ID4gLSBBcyBtZW50aW9uZWQgaW4gdGhlIHdyaXRldXAsIFtJLUQuaWV0Zi1uZXRtb2QteWFuZy10
cmVlLWRpYWdyYW1zXQ0KICAgIHNob3VsZCBiZSBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UsIG5v
dCBub3JtYXRpdmUuDQogICAgPg0KICAgID4gLSBFZGl0b3JpYWw6DQogICAgPiBPTEQ6DQogICAg
PiBUaGlzIGRyYWZ0IGFkZHJlc3NlcyB0aGUgY29tbW9uIGxlYWZzDQogICAgPiBORVc6DQogICAg
PiBUaGlzIGRvY3VtZW50IGFkZHJlc3NlcyB0aGUgY29tbW9uIGxlYWZzDQogICAgPg0KICAgID4g
UGxlYXNlIHB1Ymxpc2ggYSBuZXcgdmVyc2lvbiBhc2FwLg0KICAgID4gSW4gdGhlIG1lYW4gdGlt
ZSwgSSdtIHNlbmRpbmcgdGhpcyBkcmFmdCB0byBJRVRGIExDLg0KICAgID4NCiAgICA+IFJlZ2Fy
ZHMsIEJlbm9pdA0KICAgID4NCiAgICA+DQogICAgPg0KICAgIA0KICAgIA0KICAgIC0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLQ0KICAgIC0tLS0tLS0tDQogICAgDQogICAgDQogICAgPiBfX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KICAgID4gbmV0bW9kIG1haWxpbmcgbGlz
dA0KICAgID4gbmV0bW9kQGlldGYub3JnDQogICAgPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zw
b2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZv
X25ldG1vZCZkPUR3SUNhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhj
V3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Y0o3
TVZuUVZjMWhneHBWRjdvWWlWbjZSYm0tUWYyZER5cmZZaEwtczlpbyZzPXUwSG45R2tPLUIwalVH
bTFNbklRNHg0QWdJWk5YSEJJYVpoVFBtdDNkQzgmZT0NCiAgICA+DQogICAgDQogICAgDQogICAg
DQogICAgX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCiAg
ICBuZXRtb2QgbWFpbGluZyBsaXN0DQogICAgbmV0bW9kQGlldGYub3JnDQogICAgaHR0cHM6Ly93
d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QNCiAgICANCg0K


From nobody Thu Feb 22 08:18:49 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1020B12D7E2 for ; Thu, 22 Feb 2018 08:18:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_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 VVPwmHYyy6NQ for ; Thu, 22 Feb 2018 08:18:45 -0800 (PST)
Received: from gproxy2-pub.mail.unifiedlayer.com (gproxy2-pub.mail.unifiedlayer.com [69.89.18.3]) (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 DCA3912741D for ; Thu, 22 Feb 2018 08:18:45 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy2.mail.unifiedlayer.com (Postfix) with ESMTP id 87A231E07A8 for ; Thu, 22 Feb 2018 09:18:45 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id DsJh1x00r2SSUrH01sJk6F; Thu, 22 Feb 2018 09:18:45 -0700
X-Authority-Analysis: v=2.2 cv=M5g9E24s c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=9trkQO-fGp8CiU5gpf0A:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date: Message-ID:Cc:To:Subject:From:Sender:Reply-To:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=+9bK9CJ1tBotT/1Tpq7AqZ6WoRoRQmMpZWHmnwWNrjU=; b=wAaCc9EJ8UwNN4qR+8/+80M8Y7 7TuTmHwVXrnMngVv9oKyaTr0FpOEoIVqhMHZFEX797CMtAaJ26qLSOlJ0beJcypxPAGJAYbs+uERH OxJi0wMM1bJG1qBdbASk6k/cB;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:34954 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1eotZx-004HI4-Fz; Thu, 22 Feb 2018 09:18:41 -0700
From: Lou Berger 
To: NetMod WG 
Message-ID: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net>
Date: Thu, 22 Feb 2018 11:18:38 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1eotZx-004HI4-Fz
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:34954
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 16:18:47 -0000

Hi,

(I have a bunch of different roles WRT this work.  This mail is being 
sent as an individual - as chair, I fully support the previous chair 
statements on this draft.)

Chris and I have come up with a proposal on how to provide full NMDA as 
part the existing schema-mount module.  Our motivation was to enable 
full NMDA support with *minimal* change to the model and disruption to 
the LC'ed work.  The key NMDA limitation, with -08, that we are aiming 
to address is the ability to support different mounted schema in 
different datastores for non-inline mount points. (See more detailed 
description below if interested full nuances of limitations of -08)

What we came up with was  to simply add a (leaf)list to identify in 
which datastores a
schema-mount schema is valid/present. This is somewhat similar to YL-bis 
schema/module-set. Specifically we're proposing (see below for full tree 
below):

            +--ro schema* [name]
               +--ro name           string
ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}

This approach has the advantages of supporting different mounted schema 
in different DSes, working with both NMDA and non-NMDA implementations, 
supporting all of the extensively discussed features of schema mount 
(including recursive mounts), and having minor/scoped impact on all 
dependent work.  The main downside is that it isn't the most 
optimal/compact solution possible if we were to base this work on 
YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all 
perspectives, but it is what was agreed to as sufficient by those who 
contribute to the WG discussion.

In short, we see this as a solution to  addresses the raised last call 
issue with the minimal impact on -08 and dependent work -- which is what 
is appropriate given where we are in the process.

So our/my question really is:

     Is this a solution that you/all can live with?

Note: optimization, design preference and perfect alignment with use or 
YL-bis are not part of our question as we both don't think that is the 
right question given where we are in the WG process.

Lou (with ideas developed with Chris, and chair hat off)

======
Details -- for those who want
======
As background, my understanding/view is that the -08 version of the both 
NMDA and non-NMDA supporting implementations, but there are limitations 
in its NMDA applicability. Used with Yang Library, [rfc7895], only 
non-NMDA implementations can be supported.  When used with the revised 
Yang Library defined in [I.D.ietf-netconf-rfc7895bis-],  NMDA 
implementations  can be supported with certain limitations. 
Specifically, this document requires use of the now deprecated 
module-list grouping, and the same schema represented in schema list of 
the Schema Mount module MUST be used in all datastores.  Inline type 
mount points, which don't use the schema list,  can support different 
schema in different data stores not by instantiating the 
[I.D.ietf-netconf-rfc7895bis-] version of YANG library under the inline 
mount point.

     module: ietf-yang-schema-mount
         +--ro schema-mounts
            +--ro namespace* [prefix]
            |  +--ro prefix    yang:yang-identifier
            |  +--ro uri?      inet:uri
            +--ro mount-point* [module name]
            |  +--ro module        yang:yang-identifier
            |  +--ro name          yang:yang-identifier
            |  +--ro config?       boolean
            |  +--ro (schema-ref)?
            |     +--:(inline)
            |     |  +--ro inline?       empty
            |     +--:(use-schema)
            |        +--ro use-schema* [name]
            |           +--ro name
            |           |       -> /schema-mounts/schema/name
            |           +--ro parent-reference*   yang:xpath1.0
            +--ro schema* [name]
               +--ro name           string
ADD          +--ro datastore*	ds:datastore-ref {revised-datastores}
               +--ro module* [name revision]
               |  +--ro name                yang:yang-identifier
               |  +--ro revision            union
               |  +--ro schema?             inet:uri
               |  +--ro namespace           inet:uri
               |  +--ro feature*            yang:yang-identifier
               |  +--ro deviation* [name revision]
               |  |  +--ro name        yang:yang-identifier
               |  |  +--ro revision    union
               |  +--ro conformance-type    enumeration
               |  +--ro submodule* [name revision]
               |     +--ro name        yang:yang-identifier
               |     +--ro revision    union
               |     +--ro schema?     inet:uri
               +--ro mount-point* [module name]
                  +--ro module        yang:yang-identifier
                  +--ro name          yang:yang-identifier
                  +--ro config?       boolean
                  +--ro (schema-ref)?
                     +--:(inline)
                     |  +--ro inline?       empty
                     +--:(use-schema)
                        +--ro use-schema* [name]
                           +--ro name
                           |       -> /schema-mounts/schema/name
                           +--ro parent-reference*   yang:xpath1.0

We would expect that the revised-datastores feature would be used
(perhaps required) for any implementation that supports ietf-datastores
and yl-bis.

  


From nobody Thu Feb 22 09:08:11 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 693F712EAEA for ; Thu, 22 Feb 2018 09:08:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JWftvIocX3Lq for ; Thu, 22 Feb 2018 09:08:07 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0126.outbound.protection.outlook.com [104.47.2.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8993412D87C for ; Thu, 22 Feb 2018 09:08:06 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=334nYw9NVhtnmu+q+eCpuiNftKmDlxC5yuC6c3xA1dk=; b=B/iZ5GtqtRazfY150cZ4hWeD8Rz+zwL/1Qd2m5/OLRlQSCRAh5PI5gvnYca9eHBHbyATEXfn/zkl54Ppo2CbpdUw8fJOH4aFl64W3eGEyybOa033tMJ3XaFDDk5kZUBknSQPDMln6H8IJnxS2DC5M+nmd2+fT/iJIBC/Rqmx/V8=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.176.21.219) by VI1PR0701MB3008.eurprd07.prod.outlook.com (2603:10a6:800:87::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Thu, 22 Feb 2018 17:08:03 +0000
Message-ID: <070301d3abff$683091a0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Kent Watsen" , "NETMOD Working Group" 
References:  <922E608D-951A-459A-B515-B53834C805C1@juniper.net> <022001d3aa6a$c31895e0$4001a8c0@gateway.2wire.net> 
Date: Thu, 22 Feb 2018 16:49:51 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.176.21.219]
X-ClientProxiedBy: MRXP264CA0041.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::29) To VI1PR0701MB3008.eurprd07.prod.outlook.com (2603:10a6:800:87::22)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: 38260592-e49d-494a-bd4a-08d57a16d626
X-Microsoft-Antispam: UriScan:(219612443155931); BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:VI1PR0701MB3008; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 3:RXqkD2Jo2AV41LJzsdXuZZhtPEocmCIgc5Nhn+EvXnDGZUB7CS02hOri5nzKw3XgNufORZG3QhElF3+hfqZ4OYYBVg+3hI41XV4ajVYJUQx4x2QCIFbdU9OjPki6KLSGDXNWL3iL/JDWpxMXny04ujhnnKf4n25TNaLxdhW2O7kDy/RkGYRa8K+IKns9NO3xT/iFckkiDfqJGXEXROgzM9ytBh6tyjWS3twrT5Moj2z/s5DjdhobLSBTARt/7Q9/Dfk/puuSq1VCuGKecvrz9mTDnDZrOfuYlnyNcyIb9vY=; 25:3sqyu88e7OKry3BAoFV6TvcNZdSUuGiCEQVR5rTjJMn/JOQh6vvf+hilmVTSCskAIWc/WQC0CScrFZPjuWG2B88FYNSr0CVb4IF8Sy7+9fScPlSgmFzfOQEvtxEtYmJCQa45KZ1zNTDv6Nhp8ZtOtS+E36p83tcUBUAmBpBpWic2ZECLDBRNsWVZyg9pq9xiI3/iN1nBlrnPLZ1fLtswZ22UfvVMFFevLPveqIwXkC1iG5FR9qgPkfMbSS1CFZ7VknL5UDzjBO9de1d0j8vAeBdSPKUXSctfADYOfFHlipVQmAzzXa91c0hxQr3sbl8RPP5k2J4MYFH2b7YqRa1mZQ==; 31:Iv/vehGAkG9aTablEEzciZmA3yllk5qyKO32d5SzGdtsxa8KiCFqh4jdwiFj41scW//5nKPW4W346kAy+zziNmlx2uLnh7v8ruFTsi36+rp/g9enWw/w+xAGZIo+AmG/6iGXY2LTZ+YsEAWC3S8L6y0dTojeTkH1C8u99/+hlR3XnmAzIv0U9P7IjlLZ2k43Pt5Vzq9bHUCm/HV5gsFS2Odrre9plV2X3bLjBhGzaio=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3008:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(178726229863574)(10436049006162)(138986009662008)(219612443155931)(95692535739014);
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231101)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0701MB3008; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3008; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 4:eSVfSJmWN0Y3SoZ50eVfgEKVtQyCXLhiuzooKtWAKgnJrKacoi8C2Pt4Lgqn1qZ138JP4Ay+jAP/MaHwzXifRewhCUxk6xC4yWk1jr+PuGXArnfxnbaDjAu+Z2VlHXDm5uP93nxjuKW4uKs4TcINevx+A35WLxMd2Fl9yJyCa8bRhYGgkAh5gLh3RiNHUtIwH954YriaxFhD7NDSgfNftfjy3C4ksIeF4HHuDZKOxIyAGBH/bUKAtle/ahnQSZ/zPUwizbsCIs1qpsnXQbI3thDoNMOo+abINxFxc4KKGj77eG3r7QG8ncD0guI07qCMH+ffswudtikjnLYUmKDUZUc2PkWgW0fhbD8JbRnONHPDHcJlxu8O7zV2M03LK08ufzE+wj89VlTun36n0CB8BVOaann0YI+pbK/glJqDl2zHrN9zjBLtPcPb49inrHOM
X-Forefront-PRVS: 059185FE08
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(396003)(366004)(346002)(39860400002)(189003)(199004)(13464003)(305945005)(966005)(106356001)(8676002)(76176011)(50226002)(9686003)(81166006)(81156014)(25786009)(50466002)(44736005)(478600001)(316002)(6306002)(6486002)(575784001)(86362001)(62236002)(8666007)(14496001)(105586002)(5660300001)(7736002)(386003)(230700001)(52116002)(33896004)(6496006)(2486003)(53936002)(81686011)(1556002)(81816011)(23676004)(26005)(44716002)(186003)(16526019)(61296003)(8936002)(229853002)(6246003)(6666003)(1941001)(84392002)(47776003)(68736007)(66066001)(4720700003)(2906002)(110136005)(3846002)(93886005)(6116002)(97736004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3008; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjMwMDg7MjM6OWliQ1RFeDMxQmVLNVpSV25DZ2R3Vm5n?= =?utf-8?B?WVFUSDVTUGI3Z0h6bDhiME1aWmFNcWNuL0cxUnkrZTcydDhrQUpMUzJVcWZG?= =?utf-8?B?aEFBRVVkUU1EbVREbDEyRk1ZZSt6QnVNNlNOVWl5Qm14Z1AxN09UTWNkeWto?= =?utf-8?B?blZGQTFoNlBRWmlScUlLWTlJc0JHcVgrMFJzeUNEcWtudG9qUEtBYk9mdk93?= =?utf-8?B?dnBrUWwwMk9PTjB5aGdFOWpMVmlYQmM5cUphcDZ0T3ZtZWNiWUViSkMyWlp4?= =?utf-8?B?QVFGNTV0SDBYWmJDdnp4SFlWR2xiZG0wODAxOFhRT1Erd0NKayt2dkNrNGp2?= =?utf-8?B?b3JYNVlNUG5RcTNXa1Y5ekR6NDl1YmI5RnNMNnI3UEJnNGxHeWZaTHRueGo0?= =?utf-8?B?dm56Y1NvbUtTWWttOFBTNnpFek9QTnRHZS8wbldqb2ZLL0hmWHk2N3VFZVU3?= =?utf-8?B?b3FUanNUN0NQN1l6T0ZlbzkrbUFua2oxT2hPNWIxM1pmVkFtcDN2YWZGTDR2?= =?utf-8?B?UGFMVWdwU2hpUGViRW9SNHVHZndUQjZKbkVEd0Q4RHAxaHFGVkJ1Z21QOEtm?= =?utf-8?B?bk9aTzVIODQ2NXAvNzAvd05VeklSSllqOC9QWkRkUjdJb1FNN2VXU3VnUlM2?= =?utf-8?B?R0plUEh6Nm9sNWJwM1cyclpMQklCZlcxN2dVSFpxYytTbzZPUXM3ZGF5dE5n?= =?utf-8?B?TVJsMENNaDVZU0MrSkFBVDhyUDQyUUpteHJJWjNNZC83c1RUUkVNdWRNMHE4?= =?utf-8?B?VGJUODFpVHNveXJsckxRZ3NJdzZjN3QxYkwwVjEzOFFmd3RjanZkNy9VdDJw?= =?utf-8?B?UFpqUzZyczF1ODR0Mml0NEpOUzhscUJQczVmYS9WUFBqd1I5Z1dHbHQxclVk?= =?utf-8?B?R1VveFF0L0lUWkFtRE50a0ZiajI5eERGT0lFT21QeXN1UzdvN1cxZ0JWTldP?= =?utf-8?B?U1c0QWN6VFNrZ3JDYTdNR1gxQmRKNnVoZDFISVNocnIzTkVGVitmZ0dtajZP?= =?utf-8?B?RHpZc2xEZG5DV1RtcXl2YWJzWEtIRW5RZHp2bFJRTVVnR01WaFYrc2ROVHFZ?= =?utf-8?B?b0lrMklrSllSaVZzQlkrOUw3a2cwM3M5b2N2OWN2UkhVdDNjWUNwVEpwV3Vx?= =?utf-8?B?VFBhOUN1bVQ1Q1ZFemhmYUdKWWFuUDE1Sm9hQlBQTU45TGJXUVBPOE1xanNv?= =?utf-8?B?YndnZmdpb2VzSXhYM2grS1JodEFFVi94ZG9qbVFTUFNSZm90TUJ6cGtaUmxo?= =?utf-8?B?UkJueFlEQTRlVXNubUZuVTJyTWFleHlvWmRRZnMzc3ZWbHFmMERTWVcybWl3?= =?utf-8?B?eVBhQTBndHMxaXFPYm80NjBYV3NWOTZ4QTBvUTROTWJadHZWVm1Jdlc4ZHRv?= =?utf-8?B?bGxqY2pUMFdxZjQ4NzVSaGlSUWJvbElReGsxUDZRLzNBQS9DZUV3dDBJcE4w?= =?utf-8?B?bGx4SXkzQTN3T082QTBrcUdkMlBpRlV4eEY0dnpXa3RjcU9rUnFVMEVaUitH?= =?utf-8?B?UHhsb3Q4TzJZbkdmN0RiVWExODRFU0ZsY0hQTWxvMEczRnlPeGdVSWpGRFhm?= =?utf-8?B?TW1pbXh6dE0rbnhWYk8zcEZHdUpZd0NXSjg2emw3UHRwaFVDOVh0QUlZQlFN?= =?utf-8?B?QVJvU01DRWFsbzZvdDV0d2Nqd3hxZXRGR25FVUMwM2V0a3JHNk4rWVhHdm4x?= =?utf-8?B?LzMvZVNSa0Y4SEJIMFJhYTdMbmt6R3Nldys0ajJuaGtCSG9HdTlOZVJDa011?= =?utf-8?B?TkpjRHQ0TzN6WUtnVzhGZjRlWHUybzI0UktJZVJFek1wZzlGUzdhNWVSYm84?= =?utf-8?B?aVhlbXRiZ2k5V0t2ZE5rSC96WjY3MnFBR3NJaHhsc1dYWm5Xc0hxVUVmSjRY?= =?utf-8?B?cjUxNTV2dWFmYTlscTdpdnhoTjlFaC85L2ZweXB0bk1Od25sUUxEdmxVZUg1?= =?utf-8?B?VnBIWU1kb2Jkb2lTa2JUUUhFY3JMYW1xRE9ycEVYeWtYV05uSzhKQlVTYkRr?= =?utf-8?B?U29rVXo3SUtWZ0RXR1FaamdWTGlCTkZlclJ0S3ZBPT0=?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 6:QjHhMxTzo4QTn1hxFr9l3cqe3TWFq+WRpT5xFCIwjtpyG1KKnMNG8SpnOc8OCTO/87RcOHEeTlP9SaQpO7ePvhGuEXZQAShGTp/yuuKmtZiQVftLKRBJhVQjvtRigH+XIv/dmitS0lDaNARejpz0SkNGi9O58FY6Z8bi9JTLFxgdA/m2h+INOfLdw98Hn528eMfjVblF4xebE7BVzjDiYE1aH8GsHdq3OhpvPMR+UKgPH9XyBgtiWBbkErqaqs5zk+/CSFv5HJHNZD8qgr5Q63fTSoxIvJHyXNLRWkkn0oDZ+wTGu5MtOanGoYnCyB39U6otG39Ehg9a2fJE0Ic6MfiFm7owzgiWRjs0iUjdDgk=; 5:C+4Uqt0TLog4UZGfQucq9Q/FSN/zqQeszzIv6XUjjQ4rdOOkFV/Ms/dcZ6OYNkQFJdIKC9428wDT9hUMma6OwO+2CAh3zdJf769IxNvPhauAlZSisBNQXH3apRdq0+otX0c+9GoNjp64mW3QUeurLQXvEh1yn+retRuawWZTB+Q=; 24:k5CTn+EHkpij2SAhj4eXU+tckhZbpV0uO1yNmRvIGU3p4DX3IVfiABov2Z9wJgazRsFTwlkqqTdIPpm/CMxPxyUGc++7W21UFeM5OCMks5Q=; 7:zRK5CVWMpTTd2zU/TT5yECb/rLWonl1zzhuPEzEONepAVzsd7fg0lqtTpcq+b9z03hytDdRaH3r5tvQCsIvHfYTRySVb8ZyF2XviJSVdxJ/Erh2RX5VRV0zsRILzPVnhHnleDpYXVpHDcBURkvaFuWMVxmypvKHpUSoXnFbmCYbe2Os0UHu4rb5k/DsAykiOhYTFn4R/bYBoNRYovMWMd9jOCxr2euDyyhG0r+Ff9bcWFgoouFJhri/vYZHYzt45
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2018 17:08:03.9619 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: 38260592-e49d-494a-bd4a-08d57a16d626
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3008
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 17:08:09 -0000

----- Original Message -----
From: "Kent Watsen" 
To: "t.petch" ; "NETMOD Working Group"

Sent: Tuesday, February 20, 2018 5:06 PM
>
> > Kent
> >
> > You illustrate beautifully the problem I would like a solution to.
> >
> > The current thinking AFAICT is that tree-diagrams
> > should be an Informative Reference.
> >
> > Therefore, the RFC Editor will not hold publication until an RFC
number
> > is assigned.
> >
> > Therefore, a note asking the I-D reference to be updated to reflect
the
> > assigned RFC number is null - the RFC can be published with the
> > reference as an i-d and not as an RFC which is what I expect the RFC
> > Editor to do.
> >
> > QED
>
>
> Except I know that this draft will be stuck in MISREF state and
tree-diagrams
> will in fact be assigned an RFC number by the time this draft is
published.

Kent

Corner case:-)

You cannot know in general that drafts that appear as Informational
References and which are referenced from within a YANG module will be
published before the referencing I-D will be and so will have a RFC
number which can be inserted by the RFC Editor.

Tom Petch

> K.
>
>
> > Note that this is not the case of a Normative i-d reference being
buried
> > in the YANG module and not being.noticed by the RFC Editor; that
problem
> > I am content with.
> >
> >
> >Tom Petch
>
>
>
>
>
>
>
>
> >
> > Please also address these issues when posting -21 to address
Benoit's
> issues.  Please post -21 ASAP as Benoit has already placed this draft
on
> the IESG telechat in a couple weeks.
> >
> > Thanks,
> > Kent // shepherd
> >
> >
> > On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
>  on behalf of
> bclaise@cisco.com> wrote:
> >
> > Dear all,
> >
> > - the draft is NMDA compliant, right? It should be mentioned.
> > Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
> >
> >    The YANG model in this document conforms to the Network
Management
> >
> >    Datastore Architecture defined in
> I-D.ietf-netmod-revised-datastores.
> >
> >
> > - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
> should be an informative reference, not normative.
> >
> > - Editorial:
> > OLD:
> > This draft addresses the common leafs
> > NEW:
> > This document addresses the common leafs
> >
> > Please publish a new version asap.
> > In the mean time, I'm sending this draft to IETF LC.
> >
> > Regards, Benoit
> >
> >
> >
>
>
> ----------------------------------------------------------------------
--
> --------
>
>
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> >
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
n_listinfo_netmod&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI
&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=cJ7MVnQVc1hgxpVF7oYiVn6
Rbm-Qf2dDyrfYhL-s9io&s=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8&e=
> >
>
>
>
>


From nobody Thu Feb 22 09:08:17 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9156012D87C for ; Thu, 22 Feb 2018 09:08:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.92
X-Spam-Level: 
X-Spam-Status: No, score=-1.92 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=btconnect.onmicrosoft.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PvJKMcF1SpNJ for ; Thu, 22 Feb 2018 09:08:07 -0800 (PST)
Received: from EUR01-DB5-obe.outbound.protection.outlook.com (mail-db5eur01on0126.outbound.protection.outlook.com [104.47.2.126]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 42D9812D88C for ; Thu, 22 Feb 2018 09:08:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=btconnect.onmicrosoft.com; s=selector1-btconnect-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bKuYDfIx0XSGzbuV8WlIDZy8eZPz0FpwAMFFsSqnDls=; b=Nq9S+WvUkueoXfHF2AOoBsiIE71HfA4fv1ZFseSmhN1AREvBfKg6zhTydleDzojoggrQ96UdNOOPD/jcrIYDLoixkZLVFmiKhT+5eNgcIovULl0LnYhfmrhpJCAoAjloBnsmYOnilwXESMfQmXBJyrCg5HzE/4rLnuRikyybdg4=
Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=ietfc@btconnect.com; 
Received: from pc6 (86.176.21.219) by VI1PR0701MB3008.eurprd07.prod.outlook.com (2603:10a6:800:87::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Thu, 22 Feb 2018 17:08:04 +0000
Message-ID: <070401d3abff$68be79c0$4001a8c0@gateway.2wire.net>
From: "t.petch" 
To: "Clyde Wildes \(cwildes\)" , "Kent Watsen" 
Cc: "NETMOD Working Group" 
References:  <922E608D-951A-459A-B515-B53834C805C1@juniper.net> <022001d3aa6a$c31895e0$4001a8c0@gateway.2wire.net>  
Date: Thu, 22 Feb 2018 17:04:50 -0000
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Originating-IP: [86.176.21.219]
X-ClientProxiedBy: MRXP264CA0041.FRAP264.PROD.OUTLOOK.COM (2603:10a6:500:14::29) To VI1PR0701MB3008.eurprd07.prod.outlook.com (2603:10a6:800:87::22)
X-MS-PublicTrafficType: Email
X-MS-Office365-Filtering-Correlation-Id: ce02f3fb-9bc2-4192-ca72-08d57a16d6b5
X-Microsoft-Antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(8989060)(4534165)(4627221)(201703031133081)(201702281549075)(8990040)(5600026)(4604075)(2017052603307)(7193020); SRVR:VI1PR0701MB3008; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 3:4mkV4lVU5pXoxufJQ3lva39goYLwn2weRMhbn021uZQW2CMczOgixcx1jCE+P3bcd2ySSBJgloZhapcdVntabOBWydbSV5Ky1rJFmHZ2mLk1kUi81loR/Cp2nOxSpTJEZWHnmFLSlyI61ly+OqTbkuKpvkd3LRfvfWHpWlG2cmnhG2mqQdZPLIx+ysq76Az4JLJpLHTmv+ggXef6YDOikdwfyIIZ/qX8Y6UV8kh4BOUojOehKXzxtXhO5s2Gwwoo; 25:ZLnlHJC/Nt45wFwdPmbiZX2xDdPlgoG7y8Z3HVLT/2B6CqprQ91NHPn/n4didqgrfXSp+snic21JVgTY09VA3hIigV/xtOisFgWTq2FTO6kTWHTUlViH+m4+K3Jg7euzBruy+krwqafrktTXTXUNcLNJoESv4wnXIT9SYbfu/rvBiFvzQrIe3EIN/uIOkG2MffkB/f+p+rU6TykX3CykBu0XJqv4V+cfsUZTuoKGB1g7i1qvFAh/lH60r8ajnHEM+JElMhfF7n2f16F3Z8/Ignz7Limknj0Ldw1REGBkKR3EK4DAewOAwXlB95FKR1C5dKDrAXShmSDGmkPCwJ+BkQ==; 31:bKEf1MBRwZnFYqnmcFuOlwBQBimoGPDx+yM8gVWYm4N9dkPUYSZOuVdqujvrE7W+VjdaOT6751bGidnlASm+i8pRJoCasltHpgf/lgQu6u0LXYy4F2WuAfYk9EwnfvEtMt4dfnf0SEyl2FmG/NC0II4AuG9cILxF1TrC1yeY/mvZmKB2ePw+wqqdyG5/UoEJeRLgBgo5PcXOOajHKv4JzYYno1e8ujYh+bB28cB6x48=
X-MS-TrafficTypeDiagnostic: VI1PR0701MB3008:
X-Microsoft-Antispam-PRVS: 
X-Exchange-Antispam-Report-Test: UriScan:(10436049006162)(138986009662008)(95692535739014); 
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(5005006)(8121501046)(3002001)(93006095)(93001095)(10201501046)(3231101)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123564045)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123562045)(6072148)(201708071742011); SRVR:VI1PR0701MB3008; BCL:0; PCL:0; RULEID:; SRVR:VI1PR0701MB3008; 
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 4:+APwg6gwdkTRltS317p+K31O1Cze031OhSERyuzBQAdNHGaqwmdYysw4XAIgfxEnV6yQi+CxrUzjW6BZcwqRFTYSwanUmMLuXd/3+Xm1OHtawayf7yqwZDHTRZ32da3RbKUDsfxZtrvxrJ6bclOTPSUVArgDHIh7lqmIOO/BwTiCLsjDGRrUE22md8rOXM0RQjbq44qI9+9I5jFhtLp1p2goeYarN5r55kxzsYInZPcNzrH55nN9JPpXaKdSTSxGD20GlDZIXYZHyNO2jIRr+GoK6/v3O5D5T+J8j2M52J7PAhmL7PMpKHYEyc4ryV/Jlnn2goz+oh6/TQaU6lf4lyV+vfDTB7KzIYleWAYXdA66vq3urmI9vmetdKg3atuJ
X-Forefront-PRVS: 059185FE08
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(39380400002)(376002)(396003)(366004)(346002)(39860400002)(189003)(199004)(13464003)(305945005)(966005)(106356001)(8676002)(76176011)(50226002)(9686003)(81166006)(81156014)(25786009)(50466002)(44736005)(478600001)(316002)(6306002)(6486002)(575784001)(86362001)(62236002)(8666007)(14496001)(105586002)(5660300001)(7736002)(386003)(230700001)(52116002)(53546011)(33896004)(6496006)(2486003)(53936002)(4326008)(81686011)(1556002)(81816011)(23676004)(26005)(44716002)(186003)(16526019)(61296003)(8936002)(229853002)(6246003)(6666003)(1941001)(84392002)(47776003)(68736007)(66066001)(4720700003)(2906002)(110136005)(3846002)(93886005)(6116002)(97736004)(74416001)(7726001); DIR:OUT; SFP:1102; SCL:1; SRVR:VI1PR0701MB3008; H:pc6; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:0; LANG:en; 
Received-SPF: None (protection.outlook.com: btconnect.com does not designate permitted sender hosts)
X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtWSTFQUjA3MDFNQjMwMDg7MjM6LzNoYnZRWWVkaFBYNmRvbnVlV1h1Si94?= =?utf-8?B?U1RYWGRVdWFXWm5seGFNRGRjYVZ5SSt5cU96bjJUcFQ1QmlsazhEK21WMEg5?= =?utf-8?B?TXByT0w0NE5hUlB0ZEhkL2VjSEttRWw2TDQ1T1YzQXlOSTE2byswKzQ5YnhM?= =?utf-8?B?aWV5YmFRY2Q5U1UwR3UwMVZoR205UXNaR3RZclhrdFpNMFQwdHo2MFdqNE16?= =?utf-8?B?MHBNVzF3VDIzVi9aQ3paa0ZNSDJEYVZKMWVLd2xabjFxbG54bWgzSVRvSzlz?= =?utf-8?B?RXNkRm5Vakx2aWZHYkREL0UxU0FjdDRoYmdjVHJLL0R0aHgwNm5pdHVKT3pO?= =?utf-8?B?MFBlN1RUekVFN2IvQStHZnphOWlLbEdrZExhOXNzQjBIckwzc2VkTDFaL1hJ?= =?utf-8?B?NjJteExTdGNER1U4YjlCaUplajNNSjZ3Y1I5UG9JZ0NDVmxKYnFnSDIxTjhu?= =?utf-8?B?S3BDaW5ybjVDbVpZdU9BMnpVYUhjQkhSNUNRa1ltVHBXZ3ZVS3hGRjd4UGJm?= =?utf-8?B?ZHlGcGwzRjhVeGlrdERkbkVKdHNodVdHZTVwTU9aUm1nZSs5cXd3SHBuNjJN?= =?utf-8?B?NERYOFdPUlZnbkk4Y0tnc1Q2amhIU2pLc2J4eGJoVHNweWdVVDFOS1ptY0xw?= =?utf-8?B?V3Q0czI2eHBWb21uSWtiN214U0FVMit0R2M5RHpCYnB0NFpsbm5BOVVaZFR2?= =?utf-8?B?VW1SbEt3NlhKVFdYOFJMM1pGYXR0bUtOMHBWZ1h6UzUvN215UnpBWkllS1Ra?= =?utf-8?B?QXlUN1liWXNjTmowcjVIVlRvU0xoRStMeFZyTWo2R3RzK0Rzb2dneCtjNE1O?= =?utf-8?B?WnkxdVl3WmkyTCsyTG56S1lKQVV5U2pIZGx3bTVhSHZteG5wbFFLNHBwMUNL?= =?utf-8?B?ZTRRemJDbVo4RldUeGREL0ZaN0ZJc3p0UGxiVHBxcUlTc1VvejgwTDB5N1dm?= =?utf-8?B?aUxWUUZnbmpCYnlmUFB5VnlPVVNPTFM5ZGZ1ZGhjRWVmQUNzN2VpUzJSbUNJ?= =?utf-8?B?eXZwVk5vY1d0ZjFNdXozNVNuZ0VETyt4QzhMYUYwd1VkTWNvallBZ0lPMnpW?= =?utf-8?B?aXI5dEZvUExyNUVVRUdUTld5MnRUdW5rSE5oRHBrdzhESWMrUTRLYmo4UjFE?= =?utf-8?B?anppb0labktTblVHaTgwMUhrVXcwU1pJY0dETGVpOHJiNC9VUlRwdFVuVEdV?= =?utf-8?B?SE1sbiswaHR5c3Bid0dmY0hUdUFDK1Z0WlNxYnQreDFueDFEOUlpT0kzL1ls?= =?utf-8?B?L0YzY3RDTkRNUHZBSEsvVnFObE56eHJ3NFNRenNIelgvQTVvT1JTVFA1dHFD?= =?utf-8?B?dU5ZdkxNdkdvd2o0UXFLZk1Iei8wODdZcEZCL2pwRlVzeXVZU205THIwVzJm?= =?utf-8?B?T2xQU0ttbmgrNTl1S1VEcGFXbk1KNkc3TEdTUXVuUjh5TU5RcHluTXNzTmsw?= =?utf-8?B?U3Bwd20yRkFKUjVTUnFmekEyRUJhQ1VEaVo4eE9ZMVFqYmZGdDV6MWFWMEVB?= =?utf-8?B?Nzk5RDE2c3R5WkpYMUdraklkM2x1bWZGS3p0aEFSZS93UmZqRk1YdnJZYVJD?= =?utf-8?B?SU4vQkMzZWhzck0zUDRKa0FySThRTGYxRVhnU0gvblFCamFoZFlGK1JCVWhB?= =?utf-8?B?QitLMHhaLzU0blJJNDI5b1l3bi9CWGY3TFhlTHFTaitWM0NNTU1zQlgwSllT?= =?utf-8?B?VUhWVkJkQmx1c2hEL2dQV0huWkVJNmJyZ0ZLU095S0dJUDJuTW1jUm9uWjJP?= =?utf-8?B?ZE82VG1ENU5XckFaaXJVNnNZV0oxYWtTR0N5OGhES1JuRjJlRG01TGd2ZHkx?= =?utf-8?B?R1dqSUZXaS84L1RpNUd5QWZNMFcyWlowRTdTTnV6Ujl6Tmw2VzBpM0lhdGY1?= =?utf-8?B?RWNGMnRFV2hDZ1M0L1dEQlFxOFN4WWtZeHE2Mm9GL3pTbEdqcjJ4a2d5ZVlT?= =?utf-8?B?VE5HRjhpZnB5UmQxTGlmdkNWOVVOR09LeEEyMzRPbkcrNEpiMkp2Qk9vUERE?= =?utf-8?B?T2pRY0M5ckdZZVFmczUrb1BxOUx1V0VvZm1Yd3JSWDJnVmtkemkwbnNMK05r?= =?utf-8?Q?Ld+qye6KNaG7rn09VbvcAel1w51?=
X-Microsoft-Exchange-Diagnostics: 1; VI1PR0701MB3008; 6:0RJ2+q48qdf9b77Nr/c1CT2rhnZXkK1ZUezLv7dSs8CNNuTF1F7OcZiwzZ0sSekK4IarJvj+JBIqqSYr7zq0w2urCHnM1/lKYGoypRf6bKsdM9gmeOA5ih7SLc+NkkgyOYvMjzejyVf9TkHNQ01kxBPbGb4piJnf27NpstXrpQ3vSiqOMrWwqi4vVR/HLfLNxOs33ihehJN3KObX9bhadVarELJlGsIgcIIDCIEJ3Ep+jhXCFRmr0PKdBrJ39lIJ7hvAEtTtSjiBJDbyrejUI+lNqTyHMMrYcZ/u+k1t0GdTwCuGXPvytswdiWtVgZXHOasV1BqkEZOH1q8kMKx5eS0yhwUrkTrtToB8a1am6zs=; 5:nP1vgqst7xNmEtQLmZtr9i7yTb/y+tekALAb45kpEU/ON2TY1Jn5NZyNB4fAgV++OayCP7y/x9VQYscEx10m27xCvYzlb7gLymnXc8sSaSZMj86Wz6Em3U53Qm8FASCtsOoXF7oodEWFVEg0R2jR+EGl5NHxc3OqfxjBpfMPATQ=; 24:XmoruQscefWJ3Tb7zXue7p4PYaSobswzS8HW8jy13qbmzzLR2XDRLyhhRH1/Ks5gi+FktmQAh940xloV0uNqUv1FgGqhK4S5Y1dN68XX01Y=; 7:TZdGW2e70X+OpEXHBnK3FiUiDm3Xb2VI9RQ21c/ybp+kcWs97ol6ewERQWNvJqKZeOxYg6MQAojm62crv8CMctA7Nj+v+htXhaB2AnXTapoj2B4Cmj8Zc5rAQWwhlOMvGvJiV6+fPwwvfueHHNUrtVorrxzvk2SNvs+V0WiYGvT9K3GmYL8hFXU1F7vPtuwSWtbYbN3sYCHNr2HDV8JWsHWa4Ulf8v5U+w+Soit0h/2M8OOWjtRA+xa1Y/pxCq+T
SpamDiagnosticOutput: 1:99
SpamDiagnosticMetadata: NSPM
X-OriginatorOrg: btconnect.com
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 22 Feb 2018 17:08:04.7900 (UTC)
X-MS-Exchange-CrossTenant-Network-Message-Id: ce02f3fb-9bc2-4192-ca72-08d57a16d6b5
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: cf8853ed-96e5-465b-9185-806bfe185e30
X-MS-Exchange-Transport-CrossTenantHeadersStamped: VI1PR0701MB3008
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 17:08:11 -0000

----- Original Message -----
From: "Clyde Wildes (cwildes)" 
Sent: Wednesday, February 21, 2018 9:21 PM

> Kent, Tom, Yaron, and Ron,
>
> A new version of the draft-ietf-netmod-syslog-model has been published
that addresses your concerns.

Optimist:-)

And we can always have fresh concerns:-(

I note that this I-D imports interface-ref  from RFC7223 while
                    draft-ietf-netmod-rfc7223bis
is in the RFC Edittor's queue.  I do not think that there is any reason
not to use the latter.

Tom Petch


>
> Thanks,
>
> Clyde
>
> On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen"
 wrote:
>
>
>
>
>     > Kent
>     >
>     > You illustrate beautifully the problem I would like a solution
to.
>     >
>     > The current thinking AFAICT is that tree-diagrams
>     > should be an Informative Reference.
>     >
>     > Therefore, the RFC Editor will not hold publication until an RFC
number
>     > is assigned.
>     >
>     > Therefore, a note asking the I-D reference to be updated to
reflect the
>     > assigned RFC number is null - the RFC can be published with the
>     > reference as an i-d and not as an RFC which is what I expect the
RFC
>     > Editor to do.
>     >
>     > QED
>
>
>     Except I know that this draft will be stuck in MISREF state and
tree-diagrams
>     will in fact be assigned an RFC number by the time this draft is
published.
>
>     K.
>
>
>     > Note that this is not the case of a Normative i-d reference
being buried
>     > in the YANG module and not being.noticed by the RFC Editor; that
problem
>     > I am content with.
>     >
>     >
>     >Tom Petch
>
>
>
>
>
>
>
>
>     >
>     > Please also address these issues when posting -21 to address
Benoit's
>     issues.  Please post -21 ASAP as Benoit has already placed this
draft on
>     the IESG telechat in a couple weeks.
>     >
>     > Thanks,
>     > Kent // shepherd
>     >
>     >
>     > On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
>      on behalf
of
>     bclaise@cisco.com> wrote:
>     >
>     > Dear all,
>     >
>     > - the draft is NMDA compliant, right? It should be mentioned.
>     > Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
>     >
>     >    The YANG model in this document conforms to the Network
Management
>     >
>     >    Datastore Architecture defined in
>     I-D.ietf-netmod-revised-datastores.
>     >
>     >
>     > - As mentioned in the writeup,
[I-D.ietf-netmod-yang-tree-diagrams]
>     should be an informative reference, not normative.
>     >
>     > - Editorial:
>     > OLD:
>     > This draft addresses the common leafs
>     > NEW:
>     > This document addresses the common leafs
>     >
>     > Please publish a new version asap.
>     > In the mean time, I'm sending this draft to IETF LC.
>     >
>     > Regards, Benoit
>     >
>     >
>     >
>
>
>     ------------------------------------------------------------------
------
>     --------
>
>
>     > _______________________________________________
>     > netmod mailing list
>     > netmod@ietf.org
>     >
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailma
n_listinfo_netmod&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI
&r=9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=cJ7MVnQVc1hgxpVF7oYiVn6
Rbm-Qf2dDyrfYhL-s9io&s=u0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8&e=
>     >
>
>
>
>     _______________________________________________
>     netmod mailing list
>     netmod@ietf.org
>     https://www.ietf.org/mailman/listinfo/netmod
>
>
>


From nobody Thu Feb 22 09:15:32 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3F08112D878 for ; Thu, 22 Feb 2018 09:15:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IKscrbiL8e9s for ; Thu, 22 Feb 2018 09:15:24 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3EEFA12D879 for ; Thu, 22 Feb 2018 09:15:24 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7128; q=dns/txt; s=iport; t=1519319724; x=1520529324; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=czqBTapjqHVVHkPJNhvHJ30kXHcm/bInnqXSR2f+mrw=; b=B/THitgmEUws6unjA5tQ0wp4N1C/gvc3Pqo5BlRv1Z8I/iKAeK4qMJkl S1cd5kYUXZlVKMaRKd3muZEyyv8S9o/2bES9CC5C57rDK5doyzf0NLQj2 XmQg6I5GpF2/U40wmHdDjS3Kic4ej93XDFThzvabhdsXFFRJvmLt/mkdj 8=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B/AQD/+Y5a/xbLJq1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGENXAog2iLGY5YCyeBFphkChgLhEJPAoMGFAECAQEBAQEBAms?= =?us-ascii?q?ohSQBAQQBASEECwEFNhsJAg4KAgImAgInMAYBDAYCAQEXiggQjROddIFtOoUAg?= =?us-ascii?q?3aCFwEBAQEBAQEBAgEBAQEBAQEBAQEBGAWBD4QKg36BZykMgnmDMAEBgUYLAQE?= =?us-ascii?q?egxeCZQEEklaRaQmWDow5iAuQDYgdgTw2IoFRMxoIGxU6gkOEdkE3inGCPgEBA?= =?us-ascii?q?Q?=
X-IronPort-AV: E=Sophos;i="5.47,378,1515456000";  d="scan'208";a="2231248"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2018 17:15:20 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1MHFKsA019332; Thu, 22 Feb 2018 17:15:20 GMT
To: Lou Berger , NetMod WG 
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net>
From: Robert Wilton 
Message-ID: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com>
Date: Thu, 22 Feb 2018 17:15:20 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 17:15:31 -0000

Hi Lou,

I think that this solution is inferior to the model presented in pre-09.

I would prefer that we publish pre09 instead, potentially including the 
-08 model in the appendix if that helps progress the document in a more 
expedient fashion.

Thanks,
Rob


On 22/02/2018 16:18, Lou Berger wrote:
> Hi,
>
> (I have a bunch of different roles WRT this work.  This mail is being 
> sent as an individual - as chair, I fully support the previous chair 
> statements on this draft.)
>
> Chris and I have come up with a proposal on how to provide full NMDA 
> as part the existing schema-mount module.  Our motivation was to 
> enable full NMDA support with *minimal* change to the model and 
> disruption to the LC'ed work.  The key NMDA limitation, with -08, that 
> we are aiming to address is the ability to support different mounted 
> schema in different datastores for non-inline mount points. (See more 
> detailed description below if interested full nuances of limitations 
> of -08)
>
> What we came up with was  to simply add a (leaf)list to identify in 
> which datastores a
> schema-mount schema is valid/present. This is somewhat similar to 
> YL-bis schema/module-set. Specifically we're proposing (see below for 
> full tree below):
>
>            +--ro schema* [name]
>               +--ro name           string
> ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}
>
> This approach has the advantages of supporting different mounted 
> schema in different DSes, working with both NMDA and non-NMDA 
> implementations, supporting all of the extensively discussed features 
> of schema mount (including recursive mounts), and having minor/scoped 
> impact on all dependent work.  The main downside is that it isn't the 
> most optimal/compact solution possible if we were to base this work on 
> YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all 
> perspectives, but it is what was agreed to as sufficient by those who 
> contribute to the WG discussion.
>
> In short, we see this as a solution to  addresses the raised last call 
> issue with the minimal impact on -08 and dependent work -- which is 
> what is appropriate given where we are in the process.
>
> So our/my question really is:
>
>     Is this a solution that you/all can live with?
>
> Note: optimization, design preference and perfect alignment with use 
> or YL-bis are not part of our question as we both don't think that is 
> the right question given where we are in the WG process.
>
> Lou (with ideas developed with Chris, and chair hat off)
>
> ======
> Details -- for those who want
> ======
> As background, my understanding/view is that the -08 version of the 
> both NMDA and non-NMDA supporting implementations, but there are 
> limitations in its NMDA applicability. Used with Yang Library, 
> [rfc7895], only non-NMDA implementations can be supported.  When used 
> with the revised Yang Library defined in 
> [I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be 
> supported with certain limitations. Specifically, this document 
> requires use of the now deprecated module-list grouping, and the same 
> schema represented in schema list of the Schema Mount module MUST be 
> used in all datastores.  Inline type mount points, which don't use the 
> schema list,  can support different schema in different data stores 
> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of 
> YANG library under the inline mount point.
>
>     module: ietf-yang-schema-mount
>         +--ro schema-mounts
>            +--ro namespace* [prefix]
>            |  +--ro prefix    yang:yang-identifier
>            |  +--ro uri?      inet:uri
>            +--ro mount-point* [module name]
>            |  +--ro module        yang:yang-identifier
>            |  +--ro name          yang:yang-identifier
>            |  +--ro config?       boolean
>            |  +--ro (schema-ref)?
>            |     +--:(inline)
>            |     |  +--ro inline?       empty
>            |     +--:(use-schema)
>            |        +--ro use-schema* [name]
>            |           +--ro name
>            |           |       -> /schema-mounts/schema/name
>            |           +--ro parent-reference*   yang:xpath1.0
>            +--ro schema* [name]
>               +--ro name           string
> ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}
>               +--ro module* [name revision]
>               |  +--ro name                yang:yang-identifier
>               |  +--ro revision            union
>               |  +--ro schema?             inet:uri
>               |  +--ro namespace           inet:uri
>               |  +--ro feature*            yang:yang-identifier
>               |  +--ro deviation* [name revision]
>               |  |  +--ro name        yang:yang-identifier
>               |  |  +--ro revision    union
>               |  +--ro conformance-type    enumeration
>               |  +--ro submodule* [name revision]
>               |     +--ro name        yang:yang-identifier
>               |     +--ro revision    union
>               |     +--ro schema?     inet:uri
>               +--ro mount-point* [module name]
>                  +--ro module        yang:yang-identifier
>                  +--ro name          yang:yang-identifier
>                  +--ro config?       boolean
>                  +--ro (schema-ref)?
>                     +--:(inline)
>                     |  +--ro inline?       empty
>                     +--:(use-schema)
>                        +--ro use-schema* [name]
>                           +--ro name
>                           |       -> /schema-mounts/schema/name
>                           +--ro parent-reference*   yang:xpath1.0
>
> We would expect that the revised-datastores feature would be used
> (perhaps required) for any implementation that supports ietf-datastores
> and yl-bis.
>
>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Thu Feb 22 11:58:09 2018
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 5BBDE12DA40; Thu, 22 Feb 2018 11:58:02 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: Stephen Farrell 
To: 
Cc: ietf@ietf.org, netmod@ietf.org, draft-ietf-netmod-rfc6087bis.all@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.72.2
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151932948231.8096.10376000064045374752@ietfa.amsl.com>
Date: Thu, 22 Feb 2018 11:58:02 -0800
Archived-At: 
Subject: [netmod] Secdir telechat review of draft-ietf-netmod-rfc6087bis-18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 19:58:02 -0000

Reviewer: Stephen Farrell
Review result: Ready


I reviewed the diff between -18 and RFC6087. [1]

   [1] https://www.ietf.org/rfcdiff?url1=rfc6087&url2=draft-ietf-netmod-rfc6087bis-18

I assume the security ADs were involved already in discussion about
the new security considerations template in 3.7.1 and the text there
does seem fine to me, so I won't even nit-pick about it:-)

I do have some other nits to note though.

- There are a number of URLs given for access to updated materials
that use http schemed URLs and that do not use https schemed URLs.
There was a recent IESG statement to the effect that those'd be better
as https URLs. The first such example is in 3.1. In fact that URL is
re-directed (for me) to https. I think a general pass to fix such URLs
to use https wherever possible would be easy and better practice.

- Some of the namespaces use http schemed URLs, for example in
section 4.2. I don't know if people are expected to de-reference such
URLs, but if they are then it'd be good to say if https is better to use
or not. (I'd argue it is.) If those URLs are not expected to be 
de-referenced, then saying that would be good. (Not that it'd stop 
people de-referencing 'em so the change is better in any case;-)

Cheers,
S.


From nobody Thu Feb 22 15:06:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3EFBD126D73 for ; Thu, 22 Feb 2018 15:06:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.53
X-Spam-Level: 
X-Spam-Status: No, score=-14.53 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Og1F1cNV-L6F for ; Thu, 22 Feb 2018 15:06:33 -0800 (PST)
Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D1AAC126B6D for ; Thu, 22 Feb 2018 15:06:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1492; q=dns/txt; s=iport; t=1519340792; x=1520550392; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=xmMRTQdl7v4ZogiIbZL70Pv/sele0dIvaax1X5fDaaA=; b=B7Ye1uHZugDXt6frs7QcxZQnibWOkteqfRNlh/oMXGvHBZR4gwCJjKay egfoD1eNvceH+ZYBgUDMvSU2qYVGMUFWYJYYql+G+PtlgHYatkzw7jBKW 2jczjlmZ2XkVcbkrJnLhKu1UL9Y+OBIlY7FDeGXyTW3fbAFXUH02lAJvd E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AzAwA7TI9a/5NdJa1dGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQcBAQEBAYNPgVYog2iYIYFQMoEWmGQKhTQCgi5XFQECAQEBAQEBAms?= =?us-ascii?q?ohSMBAQEDASMVTQQLFQECAgImAgJXBgEMBgIBAReKAAisBIInhQCDd4IZAQE?= =?us-ascii?q?BAQEBAQEBAQEBAQEBAQEBAR+BD4QKgieBV4FnKYMFiDqCZQEEk2qQVQmWDow?= =?us-ascii?q?5iAuQDYgdgTw1I4FRMxoIGxWCfYUUIzeMaAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.47,381,1515456000"; d="scan'208";a="352435839"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by rcdn-iport-9.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 22 Feb 2018 23:06:31 +0000
Received: from [10.82.171.153] ([10.82.171.153]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id w1MN6SgK026983; Thu, 22 Feb 2018 23:06:30 GMT
To: "t.petch" , Kent Watsen , NETMOD Working Group 
References:  <922E608D-951A-459A-B515-B53834C805C1@juniper.net> <022001d3aa6a$c31895e0$4001a8c0@gateway.2wire.net>  <070301d3abff$683091a0$4001a8c0@gateway.2wire.net>
From: Benoit Claise 
Message-ID: <90bdf9bc-2e13-8ed3-56d1-d7937f76381b@cisco.com>
Date: Thu, 22 Feb 2018 15:35:08 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <070301d3abff$683091a0$4001a8c0@gateway.2wire.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Thu, 22 Feb 2018 23:06:34 -0000

On 2/22/2018 11:49 AM, t.petch wrote:
> ----- Original Message -----
> From: "Kent Watsen" 
> To: "t.petch" ; "NETMOD Working Group"
> 
> Sent: Tuesday, February 20, 2018 5:06 PM
>>> Kent
>>>
>>> You illustrate beautifully the problem I would like a solution to.
>>>
>>> The current thinking AFAICT is that tree-diagrams
>>> should be an Informative Reference.
>>>
>>> Therefore, the RFC Editor will not hold publication until an RFC
> number
>>> is assigned.
>>>
>>> Therefore, a note asking the I-D reference to be updated to reflect
> the
>>> assigned RFC number is null - the RFC can be published with the
>>> reference as an i-d and not as an RFC which is what I expect the RFC
>>> Editor to do.
>>>
>>> QED
>>
>> Except I know that this draft will be stuck in MISREF state and
> tree-diagrams
>> will in fact be assigned an RFC number by the time this draft is
> published.
>
> Kent
>
> Corner case:-)
Note that, for this corner case, the IESG agreed for the tree-diagrams 
to go through expedited processing.
Even if this is an informative reference, it's nicer to get an RFC as a 
reference.

Regards, Benoit

>
> You cannot know in general that drafts that appear as Informational
> References and which are referenced from within a YANG module will be
> published before the referencing I-D will be and so will have a RFC
> number which can be inserted by the RFC Editor.
>
>


From nobody Thu Feb 22 23:12:09 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EA741243FE for ; Thu, 22 Feb 2018 23:12:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Iu-jfxep4nxY for ; Thu, 22 Feb 2018 23:12:06 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6779124234 for ; Thu, 22 Feb 2018 23:12:06 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 9031A755 for ; Fri, 23 Feb 2018 08:12:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id Gog5k_Hh5q9A for ; Fri, 23 Feb 2018 08:12:04 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS for ; Fri, 23 Feb 2018 08:12:05 +0100 (CET)
Received: from localhost (demetrius4.jacobs-university.de [212.201.44.49]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5645520152 for ; Fri, 23 Feb 2018 08:12:05 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius4.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id Nn8w9c8IqpmX; Fri, 23 Feb 2018 08:12:05 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1CCB120150; Fri, 23 Feb 2018 08:12:05 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id DEC57425305E; Fri, 23 Feb 2018 08:12:04 +0100 (CET)
Date: Fri, 23 Feb 2018 08:12:04 +0100
From: Juergen Schoenwaelder 
To: netmod@ietf.org
Message-ID: <20180223071204.wio22cwopgajy7hb@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: netmod@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: [netmod] reference statement examples in draft-ietf-netmod-rfc6087bis-18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 07:12:08 -0000

Hi,

I think it was common practice to write

  reference "RFC 6991: Common YANG Data Types";

instead of just

  reference "RFC 6991";

that is to include the RFC title (this can be especially useful with
longer lists of references and less commonly known RFC numbers). It
seems that draft-ietf-netmod-rfc6087bis-18 kind of suggests to only
use the RFC number (section 3.2 and section 4.7).

/js

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


From nobody Fri Feb 23 01:36:34 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 790571243FE for ; Fri, 23 Feb 2018 01:36:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id djMS3JCY_LeJ for ; Fri, 23 Feb 2018 01:36:30 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 5F5771242EA for ; Fri, 23 Feb 2018 01:36:30 -0800 (PST)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id DBF911AE02BE; Fri, 23 Feb 2018 10:36:28 +0100 (CET)
Date: Fri, 23 Feb 2018 10:36:28 +0100 (CET)
Message-Id: <20180223.103628.1174590223555999274.mbj@tail-f.com>
To: rwilton@cisco.com
Cc: lberger@labn.net, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com>
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 09:36:32 -0000

Hi,

Robert Wilton  wrote:
> Hi Lou,
> =

> I think that this solution is inferior to the model presented in
> pre-09.

I agree.  Servers that are NMDA-compliant, or implements YANG Library
bis will have to present schemas in two different structures,
depending on where the schema is used, and clients will have to code
for both.  With the solution in pre-09, there is just one structure.
A single structure also has other benefits (apart from being simpler),
e.g., if we augment it with the meta data that has been discussed
recently, we can augment a single structure.


/martin



> I would prefer that we publish pre09 instead, potentially including
> the -08 model in the appendix if that helps progress the document in =
a
> more expedient fashion.
> =

> Thanks,
> Rob
> =

> =

> On 22/02/2018 16:18, Lou Berger wrote:
> > Hi,
> >
> > (I have a bunch of different roles WRT this work.=A0 This mail is b=
eing
> > sent as an individual - as chair, I fully support the previous chai=
r
> > statements on this draft.)
> >
> > Chris and I have come up with a proposal on how to provide full NMD=
A
> > as part the existing schema-mount module.=A0 Our motivation was to
> > enable full NMDA support with *minimal* change to the model and
> > disruption to the LC'ed work.=A0 The key NMDA limitation, with -08,=
 that
> > we are aiming to address is the ability to support different mounte=
d
> > schema in different datastores for non-inline mount points. (See mo=
re
> > detailed description below if interested full nuances of limitation=
s
> > of -08)
> >
> > What we came up with was=A0 to simply add a (leaf)list to identify =
in
> > which datastores a
> > schema-mount schema is valid/present. This is somewhat similar to
> > YL-bis schema/module-set. Specifically we're proposing (see below f=
or
> > full tree below):
> >
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro schema* [name]
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 string
> > ADD=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro datastore*=A0=A0=A0 ds:datasto=
re-ref {revised-datastores}
> >
> > This approach has the advantages of supporting different mounted
> > schema in different DSes, working with both NMDA and non-NMDA
> > implementations, supporting all of the extensively discussed featur=
es
> > of schema mount (including recursive mounts), and having minor/scop=
ed
> > impact on all dependent work.=A0 The main downside is that it isn't=
 the
> > most optimal/compact solution possible if we were to base this work=
 on
> > YL-bis/pre09 draft.=A0 Of course -08 isn't necessarily optimal from=
 all
> > perspectives, but it is what was agreed to as sufficient by those w=
ho
> > contribute to the WG discussion.
> >
> > In short, we see this as a solution to=A0 addresses the raised last=
 call
> > issue with the minimal impact on -08 and dependent work -- which is=

> > what is appropriate given where we are in the process.
> >
> > So our/my question really is:
> >
> > =A0=A0=A0 Is this a solution that you/all can live with?
> >
> > Note: optimization, design preference and perfect alignment with us=
e
> > or YL-bis are not part of our question as we both don't think that =
is
> > the right question given where we are in the WG process.
> >
> > Lou (with ideas developed with Chris, and chair hat off)
> >
> > =3D=3D=3D=3D=3D=3D
> > Details -- for those who want
> > =3D=3D=3D=3D=3D=3D
> > As background, my understanding/view is that the -08 version of the=

> > both NMDA and non-NMDA supporting implementations, but there are
> > limitations in its NMDA applicability. Used with Yang Library,
> > [rfc7895], only non-NMDA implementations can be supported.=A0 When =
used
> > with the revised Yang Library defined in
> > [I.D.ietf-netconf-rfc7895bis-],=A0 NMDA implementations=A0 can be
> > supported with certain limitations. Specifically, this document
> > requires use of the now deprecated module-list grouping, and the sa=
me
> > schema represented in schema list of the Schema Mount module MUST b=
e
> > used in all datastores.=A0 Inline type mount points, which don't us=
e the
> > schema list,=A0 can support different schema in different data stor=
es
> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
> > YANG library under the inline mount point.
> >
> > =A0=A0=A0 module: ietf-yang-schema-mount
> > =A0=A0=A0=A0=A0=A0=A0 +--ro schema-mounts
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro namespace* [prefix]
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro prefix=A0=A0=A0 yang:yang=
-identifier
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro uri?=A0=A0=A0=A0=A0 inet:=
uri
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro mount-point* [module name]
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro module=A0=A0=A0=A0=A0=A0=A0=
 yang:yang-identifier
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 yang:yang-identifier
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro config?=A0=A0=A0=A0=A0=A0=
 boolean
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro (schema-ref)?
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 +--:(inline)
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 |=A0 +--ro inline?=A0=A0=
=A0=A0=A0=A0 empty
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 +--:(use-schema)
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro use-sch=
ema* [name]
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--r=
o name
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=
=A0=A0=A0=A0=A0 -> /schema-mounts/schema/name
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--r=
o parent-reference*=A0=A0 yang:xpath1.0
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro schema* [name]
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=A0=
=A0=A0=A0=A0 string
> > ADD=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro datastore*=A0=A0=A0 ds:datasto=
re-ref {revised-datastores}
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +--ro module* [name revision]=

> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro name=A0=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 yang:yang-identifier
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro revision=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 union
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro schema?=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 inet:uri
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro namespace=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 inet:uri
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro feature*=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 yang:yang-identifier
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro deviation* [name=
 revision]
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0 +--ro name=A0=A0=A0=
=A0=A0=A0=A0 yang:yang-identifier
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0 +--ro revision=A0=
=A0=A0 union
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro conformance-type=
=A0=A0=A0 enumeration
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro submodule* [name=
 revision]
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 +--ro name=A0=
=A0=A0=A0=A0=A0=A0 yang:yang-identifier
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 +--ro revisio=
n=A0=A0=A0 union
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 +--ro schema?=
=A0=A0=A0=A0 inet:uri
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro mount-point* [module =
name]
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro module=A0=A0=
=A0=A0=A0=A0=A0 yang:yang-identifier
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro name=A0=A0=A0=
=A0=A0=A0=A0=A0=A0 yang:yang-identifier
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro config?=A0=A0=
=A0=A0=A0=A0 boolean
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro (schema-ref)=
?
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--:(inli=
ne)
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--r=
o inline?=A0=A0=A0=A0=A0=A0 empty
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--:(use-=
schema)
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =
+--ro use-schema* [name]
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 +--ro name
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 |=A0=A0=A0=A0=A0=A0 -> /schema-mounts/schema/name
> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0 +--ro parent-reference*=A0=A0 yang:xpath1.0
> >
> > We would expect that the revised-datastores feature would be used
> > (perhaps required) for any implementation that supports
> > ietf-datastores
> > and yl-bis.
> >
> >
> >
> > _______________________________________________
> > netmod mailing list
> > netmod@ietf.org
> > https://www.ietf.org/mailman/listinfo/netmod
> =

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


From nobody Fri Feb 23 04:45:04 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1A07812D949 for ; Fri, 23 Feb 2018 04:45:02 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 zDb2gKQCydd0 for ; Fri, 23 Feb 2018 04:45:00 -0800 (PST)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 10C88124239 for ; Fri, 23 Feb 2018 04:45:00 -0800 (PST)
Received: from [::1] (port=48188) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1epCih-000177-Fo; Fri, 23 Feb 2018 15:44:59 +0300
To: Martin Bjorklund , rwilton@cisco.com
Cc: netmod@ietf.org
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com>
From: Lou Berger 
Message-ID: <61afc424-4131-2871-b752-59c086dd4727@labn.net>
Date: Fri, 23 Feb 2018 07:44:53 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180223.103628.1174590223555999274.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 12:45:02 -0000

Martin/Rob,

     Back when the topic was raised for the first time publicly 
(Yokahama) and discussed in the WG [1] *any* solution would have been 
workable.  At this point > 2 years later, do you really think it is 
reasonable to do a rewrite of the solution ?  Are you really not willing 
to live with a compromise that addresses the issue albeit in way that 
you/some view as suboptimal?

Keep in mind that we had lots of discussions on what is 
optimal/preferred and there are/were different view points on this, 
compromises were made that increased complexity for others and these 
were accepted in interest of progressing *any* deployable solution.

Lou

[1] 
https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod

On 2/23/2018 4:36 AM, Martin Bjorklund wrote:
> Hi,
>
> Robert Wilton  wrote:
>> Hi Lou,
>>
>> I think that this solution is inferior to the model presented in
>> pre-09.
> I agree.  Servers that are NMDA-compliant, or implements YANG Library
> bis will have to present schemas in two different structures,
> depending on where the schema is used, and clients will have to code
> for both.  With the solution in pre-09, there is just one structure.
> A single structure also has other benefits (apart from being simpler),
> e.g., if we augment it with the meta data that has been discussed
> recently, we can augment a single structure.
>
>
> /martin
>
>
>
>> I would prefer that we publish pre09 instead, potentially including
>> the -08 model in the appendix if that helps progress the document in a
>> more expedient fashion.
>>
>> Thanks,
>> Rob
>>
>>
>> On 22/02/2018 16:18, Lou Berger wrote:
>>> Hi,
>>>
>>> (I have a bunch of different roles WRT this work.  This mail is being
>>> sent as an individual - as chair, I fully support the previous chair
>>> statements on this draft.)
>>>
>>> Chris and I have come up with a proposal on how to provide full NMDA
>>> as part the existing schema-mount module.  Our motivation was to
>>> enable full NMDA support with *minimal* change to the model and
>>> disruption to the LC'ed work.  The key NMDA limitation, with -08, that
>>> we are aiming to address is the ability to support different mounted
>>> schema in different datastores for non-inline mount points. (See more
>>> detailed description below if interested full nuances of limitations
>>> of -08)
>>>
>>> What we came up with was  to simply add a (leaf)list to identify in
>>> which datastores a
>>> schema-mount schema is valid/present. This is somewhat similar to
>>> YL-bis schema/module-set. Specifically we're proposing (see below for
>>> full tree below):
>>>
>>>             +--ro schema* [name]
>>>                +--ro name           string
>>> ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}
>>>
>>> This approach has the advantages of supporting different mounted
>>> schema in different DSes, working with both NMDA and non-NMDA
>>> implementations, supporting all of the extensively discussed features
>>> of schema mount (including recursive mounts), and having minor/scoped
>>> impact on all dependent work.  The main downside is that it isn't the
>>> most optimal/compact solution possible if we were to base this work on
>>> YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all
>>> perspectives, but it is what was agreed to as sufficient by those who
>>> contribute to the WG discussion.
>>>
>>> In short, we see this as a solution to  addresses the raised last call
>>> issue with the minimal impact on -08 and dependent work -- which is
>>> what is appropriate given where we are in the process.
>>>
>>> So our/my question really is:
>>>
>>>      Is this a solution that you/all can live with?
>>>
>>> Note: optimization, design preference and perfect alignment with use
>>> or YL-bis are not part of our question as we both don't think that is
>>> the right question given where we are in the WG process.
>>>
>>> Lou (with ideas developed with Chris, and chair hat off)
>>>
>>> ======
>>> Details -- for those who want
>>> ======
>>> As background, my understanding/view is that the -08 version of the
>>> both NMDA and non-NMDA supporting implementations, but there are
>>> limitations in its NMDA applicability. Used with Yang Library,
>>> [rfc7895], only non-NMDA implementations can be supported.  When used
>>> with the revised Yang Library defined in
>>> [I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be
>>> supported with certain limitations. Specifically, this document
>>> requires use of the now deprecated module-list grouping, and the same
>>> schema represented in schema list of the Schema Mount module MUST be
>>> used in all datastores.  Inline type mount points, which don't use the
>>> schema list,  can support different schema in different data stores
>>> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>> YANG library under the inline mount point.
>>>
>>>      module: ietf-yang-schema-mount
>>>          +--ro schema-mounts
>>>             +--ro namespace* [prefix]
>>>             |  +--ro prefix    yang:yang-identifier
>>>             |  +--ro uri?      inet:uri
>>>             +--ro mount-point* [module name]
>>>             |  +--ro module        yang:yang-identifier
>>>             |  +--ro name          yang:yang-identifier
>>>             |  +--ro config?       boolean
>>>             |  +--ro (schema-ref)?
>>>             |     +--:(inline)
>>>             |     |  +--ro inline?       empty
>>>             |     +--:(use-schema)
>>>             |        +--ro use-schema* [name]
>>>             |           +--ro name
>>>             |           |       -> /schema-mounts/schema/name
>>>             |           +--ro parent-reference*   yang:xpath1.0
>>>             +--ro schema* [name]
>>>                +--ro name           string
>>> ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}
>>>                +--ro module* [name revision]
>>>                |  +--ro name                yang:yang-identifier
>>>                |  +--ro revision            union
>>>                |  +--ro schema?             inet:uri
>>>                |  +--ro namespace           inet:uri
>>>                |  +--ro feature*            yang:yang-identifier
>>>                |  +--ro deviation* [name revision]
>>>                |  |  +--ro name        yang:yang-identifier
>>>                |  |  +--ro revision    union
>>>                |  +--ro conformance-type    enumeration
>>>                |  +--ro submodule* [name revision]
>>>                |     +--ro name        yang:yang-identifier
>>>                |     +--ro revision    union
>>>                |     +--ro schema?     inet:uri
>>>                +--ro mount-point* [module name]
>>>                   +--ro module        yang:yang-identifier
>>>                   +--ro name          yang:yang-identifier
>>>                   +--ro config?       boolean
>>>                   +--ro (schema-ref)?
>>>                      +--:(inline)
>>>                      |  +--ro inline?       empty
>>>                      +--:(use-schema)
>>>                         +--ro use-schema* [name]
>>>                            +--ro name
>>>                            |       -> /schema-mounts/schema/name
>>>                            +--ro parent-reference*   yang:xpath1.0
>>>
>>> We would expect that the revised-datastores feature would be used
>>> (perhaps required) for any implementation that supports
>>> ietf-datastores
>>> and yl-bis.
>>>
>>>
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Feb 23 04:55:16 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B1E061270AE for ; Fri, 23 Feb 2018 04:55:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kp40i2QSA8sC for ; Fri, 23 Feb 2018 04:55:11 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 21D64124239 for ; Fri, 23 Feb 2018 04:55:11 -0800 (PST)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id C5FF61AE02BE; Fri, 23 Feb 2018 13:55:09 +0100 (CET)
Date: Fri, 23 Feb 2018 13:55:09 +0100 (CET)
Message-Id: <20180223.135509.1022283362077802966.mbj@tail-f.com>
To: lberger@labn.net
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <61afc424-4131-2871-b752-59c086dd4727@labn.net>
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 12:55:14 -0000

Hi,

Lou Berger  wrote:
> Martin/Rob,
> =

> =A0=A0=A0 Back when the topic was raised for the first time publicly
> (Yokahama) and discussed in the WG [1] *any* solution would have been=

> workable.=A0 At this point > 2 years later, do you really think it is=

> reasonable to do a rewrite of the solution ?

I don't agree that this is a rewrite of the solution.  I want to keep
the mountpoint statement.  I want to keep the two mechanisms inline
and use-schema.  The only change we're talking about is alinging the
read-only data that the server makes available with YLbis.  This is
quite trivial.  We have documented this in the pre09 branch, and this
is imo ready to be published.

> Are you really not
> willing to live with a compromise that addresses the issue albeit in
> way that you/some view as suboptimal?
> =

> Keep in mind that we had lots of discussions on what is
> optimal/preferred and there are/were different view points on this,
> compromises were made that increased complexity for others and these
> were accepted in interest of progressing *any* deployable solution.

Yes.  I don't want to give up these compromises.  I know that others
want to, and/or explore other solutions.  That's *not* what I'm
proposing.


/martin



> =

> Lou
> =

> [1]
> https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/n=
etmod
> =

> On 2/23/2018 4:36 AM, Martin Bjorklund wrote:
> > Hi,
> >
> > Robert Wilton  wrote:
> >> Hi Lou,
> >>
> >> I think that this solution is inferior to the model presented in
> >> pre-09.
> > I agree.  Servers that are NMDA-compliant, or implements YANG Libra=
ry
> > bis will have to present schemas in two different structures,
> > depending on where the schema is used, and clients will have to cod=
e
> > for both.  With the solution in pre-09, there is just one structure=
.=

> > A single structure also has other benefits (apart from being simple=
r),
> > e.g., if we augment it with the meta data that has been discussed
> > recently, we can augment a single structure.
> >
> >
> > /martin
> >
> >
> >
> >> I would prefer that we publish pre09 instead, potentially includin=
g
> >> the -08 model in the appendix if that helps progress the document =
in a
> >> more expedient fashion.
> >>
> >> Thanks,
> >> Rob
> >>
> >>
> >> On 22/02/2018 16:18, Lou Berger wrote:
> >>> Hi,
> >>>
> >>> (I have a bunch of different roles WRT this work.=A0 This mail is=
 being
> >>> sent as an individual - as chair, I fully support the previous ch=
air
> >>> statements on this draft.)
> >>>
> >>> Chris and I have come up with a proposal on how to provide full N=
MDA
> >>> as part the existing schema-mount module.=A0 Our motivation was t=
o
> >>> enable full NMDA support with *minimal* change to the model and
> >>> disruption to the LC'ed work.=A0 The key NMDA limitation, with -0=
8, that
> >>> we are aiming to address is the ability to support different moun=
ted
> >>> schema in different datastores for non-inline mount points. (See =
more
> >>> detailed description below if interested full nuances of limitati=
ons
> >>> of -08)
> >>>
> >>> What we came up with was=A0 to simply add a (leaf)list to identif=
y in
> >>> which datastores a
> >>> schema-mount schema is valid/present. This is somewhat similar to=

> >>> YL-bis schema/module-set. Specifically we're proposing (see below=
 for
> >>> full tree below):
> >>>
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro schema* [name]
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 string
> >>> ADD=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro datastore*=A0=A0=A0 ds:datas=
tore-ref {revised-datastores}
> >>>
> >>> This approach has the advantages of supporting different mounted
> >>> schema in different DSes, working with both NMDA and non-NMDA
> >>> implementations, supporting all of the extensively discussed feat=
ures
> >>> of schema mount (including recursive mounts), and having minor/sc=
oped
> >>> impact on all dependent work.=A0 The main downside is that it isn=
't the
> >>> most optimal/compact solution possible if we were to base this wo=
rk on
> >>> YL-bis/pre09 draft.=A0 Of course -08 isn't necessarily optimal fr=
om all
> >>> perspectives, but it is what was agreed to as sufficient by those=
 who
> >>> contribute to the WG discussion.
> >>>
> >>> In short, we see this as a solution to=A0 addresses the raised la=
st call
> >>> issue with the minimal impact on -08 and dependent work -- which =
is
> >>> what is appropriate given where we are in the process.
> >>>
> >>> So our/my question really is:
> >>>
> >>>  =A0=A0=A0 Is this a solution that you/all can live with?
> >>>
> >>> Note: optimization, design preference and perfect alignment with =
use
> >>> or YL-bis are not part of our question as we both don't think tha=
t is
> >>> the right question given where we are in the WG process.
> >>>
> >>> Lou (with ideas developed with Chris, and chair hat off)
> >>>
> >>> =3D=3D=3D=3D=3D=3D
> >>> Details -- for those who want
> >>> =3D=3D=3D=3D=3D=3D
> >>> As background, my understanding/view is that the -08 version of t=
he
> >>> both NMDA and non-NMDA supporting implementations, but there are
> >>> limitations in its NMDA applicability. Used with Yang Library,
> >>> [rfc7895], only non-NMDA implementations can be supported.=A0 Whe=
n used
> >>> with the revised Yang Library defined in
> >>> [I.D.ietf-netconf-rfc7895bis-],=A0 NMDA implementations=A0 can be=

> >>> supported with certain limitations. Specifically, this document
> >>> requires use of the now deprecated module-list grouping, and the =
same
> >>> schema represented in schema list of the Schema Mount module MUST=
 be
> >>> used in all datastores.=A0 Inline type mount points, which don't =
use the
> >>> schema list,=A0 can support different schema in different data st=
ores
> >>> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version o=
f
> >>> YANG library under the inline mount point.
> >>>
> >>>  =A0=A0=A0 module: ietf-yang-schema-mount
> >>>  =A0=A0=A0=A0=A0=A0=A0 +--ro schema-mounts
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro namespace* [prefix]
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro prefix=A0=A0=A0 yang:y=
ang-identifier
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro uri?=A0=A0=A0=A0=A0 in=
et:uri
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro mount-point* [module name]
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro module=A0=A0=A0=A0=A0=A0=
=A0 yang:yang-identifier
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro name=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 yang:yang-identifier
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro config?=A0=A0=A0=A0=A0=
=A0 boolean
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro (schema-ref)?
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 +--:(inline)
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 |=A0 +--ro inline?=A0=
=A0=A0=A0=A0=A0 empty
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 +--:(use-schema)
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0 +--ro use-=
schema* [name]
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=
--ro name
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=
=A0=A0=A0=A0=A0=A0 -> /schema-mounts/schema/name
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +=
--ro parent-reference*=A0=A0 yang:xpath1.0
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro schema* [name]
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro name=A0=A0=A0=A0=A0=
=A0=A0=A0=A0=A0 string
> >>> ADD=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro datastore*=A0=A0=A0 ds:datas=
tore-ref {revised-datastores}
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 =A0 +--ro module* [name revisi=
on]
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro name=A0=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 yang:yang-identifier
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro revision=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 union
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro schema?=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 inet:uri
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro namespace=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0 inet:uri
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro feature*=A0=A0=
=A0=A0=A0=A0=A0=A0=A0=A0=A0 yang:yang-identifier
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro deviation* [n=
ame revision]
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0 +--ro name=A0=A0=
=A0=A0=A0=A0=A0 yang:yang-identifier
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 |=A0 +--ro revision=
=A0=A0=A0 union
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro conformance-t=
ype=A0=A0=A0 enumeration
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +--ro submodule* [n=
ame revision]
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 +--ro name=
=A0=A0=A0=A0=A0=A0=A0 yang:yang-identifier
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 +--ro revi=
sion=A0=A0=A0 union
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0=A0=A0=A0 +--ro sche=
ma?=A0=A0=A0=A0 inet:uri
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro mount-point* [modu=
le name]
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro module=A0=
=A0=A0=A0=A0=A0=A0 yang:yang-identifier
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro name=A0=A0=
=A0=A0=A0=A0=A0=A0=A0 yang:yang-identifier
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro config?=A0=
=A0=A0=A0=A0=A0 boolean
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--ro (schema-r=
ef)?
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--:(i=
nline)
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 |=A0 +=
--ro inline?=A0=A0=A0=A0=A0=A0 empty
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 +--:(u=
se-schema)
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
 +--ro use-schema* [name]
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 +--ro name
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 |=A0=A0=A0=A0=A0=A0 -> /schema-mounts/schema/name
> >>>  =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=A0=
=A0=A0=A0 +--ro parent-reference*=A0=A0 yang:xpath1.0
> >>>
> >>> We would expect that the revised-datastores feature would be used=

> >>> (perhaps required) for any implementation that supports
> >>> ietf-datastores
> >>> and yl-bis.
> >>>
> >>>
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >> _______________________________________________
> >> netmod mailing list
> >> netmod@ietf.org
> >> https://www.ietf.org/mailman/listinfo/netmod
> =


From nobody Fri Feb 23 05:19:08 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D7DFC12E047 for ; Fri, 23 Feb 2018 05:19:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-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 jVeGhGsalcsw for ; Fri, 23 Feb 2018 05:19:05 -0800 (PST)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 E139212E045 for ; Fri, 23 Feb 2018 05:19:04 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id 7386D215C48 for ; Fri, 23 Feb 2018 06:19:04 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id EDK01x00i2SSUrH01DK34P; Fri, 23 Feb 2018 06:19:04 -0700
X-Authority-Analysis: v=2.2 cv=M5g9E24s c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=wU2YTnxGAAAA:8 a=48vgC7mUAAAA:8 a=AUd_NHdVAAAA:8 a=LYxLP8SNtGR-Xs6CNKEA:9 a=QEXdDO2ut3YA:10 a=Yz9wTY_ffGCQnEDHKrcv:22 a=w1C3t2QeGrPiZgrLijVG:22
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=fk0mWo9FCSS9OpJmDotcO4e6bhmr+i/NHaAVtojqHtU=; b=QHEefQv3y2K5+Nv3VW8bYj2VT/ FN0UwqiZQQPW4H8oMaSjCfqzc6zxFksETJuoEaLC6qMI9vCo2ftdgPBDyhCw+gHntjwVHGZhCBy3K IIxQNEcBmPeoqJ5JHmlATlITx;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:38020 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1epDFc-002aVq-NE; Fri, 23 Feb 2018 06:19:00 -0700
To: Martin Bjorklund 
Cc: rwilton@cisco.com, netmod@ietf.org
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net> <20180223.135509.1022283362077802966.mbj@tail-f.com>
From: Lou Berger 
Message-ID: 
Date: Fri, 23 Feb 2018 08:18:57 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180223.135509.1022283362077802966.mbj@tail-f.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1epDFc-002aVq-NE
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:38020
X-Source-Auth: lberger@labn.net
X-Email-Count: 3
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 13:19:07 -0000

Martin,


On 2/23/2018 7:55 AM, Martin Bjorklund wrote:
> Hi,
>
> Lou Berger  wrote:
>> Martin/Rob,
>>
>>      Back when the topic was raised for the first time publicly
>> (Yokahama) and discussed in the WG [1] *any* solution would have been
>> workable.  At this point > 2 years later, do you really think it is
>> reasonable to do a rewrite of the solution ?
> I don't agree that this is a rewrite of the solution.  I want to keep
> the mountpoint statement.  I want to keep the two mechanisms inline
> and use-schema.  The only change we're talking about is alinging the
> read-only data that the server makes available with YLbis.
The requirement to use YL-bis is enough for me classifying the change as 
a rewrite.  The current draft is usable with both RFC7895 and YL-bis.  
This is a pretty major change, particularly for anyone working on a 
client or server implementation now, or who wants to soon.

>   This is
> quite trivial.
 From *your* perspective.  There are other's that disagree (See Dean's 
and Chris' mail - they don't want *any* changes and are perfectly happy 
with -08).

>   We have documented this in the pre09 branch, and this
> is imo ready to be published.
It would still need to go through normal working processing which would, 
hopefully, garner some review from some/any of the users or operator who 
contributed to the development of -08.   For example, in PRE09 I see 
some complexities in how mount points with different schema in different 
DS works that seem unnecessary,  also the recursive case is not 
documented - even if I'm wrong and all that is needed is better 
understanding (by me) or clarification (in the doc),  it still would 
need to addressed as part of normal WG processing.

Lou

>
>> Are you really not
>> willing to live with a compromise that addresses the issue albeit in
>> way that you/some view as suboptimal?
>>
>> Keep in mind that we had lots of discussions on what is
>> optimal/preferred and there are/were different view points on this,
>> compromises were made that increased complexity for others and these
>> were accepted in interest of progressing *any* deployable solution.
> Yes.  I don't want to give up these compromises.  I know that others
> want to, and/or explore other solutions.  That's *not* what I'm
> proposing.
>
>
> /martin
>
>
>
>> Lou
>>
>> [1]
>> https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod
>>
>> On 2/23/2018 4:36 AM, Martin Bjorklund wrote:
>>> Hi,
>>>
>>> Robert Wilton  wrote:
>>>> Hi Lou,
>>>>
>>>> I think that this solution is inferior to the model presented in
>>>> pre-09.
>>> I agree.  Servers that are NMDA-compliant, or implements YANG Library
>>> bis will have to present schemas in two different structures,
>>> depending on where the schema is used, and clients will have to code
>>> for both.  With the solution in pre-09, there is just one structure.
>>> A single structure also has other benefits (apart from being simpler),
>>> e.g., if we augment it with the meta data that has been discussed
>>> recently, we can augment a single structure.
>>>
>>>
>>> /martin
>>>
>>>
>>>
>>>> I would prefer that we publish pre09 instead, potentially including
>>>> the -08 model in the appendix if that helps progress the document in a
>>>> more expedient fashion.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> On 22/02/2018 16:18, Lou Berger wrote:
>>>>> Hi,
>>>>>
>>>>> (I have a bunch of different roles WRT this work.  This mail is being
>>>>> sent as an individual - as chair, I fully support the previous chair
>>>>> statements on this draft.)
>>>>>
>>>>> Chris and I have come up with a proposal on how to provide full NMDA
>>>>> as part the existing schema-mount module.  Our motivation was to
>>>>> enable full NMDA support with *minimal* change to the model and
>>>>> disruption to the LC'ed work.  The key NMDA limitation, with -08, that
>>>>> we are aiming to address is the ability to support different mounted
>>>>> schema in different datastores for non-inline mount points. (See more
>>>>> detailed description below if interested full nuances of limitations
>>>>> of -08)
>>>>>
>>>>> What we came up with was  to simply add a (leaf)list to identify in
>>>>> which datastores a
>>>>> schema-mount schema is valid/present. This is somewhat similar to
>>>>> YL-bis schema/module-set. Specifically we're proposing (see below for
>>>>> full tree below):
>>>>>
>>>>>              +--ro schema* [name]
>>>>>                 +--ro name           string
>>>>> ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}
>>>>>
>>>>> This approach has the advantages of supporting different mounted
>>>>> schema in different DSes, working with both NMDA and non-NMDA
>>>>> implementations, supporting all of the extensively discussed features
>>>>> of schema mount (including recursive mounts), and having minor/scoped
>>>>> impact on all dependent work.  The main downside is that it isn't the
>>>>> most optimal/compact solution possible if we were to base this work on
>>>>> YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from all
>>>>> perspectives, but it is what was agreed to as sufficient by those who
>>>>> contribute to the WG discussion.
>>>>>
>>>>> In short, we see this as a solution to  addresses the raised last call
>>>>> issue with the minimal impact on -08 and dependent work -- which is
>>>>> what is appropriate given where we are in the process.
>>>>>
>>>>> So our/my question really is:
>>>>>
>>>>>       Is this a solution that you/all can live with?
>>>>>
>>>>> Note: optimization, design preference and perfect alignment with use
>>>>> or YL-bis are not part of our question as we both don't think that is
>>>>> the right question given where we are in the WG process.
>>>>>
>>>>> Lou (with ideas developed with Chris, and chair hat off)
>>>>>
>>>>> ======
>>>>> Details -- for those who want
>>>>> ======
>>>>> As background, my understanding/view is that the -08 version of the
>>>>> both NMDA and non-NMDA supporting implementations, but there are
>>>>> limitations in its NMDA applicability. Used with Yang Library,
>>>>> [rfc7895], only non-NMDA implementations can be supported.  When used
>>>>> with the revised Yang Library defined in
>>>>> [I.D.ietf-netconf-rfc7895bis-],  NMDA implementations  can be
>>>>> supported with certain limitations. Specifically, this document
>>>>> requires use of the now deprecated module-list grouping, and the same
>>>>> schema represented in schema list of the Schema Mount module MUST be
>>>>> used in all datastores.  Inline type mount points, which don't use the
>>>>> schema list,  can support different schema in different data stores
>>>>> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>>>> YANG library under the inline mount point.
>>>>>
>>>>>       module: ietf-yang-schema-mount
>>>>>           +--ro schema-mounts
>>>>>              +--ro namespace* [prefix]
>>>>>              |  +--ro prefix    yang:yang-identifier
>>>>>              |  +--ro uri?      inet:uri
>>>>>              +--ro mount-point* [module name]
>>>>>              |  +--ro module        yang:yang-identifier
>>>>>              |  +--ro name          yang:yang-identifier
>>>>>              |  +--ro config?       boolean
>>>>>              |  +--ro (schema-ref)?
>>>>>              |     +--:(inline)
>>>>>              |     |  +--ro inline?       empty
>>>>>              |     +--:(use-schema)
>>>>>              |        +--ro use-schema* [name]
>>>>>              |           +--ro name
>>>>>              |           |       -> /schema-mounts/schema/name
>>>>>              |           +--ro parent-reference*   yang:xpath1.0
>>>>>              +--ro schema* [name]
>>>>>                 +--ro name           string
>>>>> ADD          +--ro datastore*    ds:datastore-ref {revised-datastores}
>>>>>                 +--ro module* [name revision]
>>>>>                 |  +--ro name                yang:yang-identifier
>>>>>                 |  +--ro revision            union
>>>>>                 |  +--ro schema?             inet:uri
>>>>>                 |  +--ro namespace           inet:uri
>>>>>                 |  +--ro feature*            yang:yang-identifier
>>>>>                 |  +--ro deviation* [name revision]
>>>>>                 |  |  +--ro name        yang:yang-identifier
>>>>>                 |  |  +--ro revision    union
>>>>>                 |  +--ro conformance-type    enumeration
>>>>>                 |  +--ro submodule* [name revision]
>>>>>                 |     +--ro name        yang:yang-identifier
>>>>>                 |     +--ro revision    union
>>>>>                 |     +--ro schema?     inet:uri
>>>>>                 +--ro mount-point* [module name]
>>>>>                    +--ro module        yang:yang-identifier
>>>>>                    +--ro name          yang:yang-identifier
>>>>>                    +--ro config?       boolean
>>>>>                    +--ro (schema-ref)?
>>>>>                       +--:(inline)
>>>>>                       |  +--ro inline?       empty
>>>>>                       +--:(use-schema)
>>>>>                          +--ro use-schema* [name]
>>>>>                             +--ro name
>>>>>                             |       -> /schema-mounts/schema/name
>>>>>                             +--ro parent-reference*   yang:xpath1.0
>>>>>
>>>>> We would expect that the revised-datastores feature would be used
>>>>> (perhaps required) for any implementation that supports
>>>>> ietf-datastores
>>>>> and yl-bis.
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Fri Feb 23 06:03:21 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BE82612E6D7 for ; Fri, 23 Feb 2018 06:03:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b5GzJ-MkXCVg for ; Fri, 23 Feb 2018 06:03:13 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6F83112706D for ; Fri, 23 Feb 2018 06:03:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=13509; q=dns/txt; s=iport; t=1519394592; x=1520604192; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=iUHWgF+Dkauv8wbCLAl+YkuUGoyiEvGSd1xZLckOOY0=; b=e1t3bP4a5wXv7b8/oRnttCR0SjS/5puloK5SWUNXnCfAqE1k5f115UdU 6WiecCDY8ZPalHRoSoUkHDlTXFKeUI+poyHfc0Tk6G6cvjT/95MYxMjnr vZQMZcCWj7vrWAo2gfe4YxvcdJfmp7dbzf4KpdV3pZGqNhHKBtpiXDmzw 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B2AQDjHpBa/xbLJq1SCgEYAQEBAQEBA?= =?us-ascii?q?QEBAQEBBwEBAQEBgyKBE3Aog2iLGY5jJ4EWllGCFgoYDYQ/TwKDDRcBAgEBAQE?= =?us-ascii?q?BAQJrKIUjAQEBAwEBASEECwEFNhsJAg4KAgImAgInMAYBDAYCAQEXigAIEI1hn?= =?us-ascii?q?XSBbTqFAIN3gh4BAQEBAQEBAwEBAQEBAQEBAQEBGAWBD4QJg36BZikMgWqBDoM?= =?us-ascii?q?uAQEDgUMLAQEIFoMXgmUFklaRbAmIKY1ngh+GKYNyJodljg2CAYRlgziBPCABN?= =?us-ascii?q?4FRMxoIGxU6gkODegECeAFBN4oSgj4BAQE?=
X-IronPort-AV: E=Sophos;i="5.47,383,1515456000";  d="scan'208";a="2253615"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-2.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 23 Feb 2018 14:03:06 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1NE35r3023797; Fri, 23 Feb 2018 14:03:05 GMT
To: Lou Berger , Martin Bjorklund , netmod@ietf.org
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net> <20180223.135509.1022283362077802966.mbj@tail-f.com> 
From: Robert Wilton 
Message-ID: <8760c49e-1304-0d55-6e38-004dfaca570c@cisco.com>
Date: Fri, 23 Feb 2018 14:03:05 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 14:03:16 -0000

Hi Lou,

I also don't agree that this is a rewrite of the draft.  My view is that 
it is really just an obvious simplification of the YANG module given the 
YLbis work.

For the use-schema version, the -08 version splits the *same* YANG 
library information into two separate places depending on whether it is 
mounted at the root, or below.  The PRE-09 version says that a root 
schema and a mounted schema are really the same thing and should be 
handled in exactly the same way.


On 23/02/2018 13:18, Lou Berger wrote:
> Martin,
>
>
> On 2/23/2018 7:55 AM, Martin Bjorklund wrote:
>> Hi,
>>
>> Lou Berger  wrote:
>>> Martin/Rob,
>>>
>>>      Back when the topic was raised for the first time publicly
>>> (Yokahama) and discussed in the WG [1] *any* solution would have been
>>> workable.  At this point > 2 years later, do you really think it is
>>> reasonable to do a rewrite of the solution ?
>> I don't agree that this is a rewrite of the solution.  I want to keep
>> the mountpoint statement.  I want to keep the two mechanisms inline
>> and use-schema.  The only change we're talking about is alinging the
>> read-only data that the server makes available with YLbis.
> The requirement to use YL-bis is enough for me classifying the change 
> as a rewrite.  The current draft is usable with both RFC7895 and 
> YL-bis.  This is a pretty major change, particularly for anyone 
> working on a client or server implementation now, or who wants to soon.
If semantic versioning, or other stuff (e.g. server/datastore 
capabilities) gets augmented into YLbis then that should just work with 
the pre-09 version, with no further changes.  This will not necessarily 
be the case with the -08 version because it will be using deprecated 
groupings, those deprecated groupings would need to be updated or it 
would force a new version of the SM YANG module.

To support pre NMDA implementations, I see that the solution should be 
the same as all other current YANG model drafts, i.e. if necessary, we 
publish a pre NMDA version of the YANG module in the appendix that works 
with existing implementations.  In this case I would use the model in 
the -08 version, put them both in different namespaces and label them 
clearly.

>
>>   This is
>> quite trivial.
> From *your* perspective.  There are other's that disagree (See Dean's 
> and Chris' mail - they don't want *any* changes and are perfectly 
> happy with -08).
>
>>   We have documented this in the pre09 branch, and this
>> is imo ready to be published.
> It would still need to go through normal working processing which 
> would, hopefully, garner some review from some/any of the users or 
> operator who contributed to the development of -08.   For example, in 
> PRE09 I see some complexities in how mount points with different 
> schema in different DS works that seem unnecessary, also the recursive 
> case is not documented - even if I'm wrong and all that is needed is 
> better understanding (by me) or clarification (in the doc),  it still 
> would need to addressed as part of normal WG processing.
Please can you elaborate, or provide an example of the perceived 
different schema in different datastore complexity.

For the recursive mount case, Juergen has previously posted a useful 
diagram that shows how the -09 model fits with YLbis, that I think would 
be a useful addition.

Perhaps a second WG LC would be sufficient?

>
> Lou
>
>>
>>> Are you really not
>>> willing to live with a compromise that addresses the issue albeit in
>>> way that you/some view as suboptimal?
I think that the YLbis based version is significantly simpler than what 
you/Chris proposed.  If we can't ship a YLbis version now then I prefer 
that the -08 version has no support for NMDA based servers and we 
immediately start SMbis using the YLbis version (i.e. not backwards 
compatible).

I also think that longer term schema mount will end up with a lot more 
usage, which is why I want the -09 model published.

Thanks,
Rob


>>>
>>> Keep in mind that we had lots of discussions on what is
>>> optimal/preferred and there are/were different view points on this,
>>> compromises were made that increased complexity for others and these
>>> were accepted in interest of progressing *any* deployable solution.
>> Yes.  I don't want to give up these compromises.  I know that others
>> want to, and/or explore other solutions.  That's *not* what I'm
>> proposing.
>>
>>
>> /martin
>>
>>
>>
>>> Lou
>>>
>>> [1]
>>> https://datatracker.ietf.org/meeting/interim-2016-netmod-01/session/netmod 
>>>
>>>
>>> On 2/23/2018 4:36 AM, Martin Bjorklund wrote:
>>>> Hi,
>>>>
>>>> Robert Wilton  wrote:
>>>>> Hi Lou,
>>>>>
>>>>> I think that this solution is inferior to the model presented in
>>>>> pre-09.
>>>> I agree.  Servers that are NMDA-compliant, or implements YANG Library
>>>> bis will have to present schemas in two different structures,
>>>> depending on where the schema is used, and clients will have to code
>>>> for both.  With the solution in pre-09, there is just one structure.
>>>> A single structure also has other benefits (apart from being simpler),
>>>> e.g., if we augment it with the meta data that has been discussed
>>>> recently, we can augment a single structure.
>>>>
>>>>
>>>> /martin
>>>>
>>>>
>>>>
>>>>> I would prefer that we publish pre09 instead, potentially including
>>>>> the -08 model in the appendix if that helps progress the document 
>>>>> in a
>>>>> more expedient fashion.
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On 22/02/2018 16:18, Lou Berger wrote:
>>>>>> Hi,
>>>>>>
>>>>>> (I have a bunch of different roles WRT this work.  This mail is 
>>>>>> being
>>>>>> sent as an individual - as chair, I fully support the previous chair
>>>>>> statements on this draft.)
>>>>>>
>>>>>> Chris and I have come up with a proposal on how to provide full NMDA
>>>>>> as part the existing schema-mount module.  Our motivation was to
>>>>>> enable full NMDA support with *minimal* change to the model and
>>>>>> disruption to the LC'ed work.  The key NMDA limitation, with -08, 
>>>>>> that
>>>>>> we are aiming to address is the ability to support different mounted
>>>>>> schema in different datastores for non-inline mount points. (See 
>>>>>> more
>>>>>> detailed description below if interested full nuances of limitations
>>>>>> of -08)
>>>>>>
>>>>>> What we came up with was  to simply add a (leaf)list to identify in
>>>>>> which datastores a
>>>>>> schema-mount schema is valid/present. This is somewhat similar to
>>>>>> YL-bis schema/module-set. Specifically we're proposing (see below 
>>>>>> for
>>>>>> full tree below):
>>>>>>
>>>>>>              +--ro schema* [name]
>>>>>>                 +--ro name           string
>>>>>> ADD          +--ro datastore*    ds:datastore-ref 
>>>>>> {revised-datastores}
>>>>>>
>>>>>> This approach has the advantages of supporting different mounted
>>>>>> schema in different DSes, working with both NMDA and non-NMDA
>>>>>> implementations, supporting all of the extensively discussed 
>>>>>> features
>>>>>> of schema mount (including recursive mounts), and having 
>>>>>> minor/scoped
>>>>>> impact on all dependent work.  The main downside is that it isn't 
>>>>>> the
>>>>>> most optimal/compact solution possible if we were to base this 
>>>>>> work on
>>>>>> YL-bis/pre09 draft.  Of course -08 isn't necessarily optimal from 
>>>>>> all
>>>>>> perspectives, but it is what was agreed to as sufficient by those 
>>>>>> who
>>>>>> contribute to the WG discussion.
>>>>>>
>>>>>> In short, we see this as a solution to  addresses the raised last 
>>>>>> call
>>>>>> issue with the minimal impact on -08 and dependent work -- which is
>>>>>> what is appropriate given where we are in the process.
>>>>>>
>>>>>> So our/my question really is:
>>>>>>
>>>>>>       Is this a solution that you/all can live with?
>>>>>>
>>>>>> Note: optimization, design preference and perfect alignment with use
>>>>>> or YL-bis are not part of our question as we both don't think 
>>>>>> that is
>>>>>> the right question given where we are in the WG process.
>>>>>>
>>>>>> Lou (with ideas developed with Chris, and chair hat off)
>>>>>>
>>>>>> ======
>>>>>> Details -- for those who want
>>>>>> ======
>>>>>> As background, my understanding/view is that the -08 version of the
>>>>>> both NMDA and non-NMDA supporting implementations, but there are
>>>>>> limitations in its NMDA applicability. Used with Yang Library,
>>>>>> [rfc7895], only non-NMDA implementations can be supported.  When 
>>>>>> used
>>>>>> with the revised Yang Library defined in
>>>>>> [I.D.ietf-netconf-rfc7895bis-],  NMDA implementations can be
>>>>>> supported with certain limitations. Specifically, this document
>>>>>> requires use of the now deprecated module-list grouping, and the 
>>>>>> same
>>>>>> schema represented in schema list of the Schema Mount module MUST be
>>>>>> used in all datastores.  Inline type mount points, which don't 
>>>>>> use the
>>>>>> schema list,  can support different schema in different data stores
>>>>>> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>>>>> YANG library under the inline mount point.
>>>>>>
>>>>>>       module: ietf-yang-schema-mount
>>>>>>           +--ro schema-mounts
>>>>>>              +--ro namespace* [prefix]
>>>>>>              |  +--ro prefix    yang:yang-identifier
>>>>>>              |  +--ro uri?      inet:uri
>>>>>>              +--ro mount-point* [module name]
>>>>>>              |  +--ro module        yang:yang-identifier
>>>>>>              |  +--ro name          yang:yang-identifier
>>>>>>              |  +--ro config?       boolean
>>>>>>              |  +--ro (schema-ref)?
>>>>>>              |     +--:(inline)
>>>>>>              |     |  +--ro inline?       empty
>>>>>>              |     +--:(use-schema)
>>>>>>              |        +--ro use-schema* [name]
>>>>>>              |           +--ro name
>>>>>>              |           |       -> /schema-mounts/schema/name
>>>>>>              |           +--ro parent-reference* yang:xpath1.0
>>>>>>              +--ro schema* [name]
>>>>>>                 +--ro name           string
>>>>>> ADD          +--ro datastore*    ds:datastore-ref 
>>>>>> {revised-datastores}
>>>>>>                 +--ro module* [name revision]
>>>>>>                 |  +--ro name yang:yang-identifier
>>>>>>                 |  +--ro revision            union
>>>>>>                 |  +--ro schema?             inet:uri
>>>>>>                 |  +--ro namespace           inet:uri
>>>>>>                 |  +--ro feature* yang:yang-identifier
>>>>>>                 |  +--ro deviation* [name revision]
>>>>>>                 |  |  +--ro name yang:yang-identifier
>>>>>>                 |  |  +--ro revision    union
>>>>>>                 |  +--ro conformance-type    enumeration
>>>>>>                 |  +--ro submodule* [name revision]
>>>>>>                 |     +--ro name yang:yang-identifier
>>>>>>                 |     +--ro revision    union
>>>>>>                 |     +--ro schema?     inet:uri
>>>>>>                 +--ro mount-point* [module name]
>>>>>>                    +--ro module yang:yang-identifier
>>>>>>                    +--ro name yang:yang-identifier
>>>>>>                    +--ro config?       boolean
>>>>>>                    +--ro (schema-ref)?
>>>>>>                       +--:(inline)
>>>>>>                       |  +--ro inline?       empty
>>>>>>                       +--:(use-schema)
>>>>>>                          +--ro use-schema* [name]
>>>>>>                             +--ro name
>>>>>>                             |       -> /schema-mounts/schema/name
>>>>>>                             +--ro parent-reference* yang:xpath1.0
>>>>>>
>>>>>> We would expect that the revised-datastores feature would be used
>>>>>> (perhaps required) for any implementation that supports
>>>>>> ietf-datastores
>>>>>> and yl-bis.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>
> .
>


From nobody Fri Feb 23 06:36:58 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 679E0124D6C for ; Fri, 23 Feb 2018 06:36:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_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 6PRiynB6MBgj for ; Fri, 23 Feb 2018 06:36:56 -0800 (PST)
Received: from gproxy7-pub.mail.unifiedlayer.com (gproxy7-pub.mail.unifiedlayer.com [70.40.196.235]) (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 5730E12025C for ; Fri, 23 Feb 2018 06:36:56 -0800 (PST)
Received: from CMOut01 (unknown [10.0.90.82]) by gproxy7.mail.unifiedlayer.com (Postfix) with ESMTP id E4A6A215E73 for ; Fri, 23 Feb 2018 07:36:55 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by CMOut01 with  id EEcs1x00C2SSUrH01EcvrX; Fri, 23 Feb 2018 07:36:55 -0700
X-Authority-Analysis: v=2.2 cv=ft6sXBwf c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=kj9zAlcOel0A:10 a=Op4juWPpsa0A:10 a=I-qAevugAchz5BOPSqUA:9 a=CjuIK1q_8ugA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Subject: References:In-Reply-To:Message-ID:Date:To:From:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=Xu39Sg/MESEwOU8nfZZgNb79BuKWwFwho1qOfSlQY5g=; b=R41DrA/XyPWTDSdaDyJ5U4EFj5 kwryx2SUidyEyOBdgGZenoBuZWvFP1BxEY2XqNfIsEDUjAh1EBRjuQW3Ymw6PAo8oKGwjKPztEVQM 3kfIU6fJxzLGmkfyTK/e1UTxR;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:38049 helo=[192.168.2.236]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1epESx-002wot-Vl; Fri, 23 Feb 2018 07:36:52 -0700
From: Lou Berger 
To: Robert Wilton , Martin Bjorklund , 
Date: Fri, 23 Feb 2018 09:36:50 -0500
Message-ID: <161c3185fd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
In-Reply-To: <8760c49e-1304-0d55-6e38-004dfaca570c@cisco.com>
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net> <20180223.135509.1022283362077802966.mbj@tail-f.com>  <8760c49e-1304-0d55-6e38-004dfaca570c@cisco.com>
User-Agent: AquaMail/1.13.2-730 (build: 101300200)
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="us-ascii"
Content-Transfer-Encoding: 8bit
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1epESx-002wot-Vl
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([192.168.2.236]) [100.15.86.101]:38049
X-Source-Auth: lberger@labn.net
X-Email-Count: 1
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 14:36:57 -0000

Rob,

I think we're going in circles here. We have one camp that wants to replace 
the current module with pre 09 and is unwilling to discuss compromise, and 
another camp that wants 08 published as is and has been waiting for the 
working group and authors to submit aversion to the IESG for publication 
based on the last call that completed in November.

The mail I sent that started this thread was sent with the hope of finding 
a compromise. As you and Martin seem uninterested in discussing a 
compromise, I not sure if it's worth pursuing this thread. If I have 
misread your mails, and you are open to compromise then we should continue 
this thread.

If not and there is no interest in finding a compromise in the working 
group and by the authors, I guess we're back to the plan of publishing 08 
and looking forward to protests.

Lou




From nobody Fri Feb 23 06:52:47 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 579D51270A3 for ; Fri, 23 Feb 2018 06:52:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Q7tJn7BJsNzP for ; Fri, 23 Feb 2018 06:52:44 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B686F12E86A for ; Fri, 23 Feb 2018 06:52:42 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1533; q=dns/txt; s=iport; t=1519397562; x=1520607162; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=B/4o2Ku5lEc7igaxL8af81cpfMSuq8fx8sB6wLT2pXQ=; b=E2++YXN4AT7h+AOUuwsIE7W8KZi6kZ0xb9xupzzdLCPmJkqnACFPXr3W uOkPoKdJc5ClSOdGCzWZHOuAaM4ZirqD8NZrR0WrgKVXwjfHGTy/7kkOG 5CYBmn+FRkgD5WB9jkmNoMNQIBzRnsVBAr0oR3BytHGWyyvZHLkWS1H7d A=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0B0AQAKKZBa/xbLJq1cGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUlhBCLGY5jJ4EWmGcKhTMCgxAUAQIBAQEBAQECayiFJAEFIw8?= =?us-ascii?q?BBVELDgoCAiYCAlcGAQwIAQEXigirXoInhQCDd4IeAQEBAQEBAQMBAQEBAQEBA?= =?us-ascii?q?SCBD4QJg36BZikMgniFAQEBgzWCZQWkQgmWEIw6iAuQDogdgTw2IoFRMxoIGxW?= =?us-ascii?q?CfoR1QYpJgj4BAQE?=
X-IronPort-AV: E=Sophos;i="5.47,383,1515456000";  d="scan'208";a="2207663"
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; 23 Feb 2018 14:52:40 +0000
Received: from [10.63.23.131] (dhcp-ensft1-uk-vla370-10-63-23-131.cisco.com [10.63.23.131]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1NEqe47008815; Fri, 23 Feb 2018 14:52:40 GMT
To: Lou Berger , Martin Bjorklund , netmod@ietf.org
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net> <20180223.135509.1022283362077802966.mbj@tail-f.com>  <8760c49e-1304-0d55-6e38-004dfaca570c@cisco.com> <161c3185fd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
From: Robert Wilton 
Message-ID: <145a8313-f649-9519-54d0-73726ece2a36@cisco.com>
Date: Fri, 23 Feb 2018 14:52:40 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <161c3185fd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 14:52:46 -0000

Hi Lou,

As per my public emails on this WG alias, and also private emails, you 
must know that both Martin, I, and others have been trying (for many 
weeks) to reach a compromise.

I don't think that it is that I am unwilling to compromise, but more 
that I perceive that a different compromise solution is the right one.  
I.e. we publish a single draft that contains the model that you want now 
for pre NMDA solutions, and also a model that we think will work well in 
the post NMDA world that all of the IETF YANG models are moving to.

Thanks,
Rob


On 23/02/2018 14:36, Lou Berger wrote:
> Rob,
>
> I think we're going in circles here. We have one camp that wants to 
> replace the current module with pre 09 and is unwilling to discuss 
> compromise, and another camp that wants 08 published as is and has 
> been waiting for the working group and authors to submit aversion to 
> the IESG for publication based on the last call that completed in 
> November.
>
> The mail I sent that started this thread was sent with the hope of 
> finding a compromise. As you and Martin seem uninterested in 
> discussing a compromise, I not sure if it's worth pursuing this 
> thread. If I have misread your mails, and you are open to compromise 
> then we should continue this thread.
>
> If not and there is no interest in finding a compromise in the working 
> group and by the authors, I guess we're back to the plan of publishing 
> 08 and looking forward to protests.
>
> Lou
>
>
>
> .
>


From nobody Fri Feb 23 06:55:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 42DA6127058 for ; Fri, 23 Feb 2018 06:55:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FCIAvlgK-y2F for ; Fri, 23 Feb 2018 06:55:33 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 023F9124D6C for ; Fri, 23 Feb 2018 06:55:33 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 5FC341820412; Fri, 23 Feb 2018 15:52:41 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 1D71218203F6; Fri, 23 Feb 2018 15:52:38 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , Lou Berger , NetMod WG 
In-Reply-To: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com>
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com>
Mail-Followup-To: Robert Wilton , Lou Berger , NetMod WG 
Date: Fri, 23 Feb 2018 15:55:28 +0100
Message-ID: <87a7vzycv3.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 14:55:36 -0000

Robert Wilton  writes:

> Hi Lou,
>
> I think that this solution is inferior to the model presented in
> pre-09.

If the choice is between pre-09 and Lou's new proposal, then I strongly
prefer pre-09.

That said, I must also add that I am still not happy with pre-09: I
believe the "schema-ref" choice is an unnecessary complication - the
"inline" mounts needn't interact at all with the YANG library of the
parent tree.

>
> I would prefer that we publish pre09 instead, potentially including the=20
> -08 model in the appendix if that helps progress the document in a more=20
> expedient fashion.

I don't agree with including such an appendix, it would only confuse the
readers.

Lada

>
> Thanks,
> Rob
>
>
> On 22/02/2018 16:18, Lou Berger wrote:
>> Hi,
>>
>> (I have a bunch of different roles WRT this work.=C2=A0 This mail is bei=
ng=20
>> sent as an individual - as chair, I fully support the previous chair=20
>> statements on this draft.)
>>
>> Chris and I have come up with a proposal on how to provide full NMDA=20
>> as part the existing schema-mount module.=C2=A0 Our motivation was to=20
>> enable full NMDA support with *minimal* change to the model and=20
>> disruption to the LC'ed work.=C2=A0 The key NMDA limitation, with -08, t=
hat=20
>> we are aiming to address is the ability to support different mounted=20
>> schema in different datastores for non-inline mount points. (See more=20
>> detailed description below if interested full nuances of limitations=20
>> of -08)
>>
>> What we came up with was=C2=A0 to simply add a (leaf)list to identify in=
=20
>> which datastores a
>> schema-mount schema is valid/present. This is somewhat similar to=20
>> YL-bis schema/module-set. Specifically we're proposing (see below for=20
>> full tree below):
>>
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schem=
a* [name]
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 string
>> ADD=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro datastor=
e*=C2=A0=C2=A0=C2=A0 ds:datastore-ref {revised-datastores}
>>
>> This approach has the advantages of supporting different mounted=20
>> schema in different DSes, working with both NMDA and non-NMDA=20
>> implementations, supporting all of the extensively discussed features=20
>> of schema mount (including recursive mounts), and having minor/scoped=20
>> impact on all dependent work.=C2=A0 The main downside is that it isn't t=
he=20
>> most optimal/compact solution possible if we were to base this work on=20
>> YL-bis/pre09 draft.=C2=A0 Of course -08 isn't necessarily optimal from a=
ll=20
>> perspectives, but it is what was agreed to as sufficient by those who=20
>> contribute to the WG discussion.
>>
>> In short, we see this as a solution to=C2=A0 addresses the raised last c=
all=20
>> issue with the minimal impact on -08 and dependent work -- which is=20
>> what is appropriate given where we are in the process.
>>
>> So our/my question really is:
>>
>> =C2=A0=C2=A0=C2=A0 Is this a solution that you/all can live with?
>>
>> Note: optimization, design preference and perfect alignment with use=20
>> or YL-bis are not part of our question as we both don't think that is=20
>> the right question given where we are in the WG process.
>>
>> Lou (with ideas developed with Chris, and chair hat off)
>>
>> =3D=3D=3D=3D=3D=3D
>> Details -- for those who want
>> =3D=3D=3D=3D=3D=3D
>> As background, my understanding/view is that the -08 version of the=20
>> both NMDA and non-NMDA supporting implementations, but there are=20
>> limitations in its NMDA applicability. Used with Yang Library,=20
>> [rfc7895], only non-NMDA implementations can be supported.=C2=A0 When us=
ed=20
>> with the revised Yang Library defined in=20
>> [I.D.ietf-netconf-rfc7895bis-],=C2=A0 NMDA implementations=C2=A0 can be=
=20
>> supported with certain limitations. Specifically, this document=20
>> requires use of the now deprecated module-list grouping, and the same=20
>> schema represented in schema list of the Schema Mount module MUST be=20
>> used in all datastores.=C2=A0 Inline type mount points, which don't use =
the=20
>> schema list,=C2=A0 can support different schema in different data stores=
=20
>> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of=20
>> YANG library under the inline mount point.
>>
>> =C2=A0=C2=A0=C2=A0 module: ietf-yang-schema-mount
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema-mounts
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro names=
pace* [prefix]
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--=
ro prefix=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--=
ro uri?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro mount=
-point* [module name]
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--=
ro module=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--=
ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-ide=
ntifier
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--=
ro config?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 boolean
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--=
ro (schema-ref)?
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0 +--:(inline)
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0 |=C2=A0 +--ro inline?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 e=
mpty
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0 +--:(use-schema)
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro use-schema* [name]
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 -> /schema-mounts/schema/name
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro parent-reference*=
=C2=A0=C2=A0 yang:xpath1.0
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schem=
a* [name]
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 string
>> ADD=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro datastor=
e*=C2=A0=C2=A0=C2=A0 ds:datastore-ref {revised-datastores}
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =C2=
=A0 +--ro module* [name revision]
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 union
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 inet:uri
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 +--ro namespace=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 inet:uri
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 +--ro feature*=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0 yang:yang-identifier
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 +--ro deviation* [name revision]
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 |=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
 yang:yang-identifier
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 |=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0 union
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 +--ro conformance-type=C2=A0=C2=A0=C2=A0 enumeration
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0 +--ro submodule* [name revision]
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0 yang:yang-identifier
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro revision=C2=A0=C2=A0=C2=A0 union
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 |=C2=A0=C2=A0=C2=A0=C2=A0 +--ro schema?=C2=A0=C2=A0=C2=A0=C2=A0 inet=
:uri
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 +--ro mount-point* [module name]
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +--ro module=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0 yang:yang-identifier
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +--ro name=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0 yang:yang-identifier
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +--ro config?=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 =
boolean
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0 +--ro (schema-ref)?
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(inline)
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 |=C2=A0 +--ro inline?=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0 empty
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--:(use-schema)
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 +--ro use-sche=
ma* [name]
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 +--ro name
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 |=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 -> /schema-mounts/schema/name
>> =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0 +--ro parent-reference*=C2=A0=C2=A0 yang:xpath1.0
>>
>> We would expect that the revised-datastores feature would be used
>> (perhaps required) for any implementation that supports ietf-datastores
>> and yl-bis.
>>
>>
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Fri Feb 23 07:28:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EC1E21270A3; Fri, 23 Feb 2018 07:28:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZX1jNUJ0qEaN; Fri, 23 Feb 2018 07:28:12 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 8A7FB126D05; Fri, 23 Feb 2018 07:28:12 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1NFP6WH026480; Fri, 23 Feb 2018 07:28:10 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=UhdvVXSUmD+0107eQDKV0tOeNUw/SgdIVvPSZk1kFrc=; b=Rts+ZyEpIWtvrdZC6jgsNLy+lN80esoNuSomAxjvd3DktCgGJ/XLk7DnYrulivUAVOxF AQbfC/fhD/SOlmIwv5e4iW+AqhrpmuwuqbF6PF1ykdD6FKFtthAKf9iNdNgGJq/Dp6cZ /HqXZ9D06vJfXAlOZnt6iBWX8XUpr3KrdbioymvcTxJ0Mu2CS+gA4pAqBDTMqet6JKS1 8vUYZn+1p3xzAgVcAmvGC8uUwyEiKSs0yxFLvArzAWOPfUzuZSUCFVJtSft8Am+xE+FU gdql4zOf8DYO15SBcp8qVhygZfSQtUPDrZs81cZUfdQ5cmTlGdNXQZ29XLLqmkXjzUnh qg== 
Received: from nam03-dm3-obe.outbound.protection.outlook.com (mail-dm3nam03lp0019.outbound.protection.outlook.com [207.46.163.19]) by mx0a-00273201.pphosted.com with ESMTP id 2gangk00fc-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Feb 2018 07:28:10 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3452.namprd05.prod.outlook.com (10.174.240.139) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.6; Fri, 23 Feb 2018 15:28:08 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b%3]) with mapi id 15.20.0548.005; Fri, 23 Feb 2018 15:28:08 +0000
From: Kent Watsen 
To: "Gary Wu (garywu)" , Yaron Sheffer , "Clyde Wildes (cwildes)" 
CC: "draft-ietf-netmod-syslog-model.all@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
Thread-Index: AQHTqMUaxzdr5H1LmU6r4TNVjLpgwKOsOFkAgAAftgCAAv3XgIACeo4A
Date: Fri, 23 Feb 2018 15:28:07 +0000
Message-ID: 
References: <151896425742.27914.9664814474838013064@ietfa.amsl.com> <6E582464-6EDB-4D55-9E8B-BEC68929DF9A@cisco.com> <4694018c-0be5-e78c-38ed-8745da01d019@gmail.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.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3452; 7:PUuw7Dx/T37iQmi2OfcB9+pw73kmEftuyos4iidqW8pDLFX4enMp9LNIn2/65YG7f8CnRjqrQB0d/d2EtDxO70np7sdU4ZGze+LXQy6CeUB5NlphgPT1eUrDuCXVP8eoX00MqGJhEdRb4Y+zQL7VORPEGHm//qZS/vH+8wr5iqZqgUZ20cPX5nqsMDDpHMTeQQ++fD/Fo5a+C/nmAK+5wvqrwmzTtJFSnkobeeDX95tlHN/YGlL6d67Mij0cFLQk
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 03763c01-941b-46da-35e4-08d57ad20a7b
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3452; 
x-ms-traffictypediagnostic: DM5PR05MB3452:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(192374486261705);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001082)(6040501)(2401047)(5005006)(8121501046)(3002001)(10201501046)(93006095)(93001095)(3231166)(944501161)(6055026)(6041288)(20161123564045)(20161123560045)(20161123562045)(20161123558120)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR05MB3452; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3452; 
x-forefront-prvs: 0592A9FDE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(366004)(396003)(39380400002)(39860400002)(346002)(376002)(199004)(189003)(54906003)(110136005)(6436002)(6346003)(2950100002)(7736002)(59450400001)(86362001)(305945005)(36756003)(6512007)(81166006)(53936002)(4326008)(14454004)(26005)(81156014)(33656002)(3846002)(76176011)(6506007)(93886005)(2906002)(106356001)(6486002)(478600001)(8936002)(229853002)(25786009)(5250100002)(8676002)(6116002)(102836004)(97736004)(186003)(5660300001)(99286004)(316002)(6246003)(82746002)(39060400002)(3660700001)(105586002)(83716003)(3280700002)(68736007)(66066001)(58126008)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3452; H:DM5PR05MB3484.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)
x-microsoft-antispam-message-info: ECRhp5iiNn6ivzYHAsY6pmboHNgsqvtGA7DHt58Uyv1LxfAKsfx4AdiVxwMdeLDiOc96ZwLRLlcqPt2S5jF1Xovbe2PYF2E8r1dfvdRK5dPqvuHDH3Lj+zAUxPdSbWMtkjgWoGrb/P+LsVsbKjHQitvoFPb75jkhDz1inIBJLp8=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: 
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 03763c01-941b-46da-35e4-08d57ad20a7b
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2018 15:28:07.9780 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3452
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-23_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802230191
Archived-At: 
Subject: Re: [netmod] Secdir last call review of draft-ietf-netmod-syslog-model-21
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 15:28:14 -0000

DQoNCiAgICA+ICAgICAgU2VjdXJpdHkgQ29tbWVudHMNCiAgICA+ICAgICAgDQogICAgPiAgICAg
ICogSSB0aGluayBhbG1vc3QgYWxsIHdyaXRhYmxlIGRhdGEgbm9kZXMgaGVyZSBhcmUgc2Vuc2l0
aXZlLCBiZWNhdXNlIGEgbmV0d29yaw0KICAgID4gICAgICBhdHRhY2tlcidzIGZpcnN0IG1vdmUg
aXMgdG8gYmxvY2sgYW55IGxvZ2dpbmcgb24gdGhlIGhvc3QsIGFuZCBtYW55IG9mIHRoZSBkYXRh
DQogICAgPiAgICAgIG5vZGVzIGhlcmUgY2FuIGJlIHVzZWQgZm9yIHRoaXMgcHVycG9zZS4NCiAg
ICA+IA0KICAgID4gW2NsdzFdIEkgd2lsbCByZXdvcmQgdGhlIHNlY3VyaXR5IHNlY3Rpb24gdG8g
aW5jbHVkZSBhbGwgd3JpdGVhYmxlIG5vZGVzIGFzIHNlbnNpdGl2ZS4NCiAgICA+IA0KICAgID4g
ICAgICAqIFJlOiByZWFkYWJsZSBkYXRhIG5vZGVzLCBJJ20gbm90DQogICAgPiAgICAgIHN1cmUg
d2hpY2ggYXJlIHNlbnNpdGl2ZSwgYW5kIHRoZSBkb2N1bWVudCBzaG91bGQgZ2l2ZSBhbiBleGFt
cGxlIG9yIHR3byByYXRoZXINCiAgICA+ICAgICAgdGhhbiBqdXN0IHNheSAic29tZSIuIE90aGVy
d2lzZSB0aGUgc2VjdXJpdHkgYWR2aWNlIGlzIG5vdCBhY3Rpb25hYmxlLiBPbmUNCiAgICA+ICAg
ICAgZXhhbXBsZTogInJlbW90ZSIgc2VjdGlvbnMgbGVhayBpbmZvcm1hdGlvbiBhYm91dCBvdGhl
ciBob3N0cyBpbiB0aGUgbmV0d29yay4NCiAgICA+IA0KICAgID4gW2NsdzFdIFRoaXMgdGV4dCB3
YXMgbGlmdGVkIGZyb20gYW5vdGhlciBtb2RlbC4gSSB3aWxsIHJldmlldyB0aGUgcmVhZGFibGUg
bm9kZXMgYW5kIHVwZGF0ZS4NCiAgICA+IA0KICAgID4gICAgICAqIFdyaXRlIG9wZXJhdGlvbnMu
Li4gY2FuIGhhdmUgYSBuZWdhdGl2ZSBlZmZlY3Qgb24gbmV0d29yayBvcGVyYXRpb25zLiAtIEkg
d291bGQNCiAgICA+ICAgICAgYWRkICJhbmQgb24gbmV0d29yayBzZWN1cml0eSIsIGJlY2F1c2Ug
bG9ncyBhcmUgb2Z0ZW4gdXNlZCB0byBkZXRlY3Qgc2VjdXJpdHkNCiAgICA+ICAgICAgYnJlYWNo
ZXMuDQogICAgPiANCiAgICA+IFtjbHcxXSBJIHdpbGwgYWRkIHRoaXMgcGhyYXNlLg0KICAgID4g
DQoNClRoZSBmYWN0IHRoYXQgdGhlIHN5c2xvZyBkYXRhIG5vZGVzIGFyZSB3cml0ZS1zZW5zaXRp
dmUgY2FuIGJlIG1hZGUgZXhwbGljaXQgaW4NCnRoZSBtb2RlbCBieSBtYWtpbmcgdGhlIHdob2xl
IGNvbmZpZ3VyYXRpb24gdHJlZSBuYWNtOmRlZmF1bHQtZGVueS13cml0ZSwgYW5kDQptYWtpbmcg
cmVhZC1zZW5zaXRpdmUgc3VidHJlZXMgbmFjbTpkZWZhdWx0LWRlbnktYWxsLg0KDQpUaGFua3Ms
DQpHYXJ5IFd1DQoNCg0KPEtFTlQ+IEFncmVlZC4gIFVzdWFsbHkgbXkgbW9kdWxlcyBoYXZlIHRo
ZSBOQUNNIGFubm90YXRpb25zIGFuZCB0aGVuLCBpbiB0aGUNClNlY3VyaXR5IENvbnNpZGVyYXRp
b25zIHNlY3Rpb24sIEknbSBzdXJlIHRvIHBvaW50IHRoZW0gb3V0Lg0KDQoNCksuDQoNCg0KDQoN
Cg==


From nobody Fri Feb 23 07:36:31 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABBCC12D779 for ; Fri, 23 Feb 2018 07:36:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level: 
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_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 8-jfl8WKd4zF for ; Fri, 23 Feb 2018 07:36:28 -0800 (PST)
Received: from gproxy8-pub.mail.unifiedlayer.com (gproxy8-pub.mail.unifiedlayer.com [67.222.33.93]) (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 6C96A127599 for ; Fri, 23 Feb 2018 07:36:28 -0800 (PST)
Received: from cmgw2 (unknown [10.0.90.83]) by gproxy8.mail.unifiedlayer.com (Postfix) with ESMTP id DEC6F1AB159 for ; Fri, 23 Feb 2018 08:36:24 -0700 (MST)
Received: from box313.bluehost.com ([69.89.31.113]) by cmgw2 with  id EFcM1x00M2SSUrH01FcQAV; Fri, 23 Feb 2018 08:36:24 -0700
X-Authority-Analysis: v=2.2 cv=M5g9E24s c=1 sm=1 tr=0 a=h1BC+oY+fLhyFmnTBx92Jg==:117 a=h1BC+oY+fLhyFmnTBx92Jg==:17 a=IkcTkHD0fZMA:10 a=xqWC_Br6kY4A:10 a=Op4juWPpsa0A:10 a=3ws5PubZchckdPC0rB0A:9 a=QEXdDO2ut3YA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=labn.net; s=default; h=Content-Transfer-Encoding:Content-Type:In-Reply-To:MIME-Version :Date:Message-ID:From:References:To:Subject:Sender:Reply-To:Cc:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=icB0mX2gNy+UdVxpWQjK2/vZcBFs14lDU9syjOH82fQ=; b=v3q9Wis4c4OK4jQrmAUPX0Yz+D NOMRdaiVyQ+D2dy235ey0HIVGDZI/EhDdEGDKapgJ/vAnMgcDif6zhypNni/ZF7sNJeH8SznSws5Z qBEuZJVnznQRRBX7J4FE9vj5i;
Received: from pool-100-15-86-101.washdc.fios.verizon.net ([100.15.86.101]:49860 helo=[IPv6:::1]) by box313.bluehost.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.89_1) (envelope-from ) id 1epFOX-003F4a-18; Fri, 23 Feb 2018 08:36:21 -0700
To: Robert Wilton , Martin Bjorklund , netmod@ietf.org
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net> <20180223.135509.1022283362077802966.mbj@tail-f.com>  <8760c49e-1304-0d55-6e38-004dfaca570c@cisco.com> <161c3185fd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <145a8313-f649-9519-54d0-73726ece2a36@cisco.com>
From: Lou Berger 
Message-ID: 
Date: Fri, 23 Feb 2018 10:36:17 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <145a8313-f649-9519-54d0-73726ece2a36@cisco.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - box313.bluehost.com
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-BWhitelist: no
X-Source-IP: 100.15.86.101
X-Exim-ID: 1epFOX-003F4a-18
X-Source: 
X-Source-Args: 
X-Source-Dir: 
X-Source-Sender: pool-100-15-86-101.washdc.fios.verizon.net ([IPv6:::1]) [100.15.86.101]:49860
X-Source-Auth: lberger@labn.net
X-Email-Count: 4
X-Source-Cap: bGFibm1vYmk7bGFibm1vYmk7Ym94MzEzLmJsdWVob3N0LmNvbQ==
X-Local-Domain: yes
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 15:36:30 -0000

Rob,

     My/our proposal doesn't seem to help unblock the current impasse,  
as such I'll drop it and move on.

Thanks,

Lou

On 2/23/2018 9:52 AM, Robert Wilton wrote:
> Hi Lou,
>
> As per my public emails on this WG alias, and also private emails, you
> must know that both Martin, I, and others have been trying (for many
> weeks) to reach a compromise.
>
> I don't think that it is that I am unwilling to compromise, but more
> that I perceive that a different compromise solution is the right one.
> I.e. we publish a single draft that contains the model that you want now
> for pre NMDA solutions, and also a model that we think will work well in
> the post NMDA world that all of the IETF YANG models are moving to.
>
> Thanks,
> Rob
>
>
> On 23/02/2018 14:36, Lou Berger wrote:
>> Rob,
>>
>> I think we're going in circles here. We have one camp that wants to
>> replace the current module with pre 09 and is unwilling to discuss
>> compromise, and another camp that wants 08 published as is and has
>> been waiting for the working group and authors to submit aversion to
>> the IESG for publication based on the last call that completed in
>> November.
>>
>> The mail I sent that started this thread was sent with the hope of
>> finding a compromise. As you and Martin seem uninterested in
>> discussing a compromise, I not sure if it's worth pursuing this
>> thread. If I have misread your mails, and you are open to compromise
>> then we should continue this thread.
>>
>> If not and there is no interest in finding a compromise in the working
>> group and by the authors, I guess we're back to the plan of publishing
>> 08 and looking forward to protests.
>>
>> Lou
>>
>>
>>
>> .
>>
>


From nobody Fri Feb 23 08:02:52 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9FB126DFB for ; Fri, 23 Feb 2018 08:02:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.491
X-Spam-Level: 
X-Spam-Status: No, score=-2.491 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id k9zFOMhhrKFZ for ; Fri, 23 Feb 2018 08:02:46 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 85F3412E8C2 for ; Fri, 23 Feb 2018 08:02:46 -0800 (PST)
Received: from pps.filterd (m0108158.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1NG15Lh002566; Fri, 23 Feb 2018 08:02:41 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=3UQeH5e7O06eNmCHXu+UCKz5jEncyQmnDqUiFYlyGH4=; b=ObHFArdWBAjtpZxmXrGqtpJCMc6EE+we0SDbMq4lMiKzMiHZx7naFUhxITMo0ZLLEsaf 4/+SZ68PjEP/BcFrTIDOxMhh1mzuS7HfrJIPWzw8hFRe35VTfkC8BE4c32RvBri8uXHY DOmt/h+em1XFoY88onSLwWXk371jUjk8ZFKlOE9bQI/LTXI8QL3v2+gpJFN0S3uj0ERB 5+x1L8E6gFDViy+WcH/cWqGzdNkrOCFVQnMlK7jvYK552/aMZMdBChhOvcEwEhLl4P68 Pp5o8B0NQm2LqfVDMyTk2rYj6RmsARHdSujS3SOX4QSsf5EzhLLe5Dx1yCif9NKXZTUP Ew== 
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0055.outbound.protection.outlook.com [207.46.163.55]) by mx0a-00273201.pphosted.com with ESMTP id 2gap28g0a4-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Feb 2018 08:02:41 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3274.namprd05.prod.outlook.com (10.173.220.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.6; Fri, 23 Feb 2018 16:02:39 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b%3]) with mapi id 15.20.0548.005; Fri, 23 Feb 2018 16:02:38 +0000
From: Kent Watsen 
To: "Clyde Wildes (cwildes)" , "t.petch" , Yaron Sheffer , Ron Bonica 
CC: NETMOD Working Group 
Thread-Topic: [netmod] AD review of draft-ietf-netmod-syslog-model-20
Thread-Index: AQHTpZZd5Geu+8X2WUq2NsIzPrmhNqOj3UoAgAmtrxX//7BHAIACLXCAgAJ3xQA=
Date: Fri, 23 Feb 2018 16:02:38 +0000
Message-ID: 
References:  <922E608D-951A-459A-B515-B53834C805C1@juniper.net> <022001d3aa6a$c31895e0$4001a8c0@gateway.2wire.net>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3274; 7:ZwXEDDrsntFs4oNestVaohUlMVHgNNC4P8wpLX0Fmd0W4Rh6lTrwlnbBbthJ3Sh4t5RrLzwKIWK8pArPejJwkfg+WZsrOyW9BagmmsS3RFlvIYPMDB2ggQmCAdsvVy0SFY9DyVR9YsJtgU+NVynO7QrC0MYqqAILNbNRLbJHwG5HA/YEvhQIJ3dsKnvmTrCuqkC7UQoDcihgtnNIDJkFlYj8YhgyR2XJRs/x1SJGZMSGcgZNccP/Rq6SDkeIayzO
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(396003)(39860400002)(39380400002)(346002)(376002)(366004)(199004)(189003)(3660700001)(8676002)(6486002)(6116002)(3846002)(81156014)(58126008)(81166006)(8936002)(5250100002)(110136005)(316002)(229853002)(14454004)(83716003)(2906002)(2900100001)(68736007)(2950100002)(966005)(6636002)(4326008)(82746002)(6436002)(39060400002)(25786009)(99286004)(478600001)(6246003)(1941001)(53936002)(76176011)(33656002)(6346003)(93886005)(97736004)(102836004)(36756003)(186003)(53546011)(3280700002)(575784001)(106356001)(86362001)(66066001)(7736002)(5660300001)(6306002)(6512007)(105586002)(305945005)(8666007)(26005)(6506007); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3274; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  A:1; MX:1; LANG:en; 
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: bae80819-8eb5-4e0d-183b-08d57ad6dcc3
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3274; 
x-ms-traffictypediagnostic: DM5PR05MB3274:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(10436049006162)(138986009662008)(150554046322364)(95692535739014); 
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(10201501046)(93006095)(93001095)(3002001)(3231192)(944501161)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123558120)(20161123560045)(20161123562045)(20161123564045)(6072148)(201708071742011); SRVR:DM5PR05MB3274; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3274; 
x-forefront-prvs: 0592A9FDE6
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: zWQb2LUHxynUC5gNglA6VYV/fzRnxi/+ZOcf/l9Emhlgc3ahsw+n9+8c6DQUXAI0QPOYeh62MslwePVmg7JfVbOmcGq8GmGKqLqZnT586A7IDyp7ertOX+YLiRtrttIdkcwgwmmC07rw+fIK6goxuXZR8pilaENTD0EELQJZ/VE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5209EFAAC20BAF43B9D14E37681117D2@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: bae80819-8eb5-4e0d-183b-08d57ad6dcc3
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2018 16:02:38.6965 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3274
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-23_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802230198
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 16:02:49 -0000

SGkgQ2x5ZGUsDQoNCkxvb2tpbmcgYXQgeW91ciBkaWZmLCBJIHNlZSB0aGF0IHlvdSBhbGlnbmVk
IHRoZSBVc2FnZSBFeGFtcGxlIHRleHQgYW5kIGFydHdvcmsgYnkgbWFraW5nIHRoZSBhcnR3b3Jr
IHVzZSB0aGUgSVAgYWRkcmVzcyBmcm9tIHRoZSB0ZXh0LCBidXQgeW91IHNob3VsZCd2ZSBpbnN0
ZWFkIHVzZWQgdGhlIGhvc3RuYW1lIGluIGJvdGggbG9jYXRpb25zLiAgUGxlYXNlIHNlZSBzZWN0
aW9uIDMuNiBoZXJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9zdGFuZGFyZHMvaWRzL2NoZWNrbGlz
dC4NCg0KQWxzbywgSSBzZWUgdGhhdCB5b3UgbW92ZWQgdGhlIEVkaXRvcmlhbCBOb3RlIHRvIFNl
Y3Rpb24gMS40IChhbG9uZyB3aXRoIGEgdHlwbyBpbiB0aGUgdGl0bGUsIG9vb3BzKS4gIFRoaXMg
aXMgZmluZSwgSSBndWVzcywgdGhvdWdoIEkgd2FzIHRoaW5raW5nIGluc3RlYWQgYWJvdXQgc29t
ZXRoaW5nIGxpa2UgYSB0b3AtbGV2ZWwgIlJGQyBFZGl0b3IgQ29uc2lkZXJhdGlvbnMiIG5lYXIg
dGhlIGVuZCBbaG1tbSwgYSBidWRkaW5nIEJDUD8gOyldLiAgQWN0dWFsbHksIEkgd2lzaCB5b3Ug
aGFkIGV4cGxhaW5lZCB0aGF0IHRoZSB0ZXh0IHdhcyBub3QgaW4gdGhlIEFic3RyYWN0LCBidXQg
aW4gYSAiPG5vdGU+IiBlbGVtZW50LCBhbmQgaXQgd2FzIGp1c3QgYSByZW5kZXJpbmcgaXNzdWUu
ICBJdCdzIGFjdHVhbGx5IGNvbW1vbiB0byB1c2UgdGhlIDxub3RlPiBlbGVtZW50IGZvciB0aGlz
IHB1cnBvc2UgKHNvcnJ5IGZvciBub3QgcmVjb2duaXppbmcgaXQgYmVmb3JlKS4gIFBsZWFzZSBh
bHNvIGVpdGhlciBmaXggdGhlIHR5cG8gb3IsIGJldHRlciwgbW92ZSB0aGUgc2VjdGlvbiBiYWNr
IHRvIHRoZSA8bm90ZT4gZWxlbWVudC4NCg0KS2VudCAvLyBzaGVwaGVyZA0KDQoNCj09PT09IG9y
aWdpbmFsIG1lc3NhZ2UgPT09PT0NCg0KS2VudCwgVG9tLCBZYXJvbiwgYW5kIFJvbiwNCg0KQSBu
ZXcgdmVyc2lvbiBvZiB0aGUgZHJhZnQtaWV0Zi1uZXRtb2Qtc3lzbG9nLW1vZGVsIGhhcyBiZWVu
IHB1Ymxpc2hlZCB0aGF0IGFkZHJlc3NlcyB5b3VyIGNvbmNlcm5zLg0KDQpUaGFua3MsDQoNCg0K
DQpDbHlkZQ0KDQoNCg0KT24gMi8yMC8xOCwgOTowNiBBTSwgIm5ldG1vZCBvbiBiZWhhbGYgb2Yg
S2VudCBXYXRzZW4iIDxuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyBvbiBiZWhhbGYgb2Yga3dhdHNl
bkBqdW5pcGVyLm5ldD4gd3JvdGU6DQoNCg0KDQogICAgDQoNCiAgICANCg0KICAgIA0KDQogICAg
PiBLZW50DQoNCiAgICA+IA0KDQogICAgPiBZb3UgaWxsdXN0cmF0ZSBiZWF1dGlmdWxseSB0aGUg
cHJvYmxlbSBJIHdvdWxkIGxpa2UgYSBzb2x1dGlvbiB0by4NCg0KICAgID4NCg0KICAgID4gVGhl
IGN1cnJlbnQgdGhpbmtpbmcgQUZBSUNUIGlzIHRoYXQgdHJlZS1kaWFncmFtcw0KDQogICAgPiBz
aG91bGQgYmUgYW4gSW5mb3JtYXRpdmUgUmVmZXJlbmNlLg0KDQogICAgPg0KDQogICAgPiBUaGVy
ZWZvcmUsIHRoZSBSRkMgRWRpdG9yIHdpbGwgbm90IGhvbGQgcHVibGljYXRpb24gdW50aWwgYW4g
UkZDIG51bWJlcg0KDQogICAgPiBpcyBhc3NpZ25lZC4NCg0KICAgID4gDQoNCiAgICA+IFRoZXJl
Zm9yZSwgYSBub3RlIGFza2luZyB0aGUgSS1EIHJlZmVyZW5jZSB0byBiZSB1cGRhdGVkIHRvIHJl
ZmxlY3QgdGhlDQoNCiAgICA+IGFzc2lnbmVkIFJGQyBudW1iZXIgaXMgbnVsbCAtIHRoZSBSRkMg
Y2FuIGJlIHB1Ymxpc2hlZCB3aXRoIHRoZQ0KDQogICAgPiByZWZlcmVuY2UgYXMgYW4gaS1kIGFu
ZCBub3QgYXMgYW4gUkZDIHdoaWNoIGlzIHdoYXQgSSBleHBlY3QgdGhlIFJGQw0KDQogICAgPiBF
ZGl0b3IgdG8gZG8uDQoNCiAgICA+IA0KDQogICAgPiBRRUQNCg0KICAgIA0KDQogICAgDQoNCiAg
ICBFeGNlcHQgSSBrbm93IHRoYXQgdGhpcyBkcmFmdCB3aWxsIGJlIHN0dWNrIGluIE1JU1JFRiBz
dGF0ZSBhbmQgdHJlZS1kaWFncmFtcw0KDQogICAgd2lsbCBpbiBmYWN0IGJlIGFzc2lnbmVkIGFu
IFJGQyBudW1iZXIgYnkgdGhlIHRpbWUgdGhpcyBkcmFmdCBpcyBwdWJsaXNoZWQuDQoNCiAgICAN
Cg0KICAgIEsuDQoNCiAgICANCg0KICAgIA0KDQogICAgPiBOb3RlIHRoYXQgdGhpcyBpcyBub3Qg
dGhlIGNhc2Ugb2YgYSBOb3JtYXRpdmUgaS1kIHJlZmVyZW5jZSBiZWluZyBidXJpZWQNCg0KICAg
ID4gaW4gdGhlIFlBTkcgbW9kdWxlIGFuZCBub3QgYmVpbmcubm90aWNlZCBieSB0aGUgUkZDIEVk
aXRvcjsgdGhhdCBwcm9ibGVtDQoNCiAgICA+IEkgYW0gY29udGVudCB3aXRoLg0KDQogICAgPg0K
DQogICAgPg0KDQogICAgPlRvbSBQZXRjaA0KDQogICAgDQoNCiAgICANCg0KICAgIA0KDQogICAg
DQoNCiAgICANCg0KICAgIA0KDQogICAgDQoNCiAgICANCg0KICAgID4NCg0KICAgID4gUGxlYXNl
IGFsc28gYWRkcmVzcyB0aGVzZSBpc3N1ZXMgd2hlbiBwb3N0aW5nIC0yMSB0byBhZGRyZXNzIEJl
bm9pdCdzDQoNCiAgICBpc3N1ZXMuICBQbGVhc2UgcG9zdCAtMjEgQVNBUCBhcyBCZW5vaXQgaGFz
IGFscmVhZHkgcGxhY2VkIHRoaXMgZHJhZnQgb24NCg0KICAgIHRoZSBJRVNHIHRlbGVjaGF0IGlu
IGEgY291cGxlIHdlZWtzLg0KDQogICAgPg0KDQogICAgPiBUaGFua3MsDQoNCiAgICA+IEtlbnQg
Ly8gc2hlcGhlcmQNCg0KICAgID4NCg0KICAgID4NCg0KICAgID4gT24gMi8xNC8xOCwgODoxOCBB
TSwgIm5ldG1vZCBvbiBiZWhhbGYgb2YgQmVub2l0IENsYWlzZSINCg0KICAgIDxuZXRtb2QtYm91
bmNlc0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+IG9uIGJlaGFsZiBv
Zg0KDQogICAgYmNsYWlzZUBjaXNjby5jb208bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPj4gd3Jv
dGU6DQoNCiAgICA+DQoNCiAgICA+IERlYXIgYWxsLA0KDQogICAgPg0KDQogICAgPiAtIHRoZSBk
cmFmdCBpcyBOTURBIGNvbXBsaWFudCwgcmlnaHQ/IEl0IHNob3VsZCBiZSBtZW50aW9uZWQuDQoN
CiAgICA+IEV4OiBkcmFmdC1pZXRmLW5ldG1vZC1yZmM3MjIzYmlzLTAzLCBpbiB0aGUgYWJzdHJh
Y3QgYW5kIGludHJvDQoNCiAgICA+DQoNCiAgICA+ICAgIFRoZSBZQU5HIG1vZGVsIGluIHRoaXMg
ZG9jdW1lbnQgY29uZm9ybXMgdG8gdGhlIE5ldHdvcmsgTWFuYWdlbWVudA0KDQogICAgPg0KDQog
ICAgPiAgICBEYXRhc3RvcmUgQXJjaGl0ZWN0dXJlIGRlZmluZWQgaW4NCg0KICAgIEktRC5pZXRm
LW5ldG1vZC1yZXZpc2VkLWRhdGFzdG9yZXMuDQoNCiAgICA+DQoNCiAgICA+DQoNCiAgICA+IC0g
QXMgbWVudGlvbmVkIGluIHRoZSB3cml0ZXVwLCBbSS1ELmlldGYtbmV0bW9kLXlhbmctdHJlZS1k
aWFncmFtc10NCg0KICAgIHNob3VsZCBiZSBhbiBpbmZvcm1hdGl2ZSByZWZlcmVuY2UsIG5vdCBu
b3JtYXRpdmUuDQoNCiAgICA+DQoNCiAgICA+IC0gRWRpdG9yaWFsOg0KDQogICAgPiBPTEQ6DQoN
CiAgICA+IFRoaXMgZHJhZnQgYWRkcmVzc2VzIHRoZSBjb21tb24gbGVhZnMNCg0KICAgID4gTkVX
Og0KDQogICAgPiBUaGlzIGRvY3VtZW50IGFkZHJlc3NlcyB0aGUgY29tbW9uIGxlYWZzDQoNCiAg
ICA+DQoNCiAgICA+IFBsZWFzZSBwdWJsaXNoIGEgbmV3IHZlcnNpb24gYXNhcC4NCg0KICAgID4g
SW4gdGhlIG1lYW4gdGltZSwgSSdtIHNlbmRpbmcgdGhpcyBkcmFmdCB0byBJRVRGIExDLg0KDQog
ICAgPg0KDQogICAgPiBSZWdhcmRzLCBCZW5vaXQNCg0KICAgID4NCg0KICAgID4NCg0KICAgID4N
Cg0KICAgIA0KDQogICAgDQoNCiAgICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgIC0tLS0tLS0tDQoN
CiAgICANCg0KICAgIA0KDQogICAgPiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fXw0KDQogICAgPiBuZXRtb2QgbWFpbGluZyBsaXN0DQoNCiAgICA+IG5ldG1v
ZEBpZXRmLm9yZw0KDQogICAgPiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3
SUNhUSZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQ
MHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09Y0o3TVZuUVZjMWhneHBW
RjdvWWlWbjZSYm0tUWYyZER5cmZZaEwtczlpbyZzPXUwSG45R2tPLUIwalVHbTFNbklRNHg0QWdJ
Wk5YSEJJYVpoVFBtdDNkQzgmZT0NCg0KICAgID4NCg0KICAgIA0KDQogICAgDQoNCiAgICANCg0K
ICAgIF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQoNCiAg
ICBuZXRtb2QgbWFpbGluZyBsaXN0DQoNCiAgICBuZXRtb2RAaWV0Zi5vcmcNCg0KICAgIGh0dHBz
Oi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYu
b3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmQ9RHdJR2FRJmM9SEFrWXVoNjNyc3VocjZTY2Jm
aDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZ
YUdUdmpJU2xhSmRjWm8mbT12RUxzbWVPUUVITm00ZmN5SkpLRzdFcHd3ek1CR2MtTUh2SGhTUFdS
enJvJnM9alNHd1AxNlhsTTZudE1LVUYzYmtDQXdSZlJ0UndBVGRseTJCbFV0eDJSQSZlPQ0KDQog
ICAgDQoNCg0KDQoNCg0K


From nobody Fri Feb 23 08:37:22 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 039BE12E039 for ; Fri, 23 Feb 2018 08:37:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SyZvqSoFE5nA for ; Fri, 23 Feb 2018 08:37:19 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A16E3126DFB for ; Fri, 23 Feb 2018 08:37:19 -0800 (PST)
Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w1NGbIMK018105 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 23 Feb 2018 16:37:18 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mb.local
From: joel jaeggli 
To: netmod@ietf.org
References:  <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com> 
Message-ID: 
Date: Fri, 23 Feb 2018 08:37:12 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Vm3BOmpSpt02NI446tuaQ6CQPwN0WwFwg"
Archived-At: 
Subject: [netmod] Adoption Poll Completed: draft-rtgyangdt-netmod-module-tags-02
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 16:37:21 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Vm3BOmpSpt02NI446tuaQ6CQPwN0WwFwg
Content-Type: multipart/mixed; boundary="R5sMqfxIxAKWdtDb2jBPIlhIEFfADbDp2";
 protected-headers="v1"
From: joel jaeggli 
To: netmod@ietf.org
Message-ID: 
Subject: Adoption Poll Completed: draft-rtgyangdt-netmod-module-tags-02
References: 
 <99825209-7add-d3a7-54bb-7c74017172bd@bogus.com>
 
In-Reply-To: 

--R5sMqfxIxAKWdtDb2jBPIlhIEFfADbDp2
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

This completes the 2 week poll on making
draft-rtgyangdt-netmod-module-tags-02 a working group document.

https://tools.ietf.org/html/draft-rtgyangdt-netmod-module-tags-02

This document was most recently discussed at IETF 100.

Response has been generally favorable and enthusiasic with some interest
in signficant changes. We are adopting the document as a working group it=
em.

The authors should submit an updated draft probably with the title
draft-ietf-netmod-module-tags-02.

thanks
joel



--R5sMqfxIxAKWdtDb2jBPIlhIEFfADbDp2--

--Vm3BOmpSpt02NI446tuaQ6CQPwN0WwFwg
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCWpBDOAAKCRDwADWrtn9W
snRiAJ9Z5CsPcZ9Xsw+WFBlouk+lHYGbDwCcD4amVsMHcujpzG2OBgaAG7rXnCQ=
=jG/Q
-----END PGP SIGNATURE-----

--Vm3BOmpSpt02NI446tuaQ6CQPwN0WwFwg--


From nobody Fri Feb 23 08:56:08 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CA04E12D7F0 for ; Fri, 23 Feb 2018 08:56:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.91
X-Spam-Level: 
X-Spam-Status: No, score=-6.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 57SkSr5e17pm for ; Fri, 23 Feb 2018 08:56:04 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id B68E61241F3 for ; Fri, 23 Feb 2018 08:56:04 -0800 (PST)
Received: from mb.local (c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209]) (authenticated bits=0) by nagasaki.bogus.com (8.15.2/8.15.2) with ESMTPSA id w1NGu3bx018240 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NOT) for ; Fri, 23 Feb 2018 16:56:04 GMT (envelope-from joelja@bogus.com)
X-Authentication-Warning: nagasaki.bogus.com: Host c-73-202-177-209.hsd1.ca.comcast.net [73.202.177.209] claimed to be mb.local
To: NETMOD Working Group 
From: joel jaeggli 
Message-ID: 
Date: Fri, 23 Feb 2018 08:55:57 -0800
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="Sx4EvVyGnBvkobpXd6CLWZDe9L9Rk4Z6c"
Archived-At: 
Subject: [netmod] feedback draft-rtgyangdt-netmod-module-tags -> draft-ietf-netmod-module-tags
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 16:56:07 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--Sx4EvVyGnBvkobpXd6CLWZDe9L9Rk4Z6c
Content-Type: multipart/mixed; boundary="NXOCgrC7RsKok5zzNiqpIYtzykP7qYxop";
 protected-headers="v1"
From: joel jaeggli 
To: NETMOD Working Group 
Message-ID: 
Subject: feedback draft-rtgyangdt-netmod-module-tags ->
 draft-ietf-netmod-module-tags

--NXOCgrC7RsKok5zzNiqpIYtzykP7qYxop
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: quoted-printable

introduction / abstract should capture the problem module tags are
attempting to solve succinctly

Robert Wilton's criticism of the approach is well taken; the use of tags
as regular configuration (his approach) vs the treatment of tags as
exceptions (how we understand them as proposed). and seems like a ket
architectural consideration in advancing this draft.

joel


--NXOCgrC7RsKok5zzNiqpIYtzykP7qYxop--

--Sx4EvVyGnBvkobpXd6CLWZDe9L9Rk4Z6c
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iF0EARECAB0WIQRcbgEEuvBAsFvTw4vwADWrtn9WsgUCWpBHnQAKCRDwADWrtn9W
sq1lAJwOSKJE/qs+XkHUPGht6wMGKNPclQCdE6nrT6GvmB1mhE9efkJBsOf2Lrs=
=fZSU
-----END PGP SIGNATURE-----

--Sx4EvVyGnBvkobpXd6CLWZDe9L9Rk4Z6c--


From nobody Fri Feb 23 10:00:21 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA84B126C2F for ; Fri, 23 Feb 2018 10:00:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XGWmYcRPIOX2 for ; Fri, 23 Feb 2018 10:00:15 -0800 (PST)
Received: from mail-pl0-x233.google.com (mail-pl0-x233.google.com [IPv6:2607:f8b0:400e:c01::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 9E6431241F8 for ; Fri, 23 Feb 2018 10:00:15 -0800 (PST)
Received: by mail-pl0-x233.google.com with SMTP id w21so5301138plp.11 for ; Fri, 23 Feb 2018 10:00:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=k/oNmSQlXbqzu4NRC2+s9o/+7COjm0/l5VOPSxmyFXI=; b=MEhyD5Vbz0GcPiSI5jYaUsxfslUWB7Lhoj2tpa+BcGgYl2KkjrTXYUjBH3VFhSBCBu yoJnGKJs6nJ4BuJFfXk+dU4ggqoHPaZrJymJl/ARMes9sB1PT+wJojTln/KUodgwnprb 6iKjyDi28RlKeW1hCMeNrJYOMkvpPyuISTJZXY+Y6ELNytOpW6jleVJ8za1M3LFAHEHx dpXSyyqvB9GBb3hZA5dBNQjlQvIpoSgEad63VVVmPmLLcXMBKJioUoFn0rGztS18K6bk vb+GGRc3vIrxphXTR2X+RH027IN/rUE9RbZDLSjjWM97uTXN1BbNIvT0TYa2QcYhI/+I ny7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=k/oNmSQlXbqzu4NRC2+s9o/+7COjm0/l5VOPSxmyFXI=; b=QlIH1nQM1RyOZS8KztK6jx94paxv97uNpl7nk0OLUrETucLdv2SZjjwS6V56LYB/aI U9f2Vdm9OXa8ruJtUd8w8v0YPN8AaVV4CdGPxNdLySnEu8Exu9LM08kyp5LzVgbksoFt gNzap6ttW2qfPntNmILAelojEGtAMc16FRIlosR8EKY6kCmzEchUT9QhGeXFKuylKILi HXcBV+o9uXATnIVQiIHX4moY99Ii45nMR+TtZxDzbiJrruUZP90RH5MSoLbILyU6rCEH ZepzomLzAuDqdFDo1Wh+M6Eqx2acZ0wQf27l49xpHxfHUXbyIDg6nsWMy3GjKT6BuWAj j2mg==
X-Gm-Message-State: APf1xPBPH4I4gYfP2pTCGFyMsZ5fCkw/QHq9fNhtbNgsSYmCsimCPNWK ejkGNezlRmU5yvludYRHQSs=
X-Google-Smtp-Source: AH8x224vQtzOXkylPgWB/5EoW3nMu9gXi6s9J1/d09JkqlHnx9GxIVohHJrp9Qga8iqvvqWmVgyLCQ==
X-Received: by 2002:a17:902:4003:: with SMTP id b3-v6mr2454133pld.154.1519408815053;  Fri, 23 Feb 2018 10:00:15 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:ddd9:f946:c0e4:4e55? ([2601:647:4700:1280:ddd9:f946:c0e4:4e55]) by smtp.gmail.com with ESMTPSA id f5sm4594882pgo.58.2018.02.23.10.00.13 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 23 Feb 2018 10:00:14 -0800 (PST)
From: Mahesh Jethanandani 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_78660305-D016-40E3-BE0F-D640BA03B0EB"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Fri, 23 Feb 2018 10:05:52 -0800
In-Reply-To: 
Cc: "Clyde Wildes (cwildes)" , "t.petch" , Yaron Sheffer , Ron Bonica , NETMOD Working Group 
To: Kent Watsen 
References:  <922E608D-951A-459A-B515-B53834C805C1@juniper.net> <022001d3aa6a$c31895e0$4001a8c0@gateway.2wire.net>   
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 18:00:19 -0000

--Apple-Mail=_78660305-D016-40E3-BE0F-D640BA03B0EB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii

Kent,

> On Feb 23, 2018, at 8:02 AM, Kent Watsen  wrote:
>=20
> Hi Clyde,
>=20
> Looking at your diff, I see that you aligned the Usage Example text =
and artwork by making the artwork use the IP address from the text, but =
you should've instead used the hostname in both locations.  Please see =
section 3.6 here: https://www.ietf.org/standards/ids/checklist =
.
>=20
> Also, I see that you moved the Editorial Note to Section 1.4 (along =
with a typo in the title, ooops).  This is fine, I guess, though I was =
thinking instead about something like a top-level "RFC Editor =
Considerations" near the end [hmmm, a budding BCP? ;)].  Actually, I =
wish you had explained that the text was not in the Abstract, but in a =
"" element, and it was just a rendering issue.  It's actually =
common to use the  element for this purpose (sorry for not =
recognizing it before). Please also either fix the typo or, better, move =
the section back to the  element.

I had recommended the move of the note from abstract section to the end =
of the Introduction section. Abstracts cannot have cross-references in =
them, which the note had. And that was one of the OPS-DIR comments too.

>=20
> Kent // shepherd
>=20
>=20
> =3D=3D=3D=3D=3D original message =3D=3D=3D=3D=3D
>=20
> Kent, Tom, Yaron, and Ron,
>=20
> A new version of the draft-ietf-netmod-syslog-model has been published =
that addresses your concerns.
>=20
> Thanks,
>=20
>=20
>=20
> Clyde
>=20
>=20
>=20
> On 2/20/18, 9:06 AM, "netmod on behalf of Kent Watsen" =
 on behalf of =
kwatsen@juniper.net > wrote:
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>> Kent
>=20
>>=20
>=20
>> You illustrate beautifully the problem I would like a solution to.
>=20
>>=20
>=20
>> The current thinking AFAICT is that tree-diagrams
>=20
>> should be an Informative Reference.
>=20
>>=20
>=20
>> Therefore, the RFC Editor will not hold publication until an RFC =
number
>=20
>> is assigned.
>=20
>>=20
>=20
>> Therefore, a note asking the I-D reference to be updated to reflect =
the
>=20
>> assigned RFC number is null - the RFC can be published with the
>=20
>> reference as an i-d and not as an RFC which is what I expect the RFC
>=20
>> Editor to do.
>=20
>>=20
>=20
>> QED
>=20
>=20
>=20
>=20
>=20
>    Except I know that this draft will be stuck in MISREF state and =
tree-diagrams
>=20
>    will in fact be assigned an RFC number by the time this draft is =
published.
>=20
>=20
>=20
>    K.
>=20
>=20
>=20
>=20
>=20
>> Note that this is not the case of a Normative i-d reference being =
buried
>=20
>> in the YANG module and not being.noticed by the RFC Editor; that =
problem
>=20
>> I am content with.
>=20
>>=20
>=20
>>=20
>=20
>> Tom Petch
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>>=20
>=20
>> Please also address these issues when posting -21 to address Benoit's
>=20
>    issues.  Please post -21 ASAP as Benoit has already placed this =
draft on
>=20
>    the IESG telechat in a couple weeks.
>=20
>>=20
>=20
>> Thanks,
>=20
>> Kent // shepherd
>=20
>>=20
>=20
>>=20
>=20
>> On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"
>=20
>     on behalf =
of
>=20
>    bclaise@cisco.com> wrote:
>=20
>>=20
>=20
>> Dear all,
>=20
>>=20
>=20
>> - the draft is NMDA compliant, right? It should be mentioned.
>=20
>> Ex: draft-ietf-netmod-rfc7223bis-03, in the abstract and intro
>=20
>>=20
>=20
>>   The YANG model in this document conforms to the Network Management
>=20
>>=20
>=20
>>   Datastore Architecture defined in
>=20
>    I-D.ietf-netmod-revised-datastores.
>=20
>>=20
>=20
>>=20
>=20
>> - As mentioned in the writeup, [I-D.ietf-netmod-yang-tree-diagrams]
>=20
>    should be an informative reference, not normative.
>=20
>>=20
>=20
>> - Editorial:
>=20
>> OLD:
>=20
>> This draft addresses the common leafs
>=20
>> NEW:
>=20
>> This document addresses the common leafs
>=20
>>=20
>=20
>> Please publish a new version asap.
>=20
>> In the mean time, I'm sending this draft to IETF LC.
>=20
>>=20
>=20
>> Regards, Benoit
>=20
>>=20
>=20
>>=20
>=20
>>=20
>=20
>=20
>=20
>=20
>=20
>    =
------------------------------------------------------------------------
>=20
>    --------
>=20
>=20
>=20
>=20
>=20
>> _______________________________________________
>=20
>> netmod mailing list
>=20
>> netmod@ietf.org
>=20
>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_netmod&d=3DDwICaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzo=
CI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DcJ7MVnQVc1hgxpVF7oY=
iVn6Rbm-Qf2dDyrfYhL-s9io&s=3Du0Hn9GkO-B0jUGm1MnIQ4x4AgIZNXHBIaZhTPmt3dC8&e=
=3D
>=20
>>=20
>=20
>=20
>=20
>=20
>=20
>=20
>=20
>    _______________________________________________
>=20
>    netmod mailing list
>=20
>    netmod@ietf.org
>=20
>    =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_netmod&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzo=
CI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3DvELsmeOQEHNm4fcyJJK=
G7EpwwzMBGc-MHvHhSPWRzro&s=3DjSGwP16XlM6ntMKUF3bkCAwRfRtRwATdly2BlUtx2RA&e=
=3D =

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

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_78660305-D016-40E3-BE0F-D640BA03B0EB
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii

Kent,

On Feb 23, 2018, at 8:02 AM, =
Kent Watsen <kwatsen@juniper.net> wrote:

Hi Clyde,
Looking at your diff, I see that you aligned the =
Usage Example text and artwork by making the artwork use the IP address =
from the text, but you should've instead used the hostname in both =
locations.  Please see section 3.6 here: https://www.ietf.org/standards/ids/checklist.

Also, I see that you moved the Editorial Note to =
Section 1.4 (along with a typo in the title, ooops).  This is fine, =
I guess, though I was thinking instead about something like a top-level =
"RFC Editor Considerations" near the end [hmmm, a budding BCP? ;)]. =
 Actually, I wish you had explained that the text was not in the =
Abstract, but in a "<note>" element, and it was just a rendering =
issue.  It's actually common to use the <note> element for =
this purpose (sorry for not recognizing it before). Please also either =
fix the typo or, better, move the section back to the <note> =
element.

I had recommended the move of the note from abstract =
section to the end of the Introduction section. Abstracts cannot have =
cross-references in them, which the note had. And that was one of the =
OPS-DIR comments too.


Kent // shepherd
=3D=3D=3D=3D=3D original message =3D=3D=3D=3D=3D

Kent, Tom, Yaron, and Ron,
A new version of the =
draft-ietf-netmod-syslog-model has been published that addresses your =
concerns.

Thanks,
Clyde

On 2/20/18, 9:06 AM, "netmod on behalf of Kent =
Watsen" <netmod-bounces@ietf.org on behalf of kwatsen@juniper.net> wrote:
Kent



You illustrate beautifully =
the problem I would like a solution to.



The current thinking AFAICT is that tree-diagrams

should be an Informative Reference.



Therefore, the RFC Editor =
will not hold publication until an RFC number

is assigned.



Therefore, a note asking the I-D reference to be updated to =
reflect the

assigned RFC number is null =
- the RFC can be published with the

reference as an i-d and not =
as an RFC which is what I expect the RFC

Editor to do.



QED



   Except I know that this draft =
will be stuck in MISREF state and tree-diagrams
   will in fact be assigned an =
RFC number by the time this draft is published.
   K.
Note that this is not the =
case of a Normative i-d reference being buried

in the YANG module and not being.noticed by the RFC Editor; =
that problem

I am content with.





Tom Petch




Please also address these issues when posting -21 to address =
Benoit's

   issues. =
 Please post -21 ASAP as Benoit has already placed this draft =
on

   the IESG =
telechat in a couple weeks.



Thanks,

Kent // shepherd





On 2/14/18, 8:18 AM, "netmod on behalf of Benoit Claise"

   <netmod-bounces@ietf.org<mailto:netmod-bounces@ietf.org> on behalf of
   bclaise@cisco.com<mailto:bclaise@cisco.com>> wrote:


Dear all,



- the draft is NMDA compliant, right? It should be =
mentioned.

Ex: =
draft-ietf-netmod-rfc7223bis-03, in the abstract and intro



  The YANG model =
in this document conforms to the Network Management



  Datastore =
Architecture defined in

   I-D.ietf-netmod-revised-datastores.




- As mentioned in the =
writeup, [I-D.ietf-netmod-yang-tree-diagrams]

   should be an =
informative reference, not normative.



- Editorial:

OLD:

This draft addresses the common leafs

NEW:

This document addresses the =
common leafs



Please publish a new version asap.

In the mean time, I'm sending this draft to IETF LC.



Regards, Benoit








   ---------------------------------------------=
---------------------------

   --------
_______________________________________________

netmod mailing list

netmod@ietf.org

https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman_listinfo_netmod&d=3DDwICaQ&c=3DHAkYuh63rsuhr6Scbfh0Uj=
BXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&=
amp;m=3DcJ7MVnQVc1hgxpVF7oYiVn6Rbm-Qf2dDyrfYhL-s9io&s=3Du0Hn9GkO-B0jUG=
m1MnIQ4x4AgIZNXHBIaZhTPmt3dC8&e=3D





   _____________________________________________=
__

   netmod mailing =
list

   netmod@ietf.org
   https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman_listinfo_netmod&d=3DDwIGaQ&c=3DHAkYuh63rsuhr6Scbfh0Uj=
BXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&=
amp;m=3DvELsmeOQEHNm4fcyJJKG7EpwwzMBGc-MHvHhSPWRzro&s=3DjSGwP16XlM6ntM=
KUF3bkCAwRfRtRwATdly2BlUtx2RA&e=3D

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



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_78660305-D016-40E3-BE0F-D640BA03B0EB--


From nobody Fri Feb 23 11:28:22 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CDF95126DEE for ; Fri, 23 Feb 2018 11:28:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sU-ha8DbzJoK for ; Fri, 23 Feb 2018 11:28:18 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 214F312D879 for ; Fri, 23 Feb 2018 11:28:18 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id DA245B28; Fri, 23 Feb 2018 20:28:16 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id wGiZB6qKF1yu; Fri, 23 Feb 2018 20:28:15 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Fri, 23 Feb 2018 20:28:16 +0100 (CET)
Received: from localhost (demetrius2.jacobs-university.de [212.201.44.47]) by hermes.jacobs-university.de (Postfix) with ESMTP id BAD7920154; Fri, 23 Feb 2018 20:28:16 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius2.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id WeFM_PlmiXoi; Fri, 23 Feb 2018 20:28:16 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 0526120153; Fri, 23 Feb 2018 20:28:15 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 98DE64254820; Fri, 23 Feb 2018 20:28:14 +0100 (CET)
Date: Fri, 23 Feb 2018 20:28:14 +0100
From: Juergen Schoenwaelder 
To: Lou Berger 
Cc: Robert Wilton , Martin Bjorklund , netmod@ietf.org
Message-ID: <20180223192814.xpicpsmsbpcqnwyg@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Lou Berger , Robert Wilton , Martin Bjorklund , netmod@ietf.org
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net> <20180223.135509.1022283362077802966.mbj@tail-f.com>  <8760c49e-1304-0d55-6e38-004dfaca570c@cisco.com> <161c3185fd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <161c3185fd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 19:28:20 -0000

On Fri, Feb 23, 2018 at 09:36:50AM -0500, Lou Berger wrote:
> Rob,
> 
> I think we're going in circles here. We have one camp that wants to replace
> the current module with pre 09 and is unwilling to discuss compromise, and
> another camp that wants 08 published as is and has been waiting for the
> working group and authors to submit aversion to the IESG for publication
> based on the last call that completed in November.

It seems the group in favor of pre 09 is in favor of it because the
solution integrates with YLbis, i.e., _one_ way to represent schema
information.

> The mail I sent that started this thread was sent with the hope of finding a
> compromise. As you and Martin seem uninterested in discussing a compromise,
> I not sure if it's worth pursuing this thread. If I have misread your mails,
> and you are open to compromise then we should continue this thread.

I assume the group in favor of pre 09 finds it difficult to
'compromise' on something that does not provide the benefit of
integrating with YLbis.
 
> If not and there is no interest in finding a compromise in the working group
> and by the authors, I guess we're back to the plan of publishing 08 and
> looking forward to protests.

To investigate the possibility of a compromise, we need to understand
what both groups find unacceptable and where there is room for finding
common grounds.

- For the pre 09 'camp', it seems integration with YLbis is the key
  technical requirement that is driving them.

What is the key technical critical issue for the other camp?

/js

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


From nobody Fri Feb 23 12:12:51 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C7292124B18; Fri, 23 Feb 2018 12:12:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jcavjm6LA531; Fri, 23 Feb 2018 12:12:46 -0800 (PST)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 133AD1201F8; Fri, 23 Feb 2018 12:12:46 -0800 (PST)
Received: from pps.filterd (m0108159.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1NK9pGX016997; Fri, 23 Feb 2018 12:12:44 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=rcF21n89/m1KcDtZfSnFgpkCfPbOt5BIGD//KQibvH8=; b=oj09KY3M+6dDx218yCmFYOAXSzBQOH1zgNiIkbCzteB1hTGM/4aLqOGYJbCZUyWcCaOF jCqS7IWDyQxR5lJh5jiTBafyOcPCqRwSzT/C90iL/4FovmN2/49hIYg79FX5mWwArvAK ui1wZQ6oOP8y1aHgCZws+vYKMOujI76/0AfOw2d3j8oD/vzVCBzVkBCB0F4SjF6RQGoR xXJ3ZLbx/BtbulydfV++vVuvnY3K1Z/w01iX8SSPm2Dz51GzXMSOI1rBGsXC7iGbhpjg hc79WnoiYl9VcT7GFsjzzQNfyyOz4FgPBt233s2l90/+qI/wma2K+I2tBRnIvP8KrgRQ Rw== 
Received: from nam02-bl2-obe.outbound.protection.outlook.com (mail-bl2nam02lp0084.outbound.protection.outlook.com [207.46.163.84]) by mx0a-00273201.pphosted.com with ESMTP id 2gaser019f-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Feb 2018 12:12:43 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3306.namprd05.prod.outlook.com (10.174.191.33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.6; Fri, 23 Feb 2018 20:12:39 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b%3]) with mapi id 15.20.0548.005; Fri, 23 Feb 2018 20:12:39 +0000
From: Kent Watsen 
To: Mahesh Jethanandani 
CC: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] ACL draft issues found during shepherd writeup
Thread-Index: AQHTpRpSR0BIQpp1FUa5qmqsmhR9+aOpZLiAgAjCjgA=
Date: Fri, 23 Feb 2018 20:12:39 +0000
Message-ID: <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net>
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net> <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com>
In-Reply-To: <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3306; 7:/7abxAN2RlyBIVKfs+aveP74brTFE2ym5rcCBDYz0wq2/mkWxTWWI/M2VDLpE+E+GsD4erpP8zzEhstCfRG8uEtx3Sl3jGMgHd57ksRIn5PycliYoH68kDqXNqvVfJmxNwMfrdzSneWhOk6KES8san0p9uALUxXDqcqnC6a0/Uv0HOFffWhjIo6is225BIXilO9Vkv3LJa1i07OhTwV00QNBrg8SCIk49J4AC6uOp3vqInGYi7sXQRMCgfUrhFiz
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 4c7d8fdb-3911-40d7-fa06-08d57af9c9bb
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3306; 
x-ms-traffictypediagnostic: DM5PR05MB3306:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(192374486261705)(138986009662008)(85827821059158)(788757137089)(100405760836317)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(5005006)(8121501046)(3231101)(944501161)(3002001)(93006095)(93001095)(10201501046)(6055026)(6041288)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB3306; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3306; 
x-forefront-prvs: 0592A9FDE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(39380400002)(366004)(346002)(376002)(396003)(85644002)(377424004)(199004)(189003)(478600001)(8676002)(6512007)(2950100002)(33656002)(81156014)(26005)(4326008)(6916009)(1411001)(9326002)(6506007)(53546011)(102836004)(106356001)(7736002)(14454004)(59450400001)(81166006)(2906002)(82746002)(3660700001)(6436002)(99286004)(8936002)(83716003)(966005)(105586002)(39060400002)(76176011)(6246003)(5660300001)(53376002)(25786009)(68736007)(6116002)(3846002)(316002)(54896002)(6306002)(6486002)(3280700002)(58126008)(236005)(2900100001)(36756003)(606006)(53936002)(97736004)(5250100002)(86362001)(229853002)(575784001)(186003)(54906003)(66066001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3306; H:DM5PR05MB3484.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)
x-microsoft-antispam-message-info: LNJjXei3vtlJeaRkZrGuQxfQiRIRcFCCUujJsOBonNRDGhT7+ePLf+AoDbFr0Q4J3HwRASXk2pOtEcwJjVMp3W68n8Wfp0631d9Cs+keaHUWJAFJfMWwxcK8hR3gkyTt/1J08fylWbFLxsOnn67c/Rv1p+yNKC4ivUuOJpsNUUc=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_8D3773A8ECA6406AB28D6DD44F951F10junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: 4c7d8fdb-3911-40d7-fa06-08d57af9c9bb
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2018 20:12:39.1977 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3306
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-23_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802230246
Archived-At: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 20:12:50 -0000

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

SGkgTWFoZXNoLA0KDQpQbGVhc2Ugc2VhcmNoIGZvciA8S0VOVD4gYmVsb3cgKDYgaW5zdGFuY2Vz
KQ0KDQpUaGFua3MsDQpLZW50IC8vIHNoZXBoZXJkDQoNCg0KT24gMi8xNy8xOCwgODoyNiBQTSwg
Ik1haGVzaCBKZXRoYW5hbmRhbmkiIDxtamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxtYWlsdG86bWpl
dGhhbmFuZGFuaUBnbWFpbC5jb20+PiB3cm90ZToNCg0KS2VudCwNCg0KVGhhbmtzIGZvciBhIGRl
dGFpbGVkIHJldmlldy4gU2VlIGlubGluZS4NCg0KDQpPbiBGZWIgMTMsIDIwMTgsIGF0IDI6MzAg
UE0sIEtlbnQgV2F0c2VuIDxrd2F0c2VuQGp1bmlwZXIubmV0PG1haWx0bzprd2F0c2VuQGp1bmlw
ZXIubmV0Pj4gd3JvdGU6DQoNCltzb3JyeSwgd3JvbmcgV0csIG1vdmluZyBuZXRjb25mIHRvIEJD
QyFdDQoNCg0KQUNMIEF1dGhvcnMsDQoNCkJlbG93IGFyZSBzb21lIGlzc3VlcyBJIGZvdW5kIHdo
aWxlIGxvb2tpbmcgYXQgZG9pbmcgdGhlIFNoZXBoZXJkDQp3cml0ZS11cCB0b2RheS4gIFBsZWFz
ZSB0YWtlIGEgbG9vay4NCg0KQWxzbywgd2l0aCByZWdhcmRzIHRvIHRoZSByZXF1ZXN0IGZvciB0
aG9zZSBoYXZpbmcgTGFzdCBDYWxsIGNvbW1lbnRzDQp0byBwbGVhc2UgdmVyaWZ5IHRoYXQgdGhl
aXIgY29tbWVudHMgd2VyZSBhZGRyZXNzZWQsIEkgb25seSBzYXcgb25lDQpyZXNwb25zZSBmcm9t
IEtyaXN0aWFuLCBidXQgc2hvdWxkIHdlIGJlIGV4cGVjdGluZyByZXNwZW9uc2VzIGZyb20NCm90
aGVycyB0b28sIHBlcmhhcHMgRWluYXIgb3IgRWxsaW90Pw0KDQpFbGlvdCBjYW4gY29uZmlybSBp
ZiBoZSBmZWVscyBoaXMgaXNzdWVzIGhhdmUgYmVlbiBhZGRyZXNzZWQuDQoNCg0KDQoNCjEgSURO
SVRTDQoNCiAtIHNvbWUgaXNzdWVzIGZvdW5kIGJ5IGlkbml0cw0KIC0gdXNpbmcgaHR0cHM6Ly91
cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdf
dG9vbHNfaWRuaXRzXyZkPUR3SUNBZyZjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIz
dm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pv
Jm09N0J4M2hnb2ZTRnh2TlJWN1h6N0Z1YUpjS0tmekVCMHNCSnpOX0tPQ3RTZyZzPV81Zi1seENv
SlcyVGlkY3JqV19LYkRrZFBoZnhMb0w2N2tuMUEyb2tnczAmZT0NCiAtIHdpdGhvdXQgc2VsZWN0
aW5nICJ2ZXJib3NlIG91dHB1dCINCg0KDQoxLjENCg0KICoqIFRoZXJlIGFyZSA1IGluc3RhbmNl
cyBvZiB0b28gbG9uZyBsaW5lcyBpbiB0aGUgZG9jdW1lbnQsIHRoZSBsb25nZXN0IG9uZQ0KICAg
IGJlaW5nIDUgY2hhcmFjdGVycyBpbiBleGNlc3Mgb2YgNzIuDQoNCkZpeGVkLg0KDQoNCg0KDQog
VGhpcyAiKioiIGlzIGJlaW5nIGZsYWdnZWQgYXMgYW4gImVycm9yIi4NCiBJZG5pdHMgbGFiZWws
IG5vdCBtaW5lLiAgUGxlYXNlIGZpeC4NCg0KDQoxLjINCg0KID09IFRoZXJlIGFyZSA3IGluc3Rh
bmNlcyBvZiBsaW5lcyB3aXRoIG5vbi1SRkM2ODkwLWNvbXBsaWFudCBJUHY0IGFkZHJlc3Nlcw0K
ICAgIGluIHRoZSBkb2N1bWVudC4gIElmIHRoZXNlIGFyZSBleGFtcGxlIGFkZHJlc3NlcywgdGhl
eSBzaG91bGQgYmUgY2hhbmdlZC4NCg0KIFRoaXMgaXMganVzdCBhIHdhcm5pbmcsIGJ1dCBnaXZl
biB0aGF0IHRoZXJlIGFyZSBzZXZlbiBvY2N1cnJlbmNlcywgaXQNCiBtaWdodCBiZSBhIGdvb2Qg
aWRlYSB0byBmaXguICBQbGVhc2Ugc2VlIFNlY3Rpb24gMywgcG9pbnQgIzYgaW4gdGhpcw0KIGRv
Y3VtZW50IGZvciBkZXRhaWxzOiBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19pZC0yRGluZm9fY2hlY2tsaXN0JmQ9RHdJQ0Fn
JmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5K
VXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT03QngzaGdvZlNGeHZOUlY3WHo3
RnVhSmNLS2Z6RUIwc0JKek5fS09DdFNnJnM9QVlvOFpIUFk0U0FITXFjeTFxVjl5cjdCam94R3lf
Qzl6Y0pfWmJ3WEJUNCZlPS4NCg0KRml4ZWQuDQoNCg0KDQoNCjEuMw0KDQogKiogVGhlIGRvY3Vt
ZW50IHNlZW1zIHRvIGxhY2sgYSBib3RoIGEgcmVmZXJlbmNlIHRvIFJGQyAyMTE5IGFuZCB0aGUN
CiAgICByZWNvbW1lbmRlZCBSRkMgMjExOSBib2lsZXJwbGF0ZSwgZXZlbiBpZiBpdCBhcHBlYXJz
IHRvIHVzZSBSRkMgMjExOQ0KICAgIGtleXdvcmRzLg0KDQogICAgUkZDIDIxMTkga2V5d29yZCwg
bGluZSA3OTc6ICcuLi5zLWxpc3QuIEEgZGV2aWNlIE1BWSByZXN0cmljdCB0aGUgbGVuZy4uLicN
Cg0KDQogVGhlcmUgbmVlZHMgdG8gYmUgYSBzZWN0aW9uIHRoYXQgbG9va3MgbGlrZSBSRkMgODE3
NCwgcGFyYWdyYXBoIDExOg0KDQogICAgVGhlIGtleSB3b3JkcyAiTVVTVCIsICJNVVNUIE5PVCIs
ICJSRVFVSVJFRCIsICJTSEFMTCIsICJTSEFMTCBOT1QiLA0KICAgICJTSE9VTEQiLCAiU0hPVUxE
IE5PVCIsICJSRUNPTU1FTkRFRCIsICJOT1QgUkVDT01NRU5ERUQiLCAiTUFZIiwNCiAgICBhbmQg
Ik9QVElPTkFMIiBpbiB0aGlzIGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhcw0KICAg
IGRlc2NyaWJlZCBpbiBCQ1AgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBhbmQgb25seSB3
aGVuLCB0aGV5DQogICAgYXBwZWFyIGluIGFsbCBjYXBpdGFscywgYXMgc2hvd24gaGVyZS4NCg0K
QWRkZWQuDQoNCg0KDQoNCjEuNC4NCg0KIC0tIFRoZSBkb2N1bWVudCBkYXRlIChGZWJydWFyeSAy
LCAyMDE4KSBpcyAxMSBkYXlzIGluIHRoZSBwYXN0LiAgSXMgdGhpcw0KICAgIGludGVudGlvbmFs
Pw0KDQogVGhpcyBpcyBmaW5lLCBpZ25vcmUgaXQuDQoNCjEuNQ0KDQogKiogT2Jzb2xldGUgbm9y
bWF0aXZlIHJlZmVyZW5jZTogUkZDIDI0NjANCg0KIFRoaXMgbmVlZHMgdG8gYmUgZml4ZWQuDQoN
ClVwZGF0ZWQgdGhlIHJlZmVyZW5jZSB0byBSRkMgODIwMC4NCg0KDQoNCjEuNg0KDQogKiogRG93
bnJlZjogTm9ybWF0aXZlIHJlZmVyZW5jZSB0byBhbiBIaXN0b3JpYyBSRkM6IFJGQyAzNTQwDQoN
CiBIbW1tbSwgYW5vdGhlciBISVNUT1JJQyBkb2N1bWVudCwgYnV0IHRoaXMgdGltZSBub3QgZHVl
IHRvIGFuIElFU0cNCiBhY3Rpb24uICBUaGUgcXVlc3Rpb24gaXMgaG93IGltcG9ydGFudCB0aGlz
IHJlZmVyZW5jZSBpcywgaXMgdGhpcw0KICJucyIgYml0IChFQ04tbm9uY2UgY29uY2VhbG1lbnQg
cHJvdGVjdGlvbikgY29tbW9ubHkgdXNlZCBpbiB0aGUNCiBpbmR1c3RyeT8NCg0KSSBkbyBub3Qg
a25vdyBlbm91Z2ggdG8ga25vdyBpdCBpcyBub3QgdXNlZC4gSWYgdGhlIGNvbnNlbnN1cyBpcyB0
aGF0IHdlIGRvIG5vdCB1c2UgaXQsIEkgY2FuIGRyb3AgaXQgZnJvbSB0aGUgbW9kZWwuDQoNCjxL
RU5UPiBBcyBzaGVwaGVyZCwgSSB3b3VsZCBsaWtlIHRoZSBub3JtYXRpdmUgcmVmZXJlbmNlIHRv
IGEgaGlzdG9yaWMgUkZDIHJlbW92ZWQgZnJvbSB0aGlzIGRyYWZ0LiAgIE15IHJlY29tbWVuZGF0
aW9uIGlzIHRvIHJlbW92ZSBpdC4gIEFzIGNoYWlyLCBpZiBhbnlvbmUgd2FudHMgdG8gbWFrZSBh
IGNhc2UgZm9yIGtlZXBpbmcgdGhlICJucyIgYml0LCAqbm93KiBpcw0KeW91ciB0aW1lIHRvIHNh
eSBzb21ldGhpbmcuDQoNCg0KMS43DQoNCiA9PSBPdXRkYXRlZCByZWZlcmVuY2U6IEEgbGF0ZXIg
dmVyc2lvbiAoLTA2KSBleGlzdHMgb2YNCiAgICBkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUt
ZGlhZ3JhbXMtMDQNCg0KIFBsZWFzZSB1cGRhdGUgdG8gLTA2DQoNClRoaXMgbWlnaHQgYmUgYmVj
YXVzZSB0aGUgZHJhZnQgd2FzIGxhc3QgcHVibGlzaGVkIHdoZW4gLTA0IHdhcyBhcm91bmQuIEkg
ZG8gbm90IHJlZmVyZW5jZSBhbnkgcGFydGljdWxhciB2ZXJzaW9uLiBNeSByZWZlcmVuY2UgaXMg
dG8NCjw/cmZjIGluY2x1ZGU9J3JlZmVyZW5jZS5JLUQuaWV0Zi1uZXRtb2QteWFuZy10cmVlLWRp
YWdyYW1z4oCZPz4uIFRoZSB0b29sIHB1bGxzIGluIHRoZSBsYXRlc3Qgd2hlbiBpdCBnZW5lcmF0
ZXMgdGhlIGRyYWZ0Lg0KDQoNCjEuOA0KDQogLS0gT2Jzb2xldGUgaW5mb3JtYXRpb25hbCByZWZl
cmVuY2UgKGlzIHRoaXMgaW50ZW50aW9uYWw/KTogUkZDIDUxMDENCiAgICAoT2Jzb2xldGVkIGJ5
IFJGQyA3MDExKQ0KDQogUGxlYXNlIHVwZGF0ZSB0byBSRkMgNzAxMQ0KDQpEb25lLg0KDQoNCg0K
DQoNCjIgIFlBTkcgVkFMSURBVElPTg0KDQoyLjEgTm9ybWF0aXZlIE1vZHVsZXMNCg0KIEFsbCBv
ZiB0aGUgZm9sbG93aW5nIHBhc3NlZDoNCg0KICAgcHlhbmcgLS1pZXRmIGlldGYtYWNjZXNzLWNv
bnRyb2wtbGlzdFxAMjAxOC0wMi0wMi55YW5nDQogICBweWFuZyAtLWlldGYgaWV0Zi1wYWNrZXQt
ZmllbGRzXEAyMDE4LTAyLTAyLnlhbmcNCiAgIHB5YW5nIC0taWV0ZiBpZXRmLWV0aGVydHlwZXNc
QDIwMTgtMDItMDIueWFuZw0KDQogICB5YW5nbGludCAtcyBpZXRmLWFjY2Vzcy1jb250cm9sLWxp
c3RcQDIwMTgtMDItMDIueWFuZw0KICAgeWFuZ2xpbnQgLXMgaWV0Zi1wYWNrZXQtZmllbGRzXEAy
MDE4LTAyLTAyLnlhbmcNCiAgIHlhbmdsaW50IC1zIGlldGYtZXRoZXJ0eXBlc1xAMjAxOC0wMi0w
Mi55YW5nDQoNCjIuMiBFeGFtcGxlIE1vZHVsZQ0KDQogRXhhbXBsZSBtb2R1bGUgcGFzc2VkIGB5
YW5nbGludCAtc2AsIGJ1dCBub3QgYHB5YW5nIC0tbGludGA6DQoNCiAgIHlhbmdsaW50IC1zIGV4
YW1wbGUtbmV3Y28tYWNsLnlhbmcNCiAgIHB5YW5nIC0tbGludCBleGFtcGxlLW5ld2NvLWFjbC55
YW5nDQoNCiAgIGV4YW1wbGUtbmV3Y28tYWNsLnlhbmc6Nzg6IGVycm9yOiBrZXl3b3JkICJkZXNj
cmlwdGlvbiIgbm90IGluDQogICBjYW5vbmljYWwgb3JkZXIsIGV4cGVjdGVkICJ0eXBlIiwgKFNl
ZSBSRkMgNjAyMCwgU2VjdGlvbiAxMikNCg0KICAgZXhhbXBsZS1uZXdjby1hY2wueWFuZzo3OTog
ZXJyb3I6IGtleXdvcmQgInR5cGUiIG5vdCBpbg0KICAgY2Fub25pY2FsIG9yZGVyLCAoU2VlIFJG
QyA2MDIwLCBTZWN0aW9uIDEyKQ0KDQogICBleGFtcGxlLW5ld2NvLWFjbC55YW5nOjgyOiBlcnJv
cjoga2V5d29yZCAiZGVmYXVsdCIgbm90IGluDQogICBjYW5vbmljYWwgb3JkZXIsIChTZWUgUkZD
IDYwMjAsIFNlY3Rpb24gMTIpDQoNCiBQbGVhc2UgZml4Lg0KDQpGaXhlZC4NCg0KDQoNCg0KMi4z
IFhNTCBFeGFtcGxlcyBmcm9tIFNlY3Rpb24gNC4zDQoNCiB5YW5nbGludCBkaWRuJ3QgZmluZCBh
bnkgaXNzdWVzOg0KDQogICB5YW5nbGludCBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3RcQDIwMTgt
MDItMDIueWFuZyBleC00LjMueG1sDQoNCg0KMi40IEV4YW1wbGVzIGZyb20gU2VjdGlvbiA0LjQN
Cg0KIEkgaGFkIHRvIHN0aXRjaCB0aGVzZSBpbnRvIHRoZSA0LjMgZXhhbXBsZS4gIEl0IGZvdW5k
IG9uZSBpc3N1ZSwgYSB0eXBvDQogaW4gdGhlIGxhc3QgY2xvc2luZyB0YWcgaW4gdGhlIGZpcnN0
IGV4YW1wbGUgaW4gdGhpcyBzZWN0aW9uOg0KDQogICB5YW5nbGludCBpZXRmLWFjY2Vzcy1jb250
cm9sLWxpc3RcQDIwMTgtMDItMDIueWFuZyBleC00LjQrKy54bWwNCiAgIGVyciA6IEludmFsaWQg
KG1peGVkIG5hbWVzKSBvcGVuaW5nIChzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcikgYW5k
IGNsb3NpbmcgKHRjcCkgZWxlbWVudCB0YWdzLiAoL2RhdGEvYWNjZXNzLWxpc3RzL2FjbC9hY2Vz
L2FjZS9tYXRjaGVzL2w0L3RjcC9zb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvci9zb3VyY2Ut
cG9ydC1yYW5nZS1vci1vcGVyYXRvcikNCg0KIFBsZWFzZSBmaXguDQoNCk1hZGUgdGhlbSBjb21w
bGV0ZSBleGFtcGxlcyBzbyB5b3UgZG8gbm90IGhhdmUgdG8gc3RpdGNoIHRoZW0gYW55bW9yZS4g
QW5kIG1hZGUgc3VyZSB5YW5nbGludCB2YWxpZGF0ZWQgdGhlIGV4YW1wbGVzIGJlZm9yZSBpdCBp
bmNsdWRlcyBpdCBpbiB0aGUgZHJhZnQuDQoNCg0KDQoNCiBQUzogQW5kIHRoaXMgaXMgbm90IGEg
c2hlcGhlcmQgZGlyZWN0aXZlLCBidXQgSSBmb3VuZCB0aGUgd2hvbGUNCiAgICAgInNvdXJjZS1w
b3J0LXJhbmdlLW9yLW9wZXJhdG9yIiBzeW50YXggY2x1bXN5LiAgSSdtIHN1cnByaXNlZA0KICAg
ICBpdCBkaWRuJ3QgbG9vayBzb21ldGhpbmcgbGlrZToNCg0KICAgICAgICAgT0xEDQogICAgICAg
ICAgICAgICA8c291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3I+DQogICAgICAgICAgICAgICAg
ICA8cG9ydC1yYW5nZS1vci1vcGVyYXRvcj4NCiAgICAgICAgICAgICAgICAgICAgPHJhbmdlPg0K
ICAgICAgICAgICAgICAgICAgICAgIDxsb3dlci1wb3J0PjE2Mzg0PC9sb3dlci1wb3J0Pg0KICAg
ICAgICAgICAgICAgICAgICAgIDx1cHBlci1wb3J0PjY1NTM1PC91cHBlci1wb3J0Pg0KICAgICAg
ICAgICAgICAgICAgICA8L3JhbmdlPg0KICAgICAgICAgICAgICAgICAgPC9wb3J0LXJhbmdlLW9y
LW9wZXJhdG9yPg0KICAgICAgICAgICAgICAgPC9zb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRv
cj4NCg0KICAgICAgICAgICAgICAgPHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yPg0KICAg
ICAgICAgICAgICAgICA8cG9ydC1yYW5nZS1vci1vcGVyYXRvcj4NCiAgICAgICAgICAgICAgICAg
ICA8b3BlcmF0b3I+DQogICAgICAgICAgICAgICAgICAgICA8b3BlcmF0b3I+ZXE8L29wZXJhdG9y
Pg0KICAgICAgICAgICAgICAgICAgICAgPHBvcnQ+MjE8L3BvcnQ+DQogICAgICAgICAgICAgICAg
ICAgPC9vcGVyYXRvcj4NCiAgICAgICAgICAgICAgICAgPC9wb3J0LXJhbmdlLW9yLW9wZXJhdG9y
Pg0KICAgICAgICAgICAgICAgPC9zb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcj4NCg0KICAg
ICAgICAgTkVXDQoNCiAgICAgICAgICAgICAgIDxzb3VyY2UtcG9ydD4NCiAgICAgICAgICAgICAg
ICAgPHJhbmdlPg0KICAgICAgICAgICAgICAgICAgIDxsb3dlcj4xNjM4NDwvbG93ZXI+DQogICAg
ICAgICAgICAgICAgICAgPHVwcGVyPjY1NTM1PC91cHBlcj4NCiAgICAgICAgICAgICAgICAgPC9y
YW5nZT4NCiAgICAgICAgICAgICAgIDwvc291cmNlLXBvcnQ+DQoNCiAgICAgICAgICAgICAgIDxz
b3VyY2UtcG9ydD4NCiAgICAgICAgICAgICAgICAgPG9wZXJhdG9yPg0KICAgICAgICAgICAgICAg
ICAgIDxvcGVyYXRvcj5lcTwvb3BlcmF0b3I+DQogICAgICAgICAgICAgICAgICAgPHBvcnQ+MjE8
L3BvcnQ+DQogICAgICAgICAgICAgICAgIDwvb3BlcmF0b3I+DQogICAgICAgICAgICAgICA8L3Nv
dXJjZS1wb3J0Pg0KDQpEaWQgeW91IHRyeSBtYWtpbmcgdGhlIGNoYW5nZSBpbiB0aGUgbW9kZWwg
dG8gc2VlIGlmIGl0IHdvcms/IEl0IHdpbGwgY29tcGxhaW4gdGhhdCA8cmFuZ2U+IGlzIGFscmVh
ZHkgdXNlZCB3aXRoaW4gdGhlIGNvbnRhaW5lciBhbmQgdGhhdCBpdCBjYW5ub3QgYmUgcmVwZWF0
ZWQgKGZvciBkZXN0aW5hdGlvbi1wb3J0KS4NCg0KPEtFTlQ+IE5vLCBJIGRpZCBub3QsIG5vciBk
byBJIGludGVuZCB0byBnZXQgdGhhdCBkZWVwIGludG8gaXQuICBCdXQgSSByZWNhbGwgdGhhdCBL
cmlzdGlhbiBtYWRlIHRoZSBzYW1lIGNvbW1lbnQgYmVmb3JlLCBhbmQgd2FzIG1ha2luZyBwdWxs
IHJlcXVlc3RzIGJlZm9yZSwgc28gbWF5YmUgaGUgY2FuIHN1Z2dlc3Qgc29tZXRoaW5nPw0KDQoN
CjMgS2V5IERyYWZ0IFNlY3Rpb25zDQoNCg0KMy4xIEFic3RyYWN0DQoNCiBGaXJzdCwgSSdtIHVu
c3VyZSBpZiB0aGF0IGZpcnN0ICJzZW50ZW5jZSIgaXMgcHJvcGVybHkgd29yZGVkLCBidXQgSQ0K
IGRlZmluaXRlbHkgdGhpbmsgdGhhdCBpdCBpcyBhIGJpdCB0b28gbXVjaCBvbiB0aGUgdGVyc2Ug
c2lkZS4gIENhbiB5b3UNCiBlbWJlbGxpc2ggaXQgYSBsaXR0bGU/DQoNCkhvdyBhYm91dCB0aGlz
Og0KDQpPTEQ6DQoNCiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBkYXRhIG1vZGVsIG9mIEFj
Y2VzcyBDb250cm9sIExpc3QgKEFDTCkNCg0KICBiYXNpYyBidWlsZGluZyBibG9ja3MuDQpORVc6
DQoNCiAgVGhpcyBkb2N1bWVudCBkZXNjcmliZXMgYSBkYXRhIG1vZGVsIGZvciBBY2Nlc3MgQ29u
dHJvbCBMaXN0IChBQ0wpLg0KICBBQ0wgaXMgYSBvcmRlcmVkLWJ5LXVzZXIgc2V0IG9mIHJ1bGVz
LCB1c2VkIHRvIGNvbmZpZ3VyZSB0aGUgZm9yd2FyZGluZw0KICBiZWhhdmlvciBpbiBkZXZpY2Uu
ICBFYWNoIHJ1bGUgaXMgdXNlZCB0byBmaW5kIGEgbWF0Y2ggb24gYSBwYWNrZXQsDQogIGFuZCBk
ZWZpbmUgYWN0aW9ucyB0aGF0IHdpbGwgYmUgcGVyZm9ybWVkIG9uIHRoZSBwYWNrZXQuDQoNCjxL
RU5UPiBnb29kLg0KDQoNCiBTZWNvbmQsIGFtIEkgcmVhZGluZyBpdCBjb3JyZWN0PyAtIGlzIHRo
ZSAiRWRpdG9yaWFsIE5vdGUiIGluIHRoZQ0KIEFic3RyYWN0IHNlY3Rpb24uICBJIHN0cm9uZ2x5
IGFkdmlzZSBtb3ZpbmcNCg0KTW92ZWQgaXQgdG8gSW50cm9kdWN0aW9uIHNlY3Rpb24uDQoNCjxL
RU5UPiB3YXMgaXQgYmVmb3JlIGluIGEgPG5vdGU+IGVsZW1lbnQ/ICAgSXQgbWF5IGhhdmUganVz
dCBiZWVuIGEgcmVuZGVyaW5nIGlzc3VlIHRoYXQgbWFkZSBpdCBsb29rIGxpa2UgaXQgd2FzIHBh
ciBvZiB0aGUgYWJzdHJhY3QuICBJZiBpdCB3YXMgYSA8bm90ZT4gYmVmb3JlLCB0aGVuIHRoYXQg
aXMgYWN0dWFsbHkgYSBjb21tb24gdXNlIG9mIHRoZSA8bm90ZT4gZWxlbWVudC4gIEl0IGRvZXNu
J3QgcmVhbGx5IG1hdHRlciwgdGhlIFJGQyBFZGl0b3Igd2lsbCByZW1vdmUgdGhlIHNlY3Rpb24g
YW55d2F5Lg0KDQoNCjMuMiBSRkMgRWRpdG9yIE5vdGUNCg0KIFRoZXJlIGlzIG5vIHJlcXVlc3Qg
dG8gcmVwbGFjZSAiSS1ELmlldGYtbmV0bW9kLXlhbmctdHJlZS1kaWFncmFtcyIgd2l0aA0KIHRo
ZSBmaW5hbCBSRkMgYXNzaWdubWVudC4NCg0KQWRkZWQuDQoNCg0KDQogWW91IG1pZ2h0IHdhbnQg
dG8gYWRkIHdoYXQgdGhlIGN1cnJlbnQgZGF0ZSB2YWx1ZSB1c2VkIGluIHRoZSBkcmFmdCBpcw0K
IChpLmUuLCAyMDE4LTAyLTAyKS4gICBQUzogbXkgZHJhZnQgYnVpbGQgdG9vbHMsIHdoaWNoIEkg
dGhpbmsgeW91J3JlDQogdXNpbmcsIHNob3VsZCBzZXQgdGhlIHZhbHVlIGZvciB5b3UgYXV0b21h
dGljYWxseSBpZiB5b3UgcHV0IFlZWVktTU0tREQNCiBpbnRvIHRoZSB0ZXh0Lg0KDQpBZGRlZCB0
ZXh0IHRvIHJlcGxhY2UgdGhlIHJldmlzaW9uIGRhdGUgaW4gdGhlIG1vZGVsIHdpdGggdGhlIGRh
dGUgdGhlIGRyYWZ0IGdldHMgcHVibGlzaGVkLg0KDQoNCg0KMy4zIEltcG9ydCBzdGF0ZW1lbnRz
IG1pc3NpbmcgcmVmZXJlbmNlcw0KDQogQWxsIGltcG9ydCBzdGF0ZW1lbnRzIGluIGFsbCBtb2R1
bGVzIGFyZSBtaXNzaW5nIHJlZmVyZW5jZSBzdGF0ZW1lbnRzDQogICAgLSB3aHkgd2Fzbid0IHRo
aXMgY2F1Z2h0IGJ5IHRoZSB0b29scz8hDQoNCiBQbGVhc2Ugc2VlIHJmYzYwODdiaXMgU2VjdGlv
biA0LjcuDQoNCkFkZGluZyByZWZlcmVuY2UgaW1wbGllcyBpbXBvcnQgYnkgcmV2aXNpb24sIHdo
aWNoIHdlIHdhbnQgdG8gYXZvaWQsIHNwZWNpYWxseSBzaW5jZSB3ZSBkbyBub3Qgd2FudCB0byBp
bXBvcnQgYnkgcmV2aXNpb24uIFJpZ2h0Pw0KDQo8S0VOVD4gSSB3cm90ZSAicmVmZXJlbmNlIiAo
bm90ICJyZXZpc2lvbiIpLiAgQSByZWZlcmVuY2Ugc3RhdGVtZW50IGp1c3Qgc3BlY2lmaWVzIHdo
aWNoIFJGQyB0aGUgaW1wb3J0ZWQgbW9kdWxlIGlzIGRlZmluZWQgaW4uDQoNCg0KMy40IFNlY3Vy
aXR5IENvbnNpZGVyYXRpb25zDQoNCiBQbGVhc2UgcmVmb3JtYXQgdGhlIGxhc3QgcGFyYWdyYXBo
IHNvIHRoZSAiYWNlcyIgcGF0aCBpcyBtb3JlIHByb25vdW5jZWQuDQogUGVyaGFwcyB1c2UgaGFu
Z1RleHQuDQoNCldoYXQgaXMgaGFuZ1RleHQ/IEkgaXRhbGljaXplZCBpdC4NCg0KPEtFTlQ+IGh0
dHBzOi8veG1sMnJmYy50b29scy5pZXRmLm9yZy94bWwycmZjRkFRLmh0bWwjcV9oYW5naW5nX2xp
c3RzDQoNCg0KDQozLjUgSUFOQSBDb25zaWRlcmF0aW9ucw0KDQogVGhpcyBzZWN0aW9uIGlzIGhh
cmQgdG8gcmVhZC4NCg0KIENvbnNpZGVyYXRpb24gYnJlYWtpbmcgdXAgdGhlICJYTUwiIGFuZCB0
aGUgIllBTkcgTW9kdWxlIE5hbWVzIiByZWdpc3RyeQ0KIHJlcXVlc3RzIGludG8gdHdvIHN1YnNl
Y3Rpb25zLg0KDQogQ29uc2lkZXIgbWFraW5nIHRoZSByZWdpc3RyYXRpb24gZW50cnkgcmVxdWVz
dHMgdGhlbXNlbHZlcyBhcnR3b3JrIHNvDQogdGhleSdyZSBsaW5lLXNwYWNlZCBhbmQgaW5kZW50
ZWQgYXMgc3VjaC4NCg0KIFRoZSBmaXJzdCBwYXJhZ3JhcGggb2YgdGhlICJYTUwiIHJlZ2lzdHJ5
IHJlcXVlc3Qgc2F5cyAiYSBVUkkiLCBidXQgaXQNCiBzaG91bGQgYmUgInR3byBVUklzIg0KDQog
VGhlIGZpcnN0IHBhcmFncmFwaCBvZiB0aGUgIllBTkcgTW9kdWxlIE5hbWVzIiByZWdpc3RyeSBy
ZXF1ZXN0IHNheXMNCiAiYSBZQU5HIG1vZHVsZSIsIGJ1dCBpdCBzaG91bGQgYmUgInR3byBZQU5H
IG1vZHVsZXPigJ0NCg0KU3BsaXQgaW50byB0d28gc2VjdGlvbnMgYW5kIHVwcGVkIHRoZSBjb3Vu
dCBvZiBVUklzIGFuZCBZQU5HIG1vZGVscyB0byB0aHJlZSAod2FzIG1pc3NpbmcgdGhlIGlldGYt
ZXRoZXJ0eXBlcyBtb2R1bGUpLg0KDQoNCg0KDQozLjYgUmVmZXJlbmNlcw0KDQogSSBoYXZlbid0
IGNoZWNrZWQgeWV0LCBidXQgcGxlYXNlIHZlcmlmeSB0aGF0IGFsbCB0aGUgcmVmZXJlbmNlcyBh
cmUNCiBwcm9wZXJseSBzb3J0ZWQgYXMgdG8gYmVpbmcgTm9ybWF0aXZlIG9yIEluZm9ybWF0aXZl
Lg0KDQoNCjMuNyBBcHBlbmRpeCBBDQoNCiBJdCB0b29rIG1lIGF3aGlsZSB0byBmaWd1cmUgb3V0
IHdoYXQgSSB3YXMgbG9va2luZyBhdC4gIFRoZSB0cmVlLWRpYWdyYW0NCiBpcyBwb29ybHkgaW5k
ZW50ZWQgYW5kIHRoZXJlIGlzIG5vIHRleHQgcHJlY2VkaW5nIHRoZSBleGFtcGxlIG1vZHVsZS4N
Cg0KSSBoYXZlIG1vdmVkIHRoZSBleGFtcGxlIG1vZHVsZSBhZnRlciB0aGUgZmlyc3QgcGFyYWdy
YXBoLCB0aGF0IGRlc2NyaWJlcyB0aGUgbW9kdWxlLiBMZXQgbWUga25vdyBpZiB0aGF0IGxvb2tz
IG9rLg0KDQoNCg0KIEkgcmVjb21tZW5kIHlvdSBmb2xkIHRoZSBsaW5lcyBvZiB5b3VyIHRyZWUg
ZGlhZ3JhbSBhdCBhIGNlcnRhaW4gY29sdW1uDQogd2hpbHN0IGFkZGluZyBhICdcJyBjaGFyYWN0
ZXIuICBJJ3ZlIHNpbmNlIGFkZGVkIHRoaXMgYWJpbGl0eSB0byBteSBkcmFmdA0KIGJ1aWxkIHRv
b2xzLCBsZXQgbWUga25vdyBpZiBpbnRlcmVzdGVkIGluIGFuIHVwZGF0ZS4gIFlvdSBtaWdodCBh
bHNvIHdhbnQNCiB0byBsb29rIGF0IGRyYWZ0LXd1LW5ldG1vZC15YW5nLXhtbC1kb2MtY29udmVu
dGlvbnMuDQoNClNob3J0ZW5lZCB0aGUgcHJlZml4IHNvIHRoZSBhdWdtZW50IHN0YXRlbWVudCBm
aXRzIHdpdGhpbiA3MiBjb2x1bW5zLg0KDQpCVFcsIEkgdXNlICdweWFuZyAgLWYgdHJlZSDigJR0
cmVlLWxpbmUtbGVuZ3RoPTY5JyB0byBnZW5lcmF0ZSB0aGUgdHJlZS4gUGx1cyBJIHVzZSBmb2xk
IC13IDcxIHRvIGZvbGQgdGhlIGRpYWdyYW0sIGJ1dCBJIGd1ZXNzIGl0IGRvZXMgbm90IHdvcmsg
Zm9yIGF1Z21lbnQgc3RhdGVtZW50Lg0KDQoNCg0KIEFsc28sIHBsZWFzZSBmaXggdGhlIGV4YW1w
bGUgbW9kdWxlJ3MgbmFtZXNwYWNlIHBlciB0aGUgZW5kIG9mDQogcmZjNjA4N2JpcyBTZWN0aW9u
IDQuOS4NCg0KVXBkYXRlZCB0aGUgbmFtZXNwYWNlIHRvIOKAnGh0dHA6Ly9leGFtcGxlLmNvbS9u
cy9leGFtcGxlLW5ld2NvLWFjbDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIv
dXJsP3U9aHR0cC0zQV9fZXhhbXBsZS5jb21fbnNfZXhhbXBsZS0yRG5ld2NvLTJEYWNsJmQ9RHdN
RmFRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1Aw
eG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT15V2FOUDNDT0JUOFRnbVZE
NVlDTTVNVDNSS2J1cEpSbTZCV0N6UHlpQzRrJnM9TGNMU0Q0Rlh1NVc3dnF0RTY2QWZGb2tUcThO
NjZhb3NBT3VCdU8zRzczSSZlPT7igJ0NCg0KQ2hlZXJzLg0KDQoNCg0KDQoNClRoYW5rcywNCktl
bnQNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X18NCk5ldGNvbmYgbWFpbGluZyBsaXN0DQpOZXRjb25mQGlldGYub3JnPG1haWx0bzpOZXRjb25m
QGlldGYub3JnPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0
dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRjb25mJmQ9RHdJQ0FnJmM9
SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZyPTl6a1AweG5KVXZa
R0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT03QngzaGdvZlNGeHZOUlY3WHo3RnVh
SmNLS2Z6RUIwc0JKek5fS09DdFNnJnM9WGtuTHFnQXUzWjl0MU1FNkZPLV9tWlkyb0NONjE4NjdW
QjB1YkxlaXYzUSZlPQ0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRtb2RAaWV0Zi5vcmcNCmh0dHBzOi8v
d3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCk1haGVzaCBKZXRoYW5hbmRh
bmkNCm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNv
bT4NCg0K

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

PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4
bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo
dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo
dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp
dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l
dGEgbmFtZT0iVGl0bGUiIGNvbnRlbnQ9IiI+DQo8bWV0YSBuYW1lPSJLZXl3b3JkcyIgY29udGVu
dD0iIj4NCjxtZXRhIG5hbWU9IkdlbmVyYXRvciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUg
KGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxlPjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8N
CkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNvdXJpZXIgTmV3IjsNCglwYW5vc2UtMToyIDcg
MyA5IDIgMiA1IDIgNCA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6IkNhbWJyaWEgTWF0
aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1mYWNlDQoJe2ZvbnQt
ZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAyIDQ7fQ0KLyogU3R5
bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWwsIGRpdi5Nc29Ob3Jt
YWwNCgl7bWFyZ2luOjBpbjsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEy
LjBwdDsNCglmb250LWZhbWlseToiVGltZXMgTmV3IFJvbWFuIjt9DQphOmxpbmssIHNwYW4uTXNv
SHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpibHVlOw0KCXRleHQt
ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KYTp2aXNpdGVkLCBzcGFuLk1zb0h5cGVybGlua0ZvbGxv
d2VkDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xvcjpwdXJwbGU7DQoJdGV4dC1kZWNv
cmF0aW9uOnVuZGVybGluZTt9DQpwcmUNCgl7bXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCBDaGFyIjsNCgltYXJnaW46MGluOw0KCW1hcmdp
bi1ib3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTAuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDb3Vy
aWVyIE5ldyI7fQ0Kc3Bhbi5IVE1MUHJlZm9ybWF0dGVkQ2hhcg0KCXttc28tc3R5bGUtbmFtZToi
SFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbXNvLXN0eWxlLXByaW9yaXR5Ojk5Ow0KCW1zby1z
dHlsZS1saW5rOiJIVE1MIFByZWZvcm1hdHRlZCI7DQoJZm9udC1mYW1pbHk6Q291cmllcjt9DQpz
cGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlwZTpwZXJzb25hbC1yZXBseTsNCglmb250
LWZhbWlseTpDYWxpYnJpOw0KCWZvbnQtdmFyaWFudDpub3JtYWwgIWltcG9ydGFudDsNCgljb2xv
cjp3aW5kb3d0ZXh0Ow0KCXRleHQtdHJhbnNmb3JtOm5vbmU7DQoJdGV4dC1kZWNvcmF0aW9uOm5v
bmUgbm9uZTsNCgl2ZXJ0aWNhbC1hbGlnbjpiYXNlbGluZTt9DQpzcGFuLm1zb0lucw0KCXttc28t
c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCgltc28tc3R5bGUtbmFtZToiIjsNCgl0ZXh0LWRlY29y
YXRpb246dW5kZXJsaW5lOw0KCWNvbG9yOnRlYWw7fQ0KLk1zb0NocERlZmF1bHQNCgl7bXNvLXN0
eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBwdDt9DQpAcGFnZSBXb3JkU2Vj
dGlvbjENCgl7c2l6ZTo4LjVpbiAxMS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEu
MGluO30NCmRpdi5Xb3JkU2VjdGlvbjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHls
ZT4NCjwvaGVhZD4NCjxib2R5IGJnY29sb3I9IndoaXRlIiBsYW5nPSJFTi1VUyIgbGluaz0iYmx1
ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPkhpIE1haGVzaCw8
bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPlBsZWFzZSBz
ZWFyY2ggZm9yICZsdDtLRU5UJmd0OyBiZWxvdyAoNiBpbnN0YW5jZXMpPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh
bGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj5UaGFua3MsPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNh
bGlicmkiPktlbnQgLy8gc2hlcGhlcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
ZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+T24gMi8xNy8xOCwgODoyNiBQTSwgJnF1b3Q7TWFoZXNo
IEpldGhhbmFuZGFuaSZxdW90OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21h
aWwuY29tIj5tamV0aGFuYW5kYW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCwgPG86cD48
L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MgZm9yIGEgZGV0
YWlsZWQgcmV2aWV3LiBTZWUgaW5saW5lLjxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+T24gRmViIDEzLCAyMDE4LCBhdCAyOjMwIFBNLCBLZW50IFdhdHNlbiAm
bHQ7PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiPmt3YXRzZW5AanVuaXBlci5u
ZXQ8L2E+Jmd0OyB3cm90ZTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPltzb3JyeSwgd3JvbmcgV0csIG1vdmluZyBuZXRjb25mIHRvIEJDQyFdPGJyPg0KPGJy
Pg0KPGJyPg0KQUNMIEF1dGhvcnMsPGJyPg0KPGJyPg0KQmVsb3cgYXJlIHNvbWUgaXNzdWVzIEkg
Zm91bmQgd2hpbGUgbG9va2luZyBhdCBkb2luZyB0aGUgU2hlcGhlcmQ8YnI+DQp3cml0ZS11cCB0
b2RheS4gJm5ic3A7UGxlYXNlIHRha2UgYSBsb29rLjxicj4NCjxicj4NCkFsc28sIHdpdGggcmVn
YXJkcyB0byB0aGUgcmVxdWVzdCBmb3IgdGhvc2UgaGF2aW5nIExhc3QgQ2FsbCBjb21tZW50czxi
cj4NCnRvIHBsZWFzZSB2ZXJpZnkgdGhhdCB0aGVpciBjb21tZW50cyB3ZXJlIGFkZHJlc3NlZCwg
SSBvbmx5IHNhdyBvbmU8YnI+DQpyZXNwb25zZSBmcm9tIEtyaXN0aWFuLCBidXQgc2hvdWxkIHdl
IGJlIGV4cGVjdGluZyByZXNwZW9uc2VzIGZyb208YnI+DQpvdGhlcnMgdG9vLCBwZXJoYXBzIEVp
bmFyIG9yIEVsbGlvdD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVv
dGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkVsaW90IGNhbiBjb25maXJtIGlmIGhlIGZlZWxz
IGhpcyBpc3N1ZXMgaGF2ZSBiZWVuIGFkZHJlc3NlZC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjEgSUROSVRT
PGJyPg0KPGJyPg0KJm5ic3A7LSBzb21lIGlzc3VlcyBmb3VuZCBieSBpZG5pdHM8YnI+DQombmJz
cDstIHVzaW5nIDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91
cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX3Rvb2xzX2lkbml0c18mYW1wO2Q9RHdJQ0FnJmFt
cDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXpr
UDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT03QngzaGdvZlNG
eHZOUlY3WHo3RnVhSmNLS2Z6RUIwc0JKek5fS09DdFNnJmFtcDtzPV81Zi1seENvSlcyVGlkY3Jq
V19LYkRrZFBoZnhMb0w2N2tuMUEyb2tnczAmYW1wO2U9Ij4NCmh0dHBzOi8vdXJsZGVmZW5zZS5w
cm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX3Rvb2xzX2lkbml0
c18mYW1wO2Q9RHdJQ0FnJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9E
VFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNa
byZhbXA7bT03QngzaGdvZlNGeHZOUlY3WHo3RnVhSmNLS2Z6RUIwc0JKek5fS09DdFNnJmFtcDtz
PV81Zi1seENvSlcyVGlkY3JqV19LYkRrZFBoZnhMb0w2N2tuMUEyb2tnczAmYW1wO2U9PC9hPjxi
cj4NCiZuYnNwOy0gd2l0aG91dCBzZWxlY3RpbmcgJnF1b3Q7dmVyYm9zZSBvdXRwdXQmcXVvdDs8
YnI+DQo8YnI+DQo8YnI+DQoxLjE8YnI+DQo8YnI+DQombmJzcDsqKiBUaGVyZSBhcmUgNSBpbnN0
YW5jZXMgb2YgdG9vIGxvbmcgbGluZXMgaW4gdGhlIGRvY3VtZW50LCB0aGUgbG9uZ2VzdCBvbmU8
YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDtiZWluZyA1IGNoYXJhY3RlcnMgaW4gZXhjZXNz
IG9mIDcyLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+Rml4ZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9j
a3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQombmJzcDtUaGlzICZx
dW90OyoqJnF1b3Q7IGlzIGJlaW5nIGZsYWdnZWQgYXMgYW4gJnF1b3Q7ZXJyb3ImcXVvdDsuICZu
YnNwOzxicj4NCiZuYnNwO0lkbml0cyBsYWJlbCwgbm90IG1pbmUuICZuYnNwO1BsZWFzZSBmaXgu
PGJyPg0KPGJyPg0KPGJyPg0KMS4yPGJyPg0KPGJyPg0KJm5ic3A7PT0gVGhlcmUgYXJlIDcgaW5z
dGFuY2VzIG9mIGxpbmVzIHdpdGggbm9uLVJGQzY4OTAtY29tcGxpYW50IElQdjQgYWRkcmVzc2Vz
PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aW4gdGhlIGRvY3VtZW50LiAmbmJzcDtJZiB0
aGVzZSBhcmUgZXhhbXBsZSBhZGRyZXNzZXMsIHRoZXkgc2hvdWxkIGJlIGNoYW5nZWQuPGJyPg0K
PGJyPg0KJm5ic3A7VGhpcyBpcyBqdXN0IGEgd2FybmluZywgYnV0IGdpdmVuIHRoYXQgdGhlcmUg
YXJlIHNldmVuIG9jY3VycmVuY2VzLCBpdDxicj4NCiZuYnNwO21pZ2h0IGJlIGEgZ29vZCBpZGVh
IHRvIGZpeC4gJm5ic3A7UGxlYXNlIHNlZSBTZWN0aW9uIDMsIHBvaW50ICM2IGluIHRoaXM8YnI+
DQombmJzcDtkb2N1bWVudCBmb3IgZGV0YWlsczogPGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNl
LnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfaWQtMkRpbmZv
X2NoZWNrbGlzdCZhbXA7ZD1Ed0lDQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1L
LW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZq
SVNsYUpkY1pvJmFtcDttPTdCeDNoZ29mU0Z4dk5SVjdYejdGdWFKY0tLZnpFQjBzQkp6Tl9LT0N0
U2cmYW1wO3M9QVlvOFpIUFk0U0FITXFjeTFxVjl5cjdCam94R3lfQzl6Y0pfWmJ3WEJUNCZhbXA7
ZT0iPg0KaHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB
X193d3cuaWV0Zi5vcmdfaWQtMkRpbmZvX2NoZWNrbGlzdCZhbXA7ZD1Ed0lDQWcmYW1wO2M9SEFr
WXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2
WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPTdCeDNoZ29mU0Z4dk5SVjdY
ejdGdWFKY0tLZnpFQjBzQkp6Tl9LT0N0U2cmYW1wO3M9QVlvOFpIUFk0U0FITXFjeTFxVjl5cjdC
am94R3lfQzl6Y0pfWmJ3WEJUNCZhbXA7ZT08L2E+LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Rml4ZWQuPG86cD48
L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+
DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
YnI+DQo8YnI+DQoxLjM8YnI+DQo8YnI+DQombmJzcDsqKiBUaGUgZG9jdW1lbnQgc2VlbXMgdG8g
bGFjayBhIGJvdGggYSByZWZlcmVuY2UgdG8gUkZDIDIxMTkgYW5kIHRoZTxicj4NCiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO3JlY29tbWVuZGVkIFJGQyAyMTE5IGJvaWxlcnBsYXRlLCBldmVuIGlm
IGl0IGFwcGVhcnMgdG8gdXNlIFJGQyAyMTE5PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
a2V5d29yZHMuIDxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO1JGQyAyMTE5IGtl
eXdvcmQsIGxpbmUgNzk3OiAnLi4ucy1saXN0LiBBIGRldmljZSBNQVkgcmVzdHJpY3QgdGhlIGxl
bmcuLi4nPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7VGhlcmUgbmVlZHMgdG8gYmUgYSBzZWN0aW9u
IHRoYXQgbG9va3MgbGlrZSBSRkMgODE3NCwgcGFyYWdyYXBoIDExOjxicj4NCjxicj4NCiZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwO1RoZSBrZXkgd29yZHMgJnF1b3Q7TVVTVCZxdW90OywgJnF1b3Q7
TVVTVCBOT1QmcXVvdDssICZxdW90O1JFUVVJUkVEJnF1b3Q7LCAmcXVvdDtTSEFMTCZxdW90Oywg
JnF1b3Q7U0hBTEwgTk9UJnF1b3Q7LDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZxdW90
O1NIT1VMRCZxdW90OywgJnF1b3Q7U0hPVUxEIE5PVCZxdW90OywgJnF1b3Q7UkVDT01NRU5ERUQm
cXVvdDssICZxdW90O05PVCBSRUNPTU1FTkRFRCZxdW90OywgJnF1b3Q7TUFZJnF1b3Q7LDxicj4N
CiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO2FuZCAmcXVvdDtPUFRJT05BTCZxdW90OyBpbiB0aGlz
IGRvY3VtZW50IGFyZSB0byBiZSBpbnRlcnByZXRlZCBhczxicj4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwO2Rlc2NyaWJlZCBpbiBCQ1AgMTQgW1JGQzIxMTldIFtSRkM4MTc0XSB3aGVuLCBhbmQg
b25seSB3aGVuLCB0aGV5PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7YXBwZWFyIGluIGFs
bCBjYXBpdGFscywgYXMgc2hvd24gaGVyZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+
DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8
L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkZGVkLjxvOnA+PC9vOnA+
PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86
cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0K
PGJyPg0KMS40Ljxicj4NCjxicj4NCiZuYnNwOy0tIFRoZSBkb2N1bWVudCBkYXRlIChGZWJydWFy
eSAyLCAyMDE4KSBpcyAxMSBkYXlzIGluIHRoZSBwYXN0LiAmbmJzcDtJcyB0aGlzPGJyPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aW50ZW50aW9uYWw/PGJyPg0KPGJyPg0KJm5ic3A7VGhpcyBp
cyBmaW5lLCBpZ25vcmUgaXQuPGJyPg0KPGJyPg0KMS41PGJyPg0KPGJyPg0KJm5ic3A7KiogT2Jz
b2xldGUgbm9ybWF0aXZlIHJlZmVyZW5jZTogUkZDIDI0NjA8YnI+DQo8YnI+DQombmJzcDtUaGlz
IG5lZWRzIHRvIGJlIGZpeGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxv
Y2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv
cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXBkYXRlZCB0aGUgcmVmZXJlbmNlIHRv
IFJGQyA4MjAwLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGJyPg0KMS42PGJyPg0KPGJyPg0KJm5ic3A7KiogRG93bnJlZjogTm9y
bWF0aXZlIHJlZmVyZW5jZSB0byBhbiBIaXN0b3JpYyBSRkM6IFJGQyAzNTQwPGJyPg0KPGJyPg0K
Jm5ic3A7SG1tbW0sIGFub3RoZXIgSElTVE9SSUMgZG9jdW1lbnQsIGJ1dCB0aGlzIHRpbWUgbm90
IGR1ZSB0byBhbiBJRVNHPGJyPg0KJm5ic3A7YWN0aW9uLiAmbmJzcDtUaGUgcXVlc3Rpb24gaXMg
aG93IGltcG9ydGFudCB0aGlzIHJlZmVyZW5jZSBpcywgaXMgdGhpczxicj4NCiZuYnNwOyZxdW90
O25zJnF1b3Q7IGJpdCAoRUNOLW5vbmNlIGNvbmNlYWxtZW50IHByb3RlY3Rpb24pIGNvbW1vbmx5
IHVzZWQgaW4gdGhlIDxicj4NCiZuYnNwO2luZHVzdHJ5PyAmbmJzcDsmbmJzcDs8bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPkkgZG8gbm90IGtub3cgZW5vdWdoIHRvIGtub3cgaXQgaXMgbm90IHVzZWQuIElmIHRoZSBj
b25zZW5zdXMgaXMgdGhhdCB3ZSBkbyBub3QgdXNlIGl0LCBJIGNhbiBkcm9wIGl0IGZyb20gdGhl
IG1vZGVsLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PGJyPg0KJmx0O0tFTlQmZ3Q7IEFzIHNoZXBoZXJkLCBJIHdvdWxkIGxpa2UgdGhlIG5vcm1h
dGl2ZSByZWZlcmVuY2UgdG8gYSBoaXN0b3JpYyBSRkMgcmVtb3ZlZCBmcm9tIHRoaXMgZHJhZnQu
Jm5ic3A7Jm5ic3A7IE15IHJlY29tbWVuZGF0aW9uIGlzIHRvIHJlbW92ZSBpdC4mbmJzcDsgQXMg
Y2hhaXIsIGlmIGFueW9uZSB3YW50cyB0byBtYWtlIGEgY2FzZSBmb3Iga2VlcGluZyB0aGUgJnF1
b3Q7bnMmcXVvdDsgYml0LCAqbm93KiBpczxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+eW91ciB0aW1lIHRvIHNheSBzb21ldGhpbmcuPG86cD48L286cD48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48YnI+DQoxLjc8YnI+DQo8YnI+DQombmJzcDs9PSBPdXRkYXRlZCBy
ZWZlcmVuY2U6IEEgbGF0ZXIgdmVyc2lvbiAoLTA2KSBleGlzdHMgb2Y8YnI+DQombmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDtkcmFmdC1pZXRmLW5ldG1vZC15YW5nLXRyZWUtZGlhZ3JhbXMtMDQ8YnI+
DQo8YnI+DQombmJzcDtQbGVhc2UgdXBkYXRlIHRvIC0wNjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+
DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw
PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhpcyBtaWdo
dCBiZSBiZWNhdXNlIHRoZSBkcmFmdCB3YXMgbGFzdCBwdWJsaXNoZWQgd2hlbiAtMDQgd2FzIGFy
b3VuZC4gSSBkbyBub3QgcmVmZXJlbmNlIGFueSBwYXJ0aWN1bGFyIHZlcnNpb24uIE15IHJlZmVy
ZW5jZSBpcyB0byZuYnNwOw0KPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+Jmx0Oz9yZmMgaW5jbHVkZT0ncmVmZXJlbmNlLkktRC5pZXRmLW5ldG1vZC15YW5nLXRy
ZWUtZGlhZ3JhbXPigJk/Jmd0Oy4gVGhlIHRvb2wgcHVsbHMgaW4gdGhlIGxhdGVzdCB3aGVuIGl0
IGdlbmVyYXRlcyB0aGUgZHJhZnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjEuODxicj4NCjxicj4NCiZuYnNwOy0t
IE9ic29sZXRlIGluZm9ybWF0aW9uYWwgcmVmZXJlbmNlIChpcyB0aGlzIGludGVudGlvbmFsPyk6
IFJGQyA1MTAxPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7KE9ic29sZXRlZCBieSBSRkMg
NzAxMSk8YnI+DQo8YnI+DQombmJzcDtQbGVhc2UgdXBkYXRlIHRvIFJGQyA3MDExPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj5Eb25lLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPGJyPg0KMiAmbmJzcDtZQU5HIFZBTElEQVRJT048
YnI+DQo8YnI+DQoyLjEgTm9ybWF0aXZlIE1vZHVsZXM8YnI+DQo8YnI+DQombmJzcDtBbGwgb2Yg
dGhlIGZvbGxvd2luZyBwYXNzZWQ6PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7cHlhbmcg
LS1pZXRmIGlldGYtYWNjZXNzLWNvbnRyb2wtbGlzdFxAMjAxOC0wMi0wMi55YW5nIDxicj4NCiZu
YnNwOyZuYnNwOyZuYnNwO3B5YW5nIC0taWV0ZiBpZXRmLXBhY2tldC1maWVsZHNcQDIwMTgtMDIt
MDIueWFuZyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtweWFuZyAtLWlldGYgaWV0Zi1ldGhlcnR5
cGVzXEAyMDE4LTAyLTAyLnlhbmc8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDt5YW5nbGlu
dCAtcyBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3RcQDIwMTgtMDItMDIueWFuZyA8YnI+DQombmJz
cDsmbmJzcDsmbmJzcDt5YW5nbGludCAtcyBpZXRmLXBhY2tldC1maWVsZHNcQDIwMTgtMDItMDIu
eWFuZyA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDt5YW5nbGludCAtcyBpZXRmLWV0aGVydHlwZXNc
QDIwMTgtMDItMDIueWFuZyA8YnI+DQo8YnI+DQoyLjIgRXhhbXBsZSBNb2R1bGU8YnI+DQo8YnI+
DQombmJzcDtFeGFtcGxlIG1vZHVsZSBwYXNzZWQgYHlhbmdsaW50IC1zYCwgYnV0IG5vdCBgcHlh
bmcgLS1saW50YDo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDt5YW5nbGludCAtcyBleGFt
cGxlLW5ld2NvLWFjbC55YW5nPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7cHlhbmcgLS1saW50IGV4
YW1wbGUtbmV3Y28tYWNsLnlhbmcgPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7ZXhhbXBs
ZS1uZXdjby1hY2wueWFuZzo3ODogZXJyb3I6IGtleXdvcmQgJnF1b3Q7ZGVzY3JpcHRpb24mcXVv
dDsgbm90IGluPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Y2Fub25pY2FsIG9yZGVyLCBleHBlY3Rl
ZCAmcXVvdDt0eXBlJnF1b3Q7LCAoU2VlIFJGQyA2MDIwLCBTZWN0aW9uIDEyKTxicj4NCjxicj4N
CiZuYnNwOyZuYnNwOyZuYnNwO2V4YW1wbGUtbmV3Y28tYWNsLnlhbmc6Nzk6IGVycm9yOiBrZXl3
b3JkICZxdW90O3R5cGUmcXVvdDsgbm90IGluIDxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO2Nhbm9u
aWNhbCBvcmRlciwgKFNlZSBSRkMgNjAyMCwgU2VjdGlvbiAxMik8YnI+DQo8YnI+DQombmJzcDsm
bmJzcDsmbmJzcDtleGFtcGxlLW5ld2NvLWFjbC55YW5nOjgyOiBlcnJvcjoga2V5d29yZCAmcXVv
dDtkZWZhdWx0JnF1b3Q7IG5vdCBpbiA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtjYW5vbmljYWwg
b3JkZXIsIChTZWUgUkZDIDYwMjAsIFNlY3Rpb24gMTIpPGJyPg0KPGJyPg0KJm5ic3A7UGxlYXNl
IGZpeC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPkZpeGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+
DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KMi4zIFhNTCBFeGFtcGxl
cyBmcm9tIFNlY3Rpb24gNC4zPGJyPg0KPGJyPg0KJm5ic3A7eWFuZ2xpbnQgZGlkbid0IGZpbmQg
YW55IGlzc3Vlczo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDt5YW5nbGludCBpZXRmLWFj
Y2Vzcy1jb250cm9sLWxpc3RcQDIwMTgtMDItMDIueWFuZyBleC00LjMueG1sIDxicj4NCjxicj4N
Cjxicj4NCjIuNCBFeGFtcGxlcyBmcm9tIFNlY3Rpb24gNC40PGJyPg0KPGJyPg0KJm5ic3A7SSBo
YWQgdG8gc3RpdGNoIHRoZXNlIGludG8gdGhlIDQuMyBleGFtcGxlLiAmbmJzcDtJdCBmb3VuZCBv
bmUgaXNzdWUsIGEgdHlwbzxicj4NCiZuYnNwO2luIHRoZSBsYXN0IGNsb3NpbmcgdGFnIGluIHRo
ZSBmaXJzdCBleGFtcGxlIGluIHRoaXMgc2VjdGlvbjo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsm
bmJzcDt5YW5nbGludCBpZXRmLWFjY2Vzcy1jb250cm9sLWxpc3RcQDIwMTgtMDItMDIueWFuZyBl
eC00LjQmIzQzOyYjNDM7LnhtbCA8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtlcnIgOiBJbnZhbGlk
IChtaXhlZCBuYW1lcykgb3BlbmluZyAoc291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpIGFu
ZCBjbG9zaW5nICh0Y3ApIGVsZW1lbnQgdGFncy4gKC9kYXRhL2FjY2Vzcy1saXN0cy9hY2wvYWNl
cy9hY2UvbWF0Y2hlcy9sNC90Y3Avc291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3Ivc291cmNl
LXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3IpPGJyPg0KPGJyPg0KJm5ic3A7UGxlYXNlIGZpeC48bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPk1hZGUgdGhlbSBjb21wbGV0ZSBleGFtcGxlcyBzbyB5b3UgZG8gbm90IGhhdmUg
dG8gc3RpdGNoIHRoZW0gYW55bW9yZS4gQW5kIG1hZGUgc3VyZSB5YW5nbGludCB2YWxpZGF0ZWQg
dGhlIGV4YW1wbGVzIGJlZm9yZSBpdCBpbmNsdWRlcyBpdCBpbiB0aGUgZHJhZnQuPG86cD48L286
cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8
bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls
ZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxicj4NCjxicj4NCiZuYnNwO1BTOiBBbmQgdGhpcyBp
cyBub3QgYSBzaGVwaGVyZCBkaXJlY3RpdmUsIGJ1dCBJIGZvdW5kIHRoZSB3aG9sZSA8YnI+DQom
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtzb3VyY2UtcG9ydC1yYW5nZS1vci1v
cGVyYXRvciZxdW90OyBzeW50YXggY2x1bXN5LiAmbmJzcDtJJ20gc3VycHJpc2VkPGJyPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aXQgZGlkbid0IGxvb2sgc29tZXRoaW5nIGxpa2U6
PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7T0xEPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O3Nv
dXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtwb3J0LXJhbmdlLW9yLW9wZXJhdG9y
Jmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZsdDtyYW5nZSZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7
bG93ZXItcG9ydCZndDsxNjM4NCZsdDsvbG93ZXItcG9ydCZndDs8YnI+DQombmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbHQ7dXBwZXItcG9ydCZndDs2NTUzNSZsdDsvdXBwZXItcG9ydCZndDs8YnI+DQombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbHQ7L3JhbmdlJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZsdDsvcG9ydC1yYW5nZS1vci1vcGVyYXRvciZndDs8YnI+DQombmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L3NvdXJjZS1wb3J0LXJhbmdlLW9yLW9w
ZXJhdG9yJmd0Ozxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZs
dDtzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvciZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7cG9ydC1yYW5nZS1vci1vcGVyYXRvciZn
dDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbHQ7b3BlcmF0b3ImZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O29wZXJhdG9yJmd0
O2VxJmx0Oy9vcGVyYXRvciZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7cG9ydCZndDsyMSZsdDsv
cG9ydCZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbHQ7L29wZXJhdG9yJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvcG9ydC1yYW5nZS1vci1vcGVyYXRvciZndDs8
YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L3NvdXJjZS1wb3J0LXJh
bmdlLW9yLW9wZXJhdG9yJmd0Ozxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwO05FVzxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtzb3VyY2UtcG9ydCZndDs8YnI+DQombmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7cmFuZ2UmZ3Q7PGJyPg0KJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2xv
d2VyJmd0OzE2Mzg0Jmx0Oy9sb3dlciZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7dXBwZXImZ3Q7NjU1MzUmbHQ7L3Vw
cGVyJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZsdDsvcmFuZ2UmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0
Oy9zb3VyY2UtcG9ydCZndDs8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbHQ7c291cmNlLXBvcnQmZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O29wZXJhdG9yJmd0Ozxicj4NCiZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtvcGVyYXRvciZndDtl
cSZsdDsvb3BlcmF0b3ImZ3Q7PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O3BvcnQmZ3Q7MjEmbHQ7L3BvcnQmZ3Q7PGJyPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy9vcGVyYXRv
ciZndDs8YnI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L3NvdXJjZS1w
b3J0Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+RGlkIHlvdSB0cnkgbWFraW5nIHRoZSBjaGFuZ2UgaW4gdGhl
IG1vZGVsIHRvIHNlZSBpZiBpdCB3b3JrPyBJdCB3aWxsIGNvbXBsYWluIHRoYXQgJmx0O3Jhbmdl
Jmd0OyBpcyBhbHJlYWR5IHVzZWQgd2l0aGluIHRoZSBjb250YWluZXIgYW5kIHRoYXQgaXQgY2Fu
bm90IGJlIHJlcGVhdGVkIChmb3IgZGVzdGluYXRpb24tcG9ydCkuPG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQombHQ7S0VOVCZndDsgTm8s
IEkgZGlkIG5vdCwgbm9yIGRvIEkgaW50ZW5kIHRvIGdldCB0aGF0IGRlZXAgaW50byBpdC4mbmJz
cDsgQnV0IEkgcmVjYWxsIHRoYXQgS3Jpc3RpYW4gbWFkZSB0aGUgc2FtZSBjb21tZW50IGJlZm9y
ZSwgYW5kIHdhcyBtYWtpbmcgcHVsbCByZXF1ZXN0cyBiZWZvcmUsIHNvIG1heWJlIGhlIGNhbiBz
dWdnZXN0IHNvbWV0aGluZz88bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQozIEtleSBEcmFmdCBTZWN0aW9uczxicj4NCjxicj4N
Cjxicj4NCjMuMSBBYnN0cmFjdDxicj4NCjxicj4NCiZuYnNwO0ZpcnN0LCBJJ20gdW5zdXJlIGlm
IHRoYXQgZmlyc3QgJnF1b3Q7c2VudGVuY2UmcXVvdDsgaXMgcHJvcGVybHkgd29yZGVkLCBidXQg
STxicj4NCiZuYnNwO2RlZmluaXRlbHkgdGhpbmsgdGhhdCBpdCBpcyBhIGJpdCB0b28gbXVjaCBv
biB0aGUgdGVyc2Ugc2lkZS4gJm5ic3A7Q2FuIHlvdTxicj4NCiZuYnNwO2VtYmVsbGlzaCBpdCBh
IGxpdHRsZT88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhvdyBhYm91dCB0aGlzOjxvOnA+PC9vOnA+PC9wPg0KPC9k
aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5PTEQ6PG86cD48L286cD48L3A+DQo8
L2Rpdj4NCjxkaXY+DQo8cHJlIHN0eWxlPSJmb250LXZhcmlhbnQtbGlnYXR1cmVzOiBub3JtYWw7
b3JwaGFuczogMjt3aWRvd3M6IDI7d29yZC13cmFwOiBicmVhay13b3JkO3doaXRlLXNwYWNlOnBy
ZS13cmFwIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDsgVGhpcyBk
b2N1bWVudCBkZXNjcmliZXMgYSBkYXRhIG1vZGVsIG9mIEFjY2VzcyBDb250cm9sIExpc3QgKEFD
TCk8bzpwPjwvbzpwPjwvc3Bhbj48L3ByZT4NCjxwcmU+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5
OkhlbHZldGljYSI+Jm5ic3A7IGJhc2ljIGJ1aWxkaW5nIGJsb2Nrcy48L3NwYW4+PG86cD48L286
cD48L3ByZT4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk5FVzo8bzpwPjwv
bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPiZu
YnNwOyBUaGlzIGRvY3VtZW50IGRlc2NyaWJlcyBhIGRhdGEgbW9kZWwgZm9yIEFjY2VzcyBDb250
cm9sIExpc3QgKEFDTCkuICZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+Jm5ic3A7IEFDTCBpcyBhIG9yZGVyZWQtYnktdXNlciBzZXQgb2Yg
cnVsZXMsIHVzZWQgdG8gY29uZmlndXJlIHRoZSBmb3J3YXJkaW5nJm5ic3A7PG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj4mbmJzcDsgYmVoYXZpb3Ig
aW4gZGV2aWNlLiAmbmJzcDtFYWNoIHJ1bGUgaXMgdXNlZCB0byBmaW5kIGEgbWF0Y2ggb24gYSBw
YWNrZXQsJm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj4mbmJzcDsgYW5kIGRlZmluZSBhY3Rpb25zIHRoYXQgd2lsbCBiZSBwZXJmb3JtZWQg
b24gdGhlIHBhY2tldC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+Jmx0
O0tFTlQmZ3Q7IGdvb2QuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxicj4NCiZuYnNwO1NlY29uZCwgYW0gSSByZWFkaW5nIGl0IGNvcnJlY3Q/IC0gaXMg
dGhlICZxdW90O0VkaXRvcmlhbCBOb3RlJnF1b3Q7IGluIHRoZTxicj4NCiZuYnNwO0Fic3RyYWN0
IHNlY3Rpb24uICZuYnNwO0kgc3Ryb25nbHkgYWR2aXNlIG1vdmluZyA8bzpwPjwvbzpwPjwvcD4N
CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1v
dmVkIGl0IHRvIEludHJvZHVjdGlvbiBzZWN0aW9uLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj4mbHQ7S0VOVCZndDsgd2FzIGl0IGJlZm9yZSBpbiBhICZsdDtub3RlJmd0
OyBlbGVtZW50PyZuYnNwOyZuYnNwOyBJdCBtYXkgaGF2ZSBqdXN0IGJlZW4gYSByZW5kZXJpbmcg
aXNzdWUgdGhhdCBtYWRlIGl0IGxvb2sgbGlrZSBpdCB3YXMgcGFyIG9mIHRoZSBhYnN0cmFjdC4m
bmJzcDsgSWYgaXQgd2FzIGEgJmx0O25vdGUmZ3Q7IGJlZm9yZSwgdGhlbiB0aGF0IGlzIGFjdHVh
bGx5IGEgY29tbW9uIHVzZSBvZiB0aGUgJmx0O25vdGUmZ3Q7IGVsZW1lbnQuJm5ic3A7IEl0IGRv
ZXNuJ3QgcmVhbGx5DQogbWF0dGVyLCB0aGUgUkZDIEVkaXRvciB3aWxsIHJlbW92ZSB0aGUgc2Vj
dGlvbiBhbnl3YXkuPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu
YnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YnI+DQozLjIgUkZDIEVkaXRvciBOb3RlPGJyPg0KPGJyPg0KJm5ic3A7VGhl
cmUgaXMgbm8gcmVxdWVzdCB0byByZXBsYWNlICZxdW90O0ktRC5pZXRmLW5ldG1vZC15YW5nLXRy
ZWUtZGlhZ3JhbXMmcXVvdDsgd2l0aDxicj4NCiZuYnNwO3RoZSBmaW5hbCBSRkMgYXNzaWdubWVu
dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNs
YXNzPSJNc29Ob3JtYWwiPkFkZGVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8YmxvY2txdW90
ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxkaXY+DQo8
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJm5ic3A7WW91IG1pZ2h0IHdhbnQgdG8g
YWRkIHdoYXQgdGhlIGN1cnJlbnQgZGF0ZSB2YWx1ZSB1c2VkIGluIHRoZSBkcmFmdCBpczxicj4N
CiZuYnNwOyhpLmUuLCAyMDE4LTAyLTAyKS4gJm5ic3A7Jm5ic3A7UFM6IG15IGRyYWZ0IGJ1aWxk
IHRvb2xzLCB3aGljaCBJIHRoaW5rIHlvdSdyZTxicj4NCiZuYnNwO3VzaW5nLCBzaG91bGQgc2V0
IHRoZSB2YWx1ZSBmb3IgeW91IGF1dG9tYXRpY2FsbHkgaWYgeW91IHB1dCBZWVlZLU1NLUREPGJy
Pg0KJm5ic3A7aW50byB0aGUgdGV4dC48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8
L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFkZGVkIHRleHQgdG8gcmVwbGFj
ZSB0aGUgcmV2aXNpb24gZGF0ZSBpbiB0aGUgbW9kZWwgd2l0aCB0aGUgZGF0ZSB0aGUgZHJhZnQg
Z2V0cyBwdWJsaXNoZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQozLjMgSW1wb3J0IHN0YXRlbWVudHMgbWlzc2luZyBy
ZWZlcmVuY2VzPGJyPg0KPGJyPg0KJm5ic3A7QWxsIGltcG9ydCBzdGF0ZW1lbnRzIGluIGFsbCBt
b2R1bGVzIGFyZSBtaXNzaW5nIHJlZmVyZW5jZSBzdGF0ZW1lbnRzPGJyPg0KJm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7LSB3aHkgd2Fzbid0IHRoaXMgY2F1Z2h0IGJ5IHRoZSB0b29scz8hPGJyPg0K
PGJyPg0KJm5ic3A7UGxlYXNlIHNlZSByZmM2MDg3YmlzIFNlY3Rpb24gNC43LiAmbmJzcDs8bzpw
PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPkFkZGluZyByZWZlcmVuY2UgaW1wbGllcyBpbXBvcnQgYnkgcmV2aXNpb24sIHdo
aWNoIHdlIHdhbnQgdG8gYXZvaWQsIHNwZWNpYWxseSBzaW5jZSB3ZSBkbyBub3Qgd2FudCB0byBp
bXBvcnQgYnkgcmV2aXNpb24uIFJpZ2h0PzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PGJyPg0KJmx0O0tFTlQmZ3Q7IEkgd3JvdGUgJnF1b3Q7cmVm
ZXJlbmNlJnF1b3Q7IChub3QgJnF1b3Q7cmV2aXNpb24mcXVvdDspLiZuYnNwOyBBIHJlZmVyZW5j
ZSBzdGF0ZW1lbnQganVzdCBzcGVjaWZpZXMgd2hpY2ggUkZDIHRoZSBpbXBvcnRlZCBtb2R1bGUg
aXMgZGVmaW5lZCBpbi48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48YnI+DQo8YnI+DQozLjQgU2VjdXJpdHkgQ29uc2lkZXJhdGlvbnM8YnI+DQo8
YnI+DQombmJzcDtQbGVhc2UgcmVmb3JtYXQgdGhlIGxhc3QgcGFyYWdyYXBoIHNvIHRoZSAmcXVv
dDthY2VzJnF1b3Q7IHBhdGggaXMgbW9yZSBwcm9ub3VuY2VkLjxicj4NCiZuYnNwO1BlcmhhcHMg
dXNlIGhhbmdUZXh0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90
ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+V2hhdCBpcyBoYW5nVGV4dD8gSSBpdGFsaWNpemVk
IGl0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PGJyPg0KJmx0O0tFTlQmZ3Q7IGh0dHBzOi8veG1sMnJmYy50b29scy5pZXRmLm9yZy94bWwycmZj
RkFRLmh0bWwjcV9oYW5naW5nX2xpc3RzPG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48YnI+DQo8YnI+DQozLjUgSUFOQSBDb25zaWRlcmF0aW9uczxicj4NCjxicj4NCiZu
YnNwO1RoaXMgc2VjdGlvbiBpcyBoYXJkIHRvIHJlYWQuPGJyPg0KPGJyPg0KJm5ic3A7Q29uc2lk
ZXJhdGlvbiBicmVha2luZyB1cCB0aGUgJnF1b3Q7WE1MJnF1b3Q7IGFuZCB0aGUgJnF1b3Q7WUFO
RyBNb2R1bGUgTmFtZXMmcXVvdDsgcmVnaXN0cnk8YnI+DQombmJzcDtyZXF1ZXN0cyBpbnRvIHR3
byBzdWJzZWN0aW9ucy48YnI+DQo8YnI+DQombmJzcDtDb25zaWRlciBtYWtpbmcgdGhlIHJlZ2lz
dHJhdGlvbiBlbnRyeSByZXF1ZXN0cyB0aGVtc2VsdmVzIGFydHdvcmsgc288YnI+DQombmJzcDt0
aGV5J3JlIGxpbmUtc3BhY2VkIGFuZCBpbmRlbnRlZCBhcyBzdWNoLjxicj4NCjxicj4NCiZuYnNw
O1RoZSBmaXJzdCBwYXJhZ3JhcGggb2YgdGhlICZxdW90O1hNTCZxdW90OyByZWdpc3RyeSByZXF1
ZXN0IHNheXMgJnF1b3Q7YSBVUkkmcXVvdDssIGJ1dCBpdCA8YnI+DQombmJzcDtzaG91bGQgYmUg
JnF1b3Q7dHdvIFVSSXMmcXVvdDs8YnI+DQo8YnI+DQombmJzcDtUaGUgZmlyc3QgcGFyYWdyYXBo
IG9mIHRoZSAmcXVvdDtZQU5HIE1vZHVsZSBOYW1lcyZxdW90OyByZWdpc3RyeSByZXF1ZXN0IHNh
eXMgPGJyPg0KJm5ic3A7JnF1b3Q7YSBZQU5HIG1vZHVsZSZxdW90OywgYnV0IGl0IHNob3VsZCBi
ZSAmcXVvdDt0d28gWUFORyBtb2R1bGVz4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5TcGxpdCBpbnRvIHR3byBz
ZWN0aW9ucyBhbmQgdXBwZWQgdGhlIGNvdW50IG9mIFVSSXMgYW5kIFlBTkcgbW9kZWxzIHRvIHRo
cmVlICh3YXMgbWlzc2luZyB0aGUgaWV0Zi1ldGhlcnR5cGVzIG1vZHVsZSkuPG86cD48L286cD48
L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpw
PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8
YnI+DQozLjYgUmVmZXJlbmNlczxicj4NCjxicj4NCiZuYnNwO0kgaGF2ZW4ndCBjaGVja2VkIHll
dCwgYnV0IHBsZWFzZSB2ZXJpZnkgdGhhdCBhbGwgdGhlIHJlZmVyZW5jZXMgYXJlPGJyPg0KJm5i
c3A7cHJvcGVybHkgc29ydGVkIGFzIHRvIGJlaW5nIE5vcm1hdGl2ZSBvciBJbmZvcm1hdGl2ZS48
YnI+DQo8YnI+DQo8YnI+DQozLjcgQXBwZW5kaXggQTxicj4NCjxicj4NCiZuYnNwO0l0IHRvb2sg
bWUgYXdoaWxlIHRvIGZpZ3VyZSBvdXQgd2hhdCBJIHdhcyBsb29raW5nIGF0LiAmbmJzcDtUaGUg
dHJlZS1kaWFncmFtPGJyPg0KJm5ic3A7aXMgcG9vcmx5IGluZGVudGVkIGFuZCB0aGVyZSBpcyBu
byB0ZXh0IHByZWNlZGluZyB0aGUgZXhhbXBsZSBtb2R1bGUuJm5ic3A7PG86cD48L286cD48L3A+
DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5J
IGhhdmUgbW92ZWQgdGhlIGV4YW1wbGUgbW9kdWxlIGFmdGVyIHRoZSBmaXJzdCBwYXJhZ3JhcGgs
IHRoYXQgZGVzY3JpYmVzIHRoZSBtb2R1bGUuIExldCBtZSBrbm93IGlmIHRoYXQgbG9va3Mgb2su
PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+
DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48YnI+DQombmJzcDtJIHJlY29tbWVuZCB5b3UgZm9sZCB0aGUgbGluZXMgb2YgeW91ciB0
cmVlIGRpYWdyYW0gYXQgYSBjZXJ0YWluIGNvbHVtbjxicj4NCiZuYnNwO3doaWxzdCBhZGRpbmcg
YSAnXCcgY2hhcmFjdGVyLiAmbmJzcDtJJ3ZlIHNpbmNlIGFkZGVkIHRoaXMgYWJpbGl0eSB0byBt
eSBkcmFmdDxicj4NCiZuYnNwO2J1aWxkIHRvb2xzLCBsZXQgbWUga25vdyBpZiBpbnRlcmVzdGVk
IGluIGFuIHVwZGF0ZS4gJm5ic3A7WW91IG1pZ2h0IGFsc28gd2FudDxicj4NCiZuYnNwO3RvIGxv
b2sgYXQgZHJhZnQtd3UtbmV0bW9kLXlhbmcteG1sLWRvYy1jb252ZW50aW9ucy48bzpwPjwvbzpw
PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPlNob3J0ZW5lZCB0aGUgcHJlZml4IHNvIHRoZSBhdWdtZW50IHN0YXRlbWVudCBmaXRzIHdp
dGhpbiA3MiBjb2x1bW5zLiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj5CVFcsIEkgdXNlICdweWFuZyAmbmJzcDstZiB0cmVlIOKAlHRy
ZWUtbGluZS1sZW5ndGg9NjknIHRvIGdlbmVyYXRlIHRoZSB0cmVlLiBQbHVzIEkgdXNlIGZvbGQg
LXcgNzEgdG8gZm9sZCB0aGUgZGlhZ3JhbSwgYnV0IEkgZ3Vlc3MgaXQgZG9lcyBub3Qgd29yayBm
b3IgYXVnbWVudCBzdGF0ZW1lbnQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQombmJzcDtBbHNvLCBwbGVhc2UgZml4IHRo
ZSBleGFtcGxlIG1vZHVsZSdzIG5hbWVzcGFjZSBwZXIgdGhlIGVuZCBvZiA8YnI+DQombmJzcDty
ZmM2MDg3YmlzIFNlY3Rpb24gNC45LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw
PjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VXBkYXRlZCB0aGUgbmFtZXNwYWNl
IHRvIOKAnDxhIGhyZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/
dT1odHRwLTNBX19leGFtcGxlLmNvbV9uc19leGFtcGxlLTJEbmV3Y28tMkRhY2wmYW1wO2Q9RHdN
RmFRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmYW1w
O3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZhbXA7bT15V2FO
UDNDT0JUOFRnbVZENVlDTTVNVDNSS2J1cEpSbTZCV0N6UHlpQzRrJmFtcDtzPUxjTFNENEZYdTVX
N3ZxdEU2NkFmRm9rVHE4TjY2YW9zQU91QnVPM0c3M0kmYW1wO2U9Ij5odHRwOi8vZXhhbXBsZS5j
b20vbnMvZXhhbXBsZS1uZXdjby1hY2w8L2E+4oCdPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk
aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K
PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNoZWVycy48bzpwPjwvbzpwPjwvcD4NCjwvZGl2
Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxicj4N
ClRoYW5rcyw8YnI+DQpLZW50PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQpOZXRjb25mIG1haWxp
bmcgbGlzdDxicj4NCjxhIGhyZWY9Im1haWx0bzpOZXRjb25mQGlldGYub3JnIj5OZXRjb25mQGll
dGYub3JnPC9hPjxicj4NCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/
dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0Y29uZiZhbXA7ZD1E
d0lDQWcmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZh
bXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPTdC
eDNoZ29mU0Z4dk5SVjdYejdGdWFKY0tLZnpFQjBzQkp6Tl9LT0N0U2cmYW1wO3M9WGtuTHFnQXUz
Wjl0MU1FNkZPLV9tWlkyb0NONjE4NjdWQjB1YkxlaXYzUSZhbXA7ZT08YnI+DQo8YnI+DQo8YnI+
DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXzxicj4NCm5l
dG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQpuZXRtb2RAaWV0Zi5vcmc8YnI+DQpodHRwczovL3d3dy5p
ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL25ldG1vZDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8
L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4m
bmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haGVz
aCBKZXRoYW5hbmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhh
bmFuZGFuaUBnbWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0K
PC9ib2R5Pg0KPC9odG1sPg0K

--_000_8D3773A8ECA6406AB28D6DD44F951F10junipernet_--


From nobody Fri Feb 23 12:44:33 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D6C124235 for ; Fri, 23 Feb 2018 12:44:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.701
X-Spam-Level: 
X-Spam-Status: No, score=-2.701 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dhrO-DRxHIth for ; Fri, 23 Feb 2018 12:44:29 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0b-00273201.pphosted.com [67.231.152.164]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A41421205F0 for ; Fri, 23 Feb 2018 12:44:29 -0800 (PST)
Received: from pps.filterd (m0108162.ppops.net [127.0.0.1]) by mx0b-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1NK03OZ028520; Fri, 23 Feb 2018 12:00:30 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : subject : date : message-id : references : in-reply-to : content-type : content-id : content-transfer-encoding : mime-version; s=PPS1017; bh=mIGs3D1G/T1bQGvaZpnn0DWcyCppgdO0v5Gx18YnOrs=; b=m/GAqMc7tZ0CHMemYYgtJBnhyrPILfWSm54/WhHhq7IjT9eTrSaJntvYf6b1w0F/jQUi XSHRMX4PVqXVn1EuqsCtWyZ+ui1DmwzkmU3E8BvirtCjXUcR69cRriDfU9g07iaXrX8d 25RMn69gu8eWR25QDD7O2zbLKmEr94vtbiyqGINU5OzUNz/EwINWWgRmX5waBdv7gKc2 TVeXQh4I/QhrsRDmp59OlX6OBDlLLFjk4O45t7RLjxYsjosV4OKXpZGayxj8cMhas8pP WEaPCSJg10moWOlG69fJgn75iOKWCM5DmMr9b+qZcGEifaa6m/Y9Ha6kGQW6aprsoDn4 1g== 
Received: from nam03-by2-obe.outbound.protection.outlook.com (mail-by2nam03lp0056.outbound.protection.outlook.com [216.32.180.56]) by mx0b-00273201.pphosted.com with ESMTP id 2gasktr00u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 23 Feb 2018 12:00:29 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2987.namprd05.prod.outlook.com (10.168.177.7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.527.6; Fri, 23 Feb 2018 19:49:24 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b%3]) with mapi id 15.20.0548.005; Fri, 23 Feb 2018 19:49:24 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder , "netmod@ietf.org" 
Thread-Topic: [netmod] reference statement examples in draft-ietf-netmod-rfc6087bis-18
Thread-Index: AQHTrHpQAqPOMaYjBk2u2kkn68z4LaOyEgeA
Date: Fri, 23 Feb 2018 19:49:23 +0000
Message-ID: <34515A86-1365-46DE-9B49-3E5BEEC44E07@juniper.net>
References: <20180223071204.wio22cwopgajy7hb@elstar.local>
In-Reply-To: <20180223071204.wio22cwopgajy7hb@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB2987; 6:qFZ0F+/EqIJ5k8ZXm5k8kuW8Z8P080HznLPtuGYDvQZGl+eQwgZd7hXnyQwmZBG22sfqucyDYB/+Z7lYz0Ke8R7lzZL4aQYfMhA9wHTQ9zN+2knJdeEIQq7T6U1ThlRBZCTvykTvtC4CTCiSWvyumRdUWrDseOR1NP1P1zO4wJnSkSEcjHeaFhbdRFcX+QZXjsyt4L4FVg1li5rs4MOovuRKhr2pJ50/bAbvvyLBFGUq0BL89c0GVGnHwF/kLl3ITMz1pr5+1gpp5cY/NDR34RmKJJ26Q6FWBInl7s03JLQTsEKqMabZXMR8MTIaxtif6aiQ8Bx+bYnOAJtlXi+pgiM/cDfH2SuS1zABsYg6qYP/KS9ROwm5y32PujDBMbd8; 5:sZmOtiwFdPXFG68WQa6v4A+L5DZMeP/iOqKCR0I1zdUYDmKF1bFNlhjJDD0xSPvivIFlRZWGrW0w59jjD10YyUulBFdASU3u64V1JwPCUGwh5TvJKLdy8VnlQzLbtqA3O8xq4puhPioY+HFdsNSwBeA40e3UUgRCqxXYW/oYMTc=; 24:Y0T61hQAi7SVEQyfogUJkIPte3qu0xYtX5b7/hrtmphQ9Rzy2aTQ3yFTsfAvUSriqT5X2ZMchm1a6EPA9k9Kp+7Y+E7YwoZDYibSy3KzxwI=; 7:vDAuzYkAdc9/PM7yLEivE7kvX973xeeGoQoxPtACRQAR1GrlqQUnDaiTLQBjCD7AMqqjeMSs/7RW47x5/tXi7XacZkRUFge2J+BtL3seAPqajtf25/3NV5n8EgdOMwyNDX8P9UHZVyeYaMxcAoaTr4eSqUDqMtIQVtYjod2SGGdNOSP31x8fT+ScD2p/oWnU/zIsoZdYRIvoZ+xJ3R+xJ8b5RKU5MZp/7rX/E+iucESQiX1QwRUjZJTnmM+ot1V5
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: acec6bda-48c2-478d-9ad6-08d57af68a22
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(4534165)(4627221)(201703031133081)(201702281549075)(5600026)(4604075)(3008032)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB2987; 
x-ms-traffictypediagnostic: DM5PR05MB2987:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(3231101)(944501161)(3002001)(10201501046)(93006095)(93001095)(6055026)(6041288)(20161123558120)(20161123562045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB2987; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2987; 
x-forefront-prvs: 0592A9FDE6
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(396003)(366004)(39380400002)(346002)(376002)(199004)(189003)(25786009)(305945005)(5660300001)(82746002)(106356001)(7736002)(14454004)(83716003)(3280700002)(6246003)(86362001)(97736004)(6506007)(66066001)(2906002)(59450400001)(102836004)(26005)(186003)(53936002)(36756003)(6512007)(6116002)(6436002)(99286004)(58126008)(110136005)(8936002)(68736007)(316002)(8676002)(81156014)(81166006)(33656002)(229853002)(3846002)(5250100002)(2501003)(2950100002)(478600001)(105586002)(2900100001)(3660700001)(76176011)(6486002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2987; H:DM5PR05MB3484.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)
x-microsoft-antispam-message-info: xYdf696RyyavIOoJlNurvspVYUa2qA8mh9jZqe6raAuhC2+HPS9Yj7XiGxBRgmMeATXjI2HB4a+KjoTP5rJ7LFPensGD3QNCdaNmNkuufysPUhugoH2YOFmSqA92b9AsqT3S83NK+Hru6csljkHdSm/PU6UUv6GrJgE3pFK8wJw=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-ID: <5EFE47E8FB400C43ABC6F416F66C4FD4@namprd05.prod.outlook.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: acec6bda-48c2-478d-9ad6-08d57af68a22
X-MS-Exchange-CrossTenant-originalarrivaltime: 23 Feb 2018 19:49:24.0060 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2987
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-23_07:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=789 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802230244
Archived-At: 
Subject: Re: [netmod] reference statement examples in draft-ietf-netmod-rfc6087bis-18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Fri, 23 Feb 2018 20:44:31 -0000

DQpKdWVyZ2VuIHdyaXRlczoNCj4gSSB0aGluayBpdCB3YXMgY29tbW9uIHByYWN0aWNlIHRvIHdy
aXRlDQo+DQo+ICAgcmVmZXJlbmNlICJSRkMgNjk5MTogQ29tbW9uIFlBTkcgRGF0YSBUeXBlcyI7
DQo+DQo+IGluc3RlYWQgb2YganVzdA0KPg0KPiAgIHJlZmVyZW5jZSAiUkZDIDY5OTEiOw0KDQpB
Z3JlZWQsIEkgYWx3YXlzIGRvLg0KDQoNCj4gdGhhdCBpcyB0byBpbmNsdWRlIHRoZSBSRkMgdGl0
bGUgKHRoaXMgY2FuIGJlIGVzcGVjaWFsbHkgdXNlZnVsIHdpdGgNCj4gbG9uZ2VyIGxpc3RzIG9m
IHJlZmVyZW5jZXMgYW5kIGxlc3MgY29tbW9ubHkga25vd24gUkZDIG51bWJlcnMpLiBJdA0KPiBz
ZWVtcyB0aGF0IGRyYWZ0LWlldGYtbmV0bW9kLXJmYzYwODdiaXMtMTgga2luZCBvZiBzdWdnZXN0
cyB0byBvbmx5DQo+IHVzZSB0aGUgUkZDIG51bWJlciAoc2VjdGlvbiAzLjIgYW5kIHNlY3Rpb24g
NC43KS4NCg0KSWYgeW91J3JlIHN1Z2dlc3RpbmcgbW9kaWZ5aW5nIHRoZSBleGFtcGxlcyBpbiBy
ZmM2MDg3YmlzLCBhcyBhIA0KY29udHJpYnV0b3IsIEkgc3VwcG9ydC4NCg0KQXMgc2hlcGhlcmQs
IGl0IHdvdWxkIGJlIGdvb2QgdG8gaGVhciBtb3JlIHN1cHBvcnQgZm9yIHRoaXMgY2hhbmdlDQpi
ZWZvcmUgZm9ybWFsaXppbmcgYSByZXF1ZXN0Lg0KDQoNCktlbnQNCg0KDQoNCg0K


From nobody Sat Feb 24 05:54:56 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A88C1270AE for ; Sat, 24 Feb 2018 05:54:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hU3WZ5IfOuHX for ; Sat, 24 Feb 2018 05:54:53 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id F2045126CBF for ; Sat, 24 Feb 2018 05:54:52 -0800 (PST)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id E142E62989; Sat, 24 Feb 2018 13:54:51 +0000 (UTC)
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com>
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps 
To: Martin Bjorklund 
Cc: rwilton@cisco.com, netmod@ietf.org
In-reply-to: <20180223.103628.1174590223555999274.mbj@tail-f.com>
Date: Sat, 24 Feb 2018 08:54:50 -0500
Message-ID: <87woz2a3x1.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 13:54:55 -0000

My position,

It may be the case that there's even a better cleaner solution; however, it's simply too late for major modifications to this work that don't actually address functional failures.  The draft as proposed works for the people who need to get work done.

We have multiple pending RFCs - MISREF on this document. These RFCs would have to be pulled from the RFC EDITOR queue, and reworked to be compliant again, and this very well could lead to discovering issues with your new proposal. Any new issues discovered in either the pending RFCs *or* in the new solution would then need to be worked out and fixed. Please recall that this actually occurred on the first round (i.e., doing the examples led to discovering problems with the drafts), so it's not unreasonable at all to assume this would happen again.

Look this just isn't a simple change your proposing. It involves a large upheaval, killing the pending RFC status on multiple documents that the industry is waiting on. Please see this.

Thanks,
Chris.


Martin Bjorklund  writes:

> Hi,
>
> Robert Wilton  wrote:
>> Hi Lou,
>>
>> I think that this solution is inferior to the model presented in
>> pre-09.
>
> I agree.  Servers that are NMDA-compliant, or implements YANG Library
> bis will have to present schemas in two different structures,
> depending on where the schema is used, and clients will have to code
> for both.  With the solution in pre-09, there is just one structure.
> A single structure also has other benefits (apart from being simpler),
> e.g., if we augment it with the meta data that has been discussed
> recently, we can augment a single structure.

> /martin
>
>
>
>> I would prefer that we publish pre09 instead, potentially including
>> the -08 model in the appendix if that helps progress the document in a
>> more expedient fashion.
>>
>> Thanks,
>> Rob
>>
>>
>> On 22/02/2018 16:18, Lou Berger wrote:
>> > Hi,
>> >
>> > (I have a bunch of different roles WRT this work. This mail is being
>> > sent as an individual - as chair, I fully support the previous chair
>> > statements on this draft.)
>> >
>> > Chris and I have come up with a proposal on how to provide full NMDA
>> > as part the existing schema-mount module. Our motivation was to
>> > enable full NMDA support with *minimal* change to the model and
>> > disruption to the LC'ed work. The key NMDA limitation, with -08, that
>> > we are aiming to address is the ability to support different mounted
>> > schema in different datastores for non-inline mount points. (See more
>> > detailed description below if interested full nuances of limitations
>> > of -08)
>> >
>> > What we came up with was to simply add a (leaf)list to identify in
>> > which datastores a
>> > schema-mount schema is valid/present. This is somewhat similar to
>> > YL-bis schema/module-set. Specifically we're proposing (see below for
>> > full tree below):
>> >
>> >  +--ro schema* [name]
>> >  +--ro name string
>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>> >
>> > This approach has the advantages of supporting different mounted
>> > schema in different DSes, working with both NMDA and non-NMDA
>> > implementations, supporting all of the extensively discussed features
>> > of schema mount (including recursive mounts), and having minor/scoped
>> > impact on all dependent work. The main downside is that it isn't the
>> > most optimal/compact solution possible if we were to base this work on
>> > YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from all
>> > perspectives, but it is what was agreed to as sufficient by those who
>> > contribute to the WG discussion.
>> >
>> > In short, we see this as a solution to addresses the raised last call
>> > issue with the minimal impact on -08 and dependent work -- which is
>> > what is appropriate given where we are in the process.
>> >
>> > So our/my question really is:
>> >
>> >  Is this a solution that you/all can live with?
>> >
>> > Note: optimization, design preference and perfect alignment with use
>> > or YL-bis are not part of our question as we both don't think that is
>> > the right question given where we are in the WG process.
>> >
>> > Lou (with ideas developed with Chris, and chair hat off)
>> >
>> > ======
>> > Details -- for those who want
>> > ======
>> > As background, my understanding/view is that the -08 version of the
>> > both NMDA and non-NMDA supporting implementations, but there are
>> > limitations in its NMDA applicability. Used with Yang Library,
>> > [rfc7895], only non-NMDA implementations can be supported. When used
>> > with the revised Yang Library defined in
>> > [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
>> > supported with certain limitations. Specifically, this document
>> > requires use of the now deprecated module-list grouping, and the same
>> > schema represented in schema list of the Schema Mount module MUST be
>> > used in all datastores. Inline type mount points, which don't use the
>> > schema list, can support different schema in different data stores
>> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>> > YANG library under the inline mount point.
>> >
>> >  module: ietf-yang-schema-mount
>> >  +--ro schema-mounts
>> >  +--ro namespace* [prefix]
>> >  | +--ro prefix yang:yang-identifier
>> >  | +--ro uri? inet:uri
>> >  +--ro mount-point* [module name]
>> >  | +--ro module yang:yang-identifier
>> >  | +--ro name yang:yang-identifier
>> >  | +--ro config? boolean
>> >  | +--ro (schema-ref)?
>> >  | +--:(inline)
>> >  | | +--ro inline? empty
>> >  | +--:(use-schema)
>> >  | +--ro use-schema* [name]
>> >  | +--ro name
>> >  | | -> /schema-mounts/schema/name
>> >  | +--ro parent-reference* yang:xpath1.0
>> >  +--ro schema* [name]
>> >  +--ro name string
>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>> >   +--ro module* [name revision]
>> >  | +--ro name yang:yang-identifier
>> >  | +--ro revision union
>> >  | +--ro schema? inet:uri
>> >  | +--ro namespace inet:uri
>> >  | +--ro feature* yang:yang-identifier
>> >  | +--ro deviation* [name revision]
>> >  | | +--ro name yang:yang-identifier
>> >  | | +--ro revision union
>> >  | +--ro conformance-type enumeration
>> >  | +--ro submodule* [name revision]
>> >  | +--ro name yang:yang-identifier
>> >  | +--ro revision union
>> >  | +--ro schema? inet:uri
>> >  +--ro mount-point* [module name]
>> >  +--ro module yang:yang-identifier
>> >  +--ro name yang:yang-identifier
>> >  +--ro config? boolean
>> >  +--ro (schema-ref)?
>> >  +--:(inline)
>> >  | +--ro inline? empty
>> >  +--:(use-schema)
>> >  +--ro use-schema* [name]
>> >  +--ro name
>> >  | -> /schema-mounts/schema/name
>> >  +--ro parent-reference* yang:xpath1.0
>> >
>> > We would expect that the revised-datastores feature would be used
>> > (perhaps required) for any implementation that supports
>> > ietf-datastores
>> > and yl-bis.
>> >
>> >
>> >
>> > _______________________________________________
>> > netmod mailing list
>> > netmod@ietf.org
>> > https://www.ietf.org/mailman/listinfo/netmod
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod


From nobody Sat Feb 24 07:13:20 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25BFA12706D for ; Sat, 24 Feb 2018 07:13:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 62cJ2ynwykAG for ; Sat, 24 Feb 2018 07:13:18 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 271B91201FA for ; Sat, 24 Feb 2018 07:13:18 -0800 (PST)
Received: from pluto.hedeland.org (81-228-155-109-no289.tbcn.telia.com [81.228.155.109]) by mail.tail-f.com (Postfix) with ESMTPSA id 6EA2F1AE018B for ; Sat, 24 Feb 2018 16:13:17 +0100 (CET)
To: "netmod@ietf.org" 
From: Per Hedeland 
Message-ID: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com>
Date: Sat, 24 Feb 2018 16:13:17 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: [netmod] derived-from() vs derived-from-or-self() in acl model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 15:13:19 -0000

Hi,

A customer of ours using one of the draft versions of the
ietf-access-control-list module reported that it was not possible to
configure an ethernet ace with type acl:eth-acl-type, due to the
derived-from() in

               container eth {
                 when "derived-from(../../../../type, " +
                      "'acl:eth-acl-type')";
                 if-feature match-on-eth;
                 uses pf:acl-eth-header-fields;
                 description
                   "Rule set that matches ethernet headers.";
               }

evaluating to "false". I pointed out that this is correct behavior of
our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
it would need to be derived-from-or-self() in order to evaluate to
"true". I also ventured a guess (not having followed the development of
the acl model in detail) that the intent was that vendors should define
their own identities, that actually *were* derived from acl:eth-acl-type
(and ditto for all the other *-acl-type identities, of course).

However I'm not at all sure that the guess is correct, and if so why
this should be *enforced* by excluding the base identity. And having a
look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
seems to be doing exactly what our customer tried, alhough with
ipv4-acl-type:


   
     
       sample-ipv4-acl
       ipv4-acl-type
       
         
           rule1
           
             
               
                 tcp

As far as I can see, this snippet is invalid for the model, since the
'ipv4' container has

               container ipv4 {
                 when "derived-from(../../../../type, " +
                      "'acl:ipv4-acl-type')";

- and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
there shouldn't be any  element either, but that's another thing.)

So, is it the case that the derived-from()s should actually be
derived-from-or-self()s, or is the example wrong?

--Per Hedeland


From nobody Sat Feb 24 08:37:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6215E127599 for ; Sat, 24 Feb 2018 08:37:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I38HcTS8Bd3B for ; Sat, 24 Feb 2018 08:37:13 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 01EC0126D05 for ; Sat, 24 Feb 2018 08:37:13 -0800 (PST)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 17B5C62A2F; Sat, 24 Feb 2018 16:37:12 +0000 (UTC)
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net> <20180223.135509.1022283362077802966.mbj@tail-f.com>  <8760c49e-1304-0d55-6e38-004dfaca570c@cisco.com> <161c3185fd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180223192814.xpicpsmsbpcqnwyg@elstar.local>
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps 
To: Juergen Schoenwaelder 
Cc: Lou Berger , netmod@ietf.org
In-reply-to: <20180223192814.xpicpsmsbpcqnwyg@elstar.local>
Date: Sat, 24 Feb 2018 11:37:11 -0500
Message-ID: <87vaem9weg.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 16:37:14 -0000

Juergen Schoenwaelder  writes:
> - For the pre 09 'camp', it seems integration with YLbis is the key
>   technical requirement that is driving them.
>
> What is the key technical critical issue for the other camp?

We have RFCs in the publication queue (i.e., awaiting RFC numbers) to manage VPNs, VMs, etc, that are literally only blocked on this work being published (as written). To change this document in the proposed fashion invalidates the pending RFCs which would then need to be pulled from the publication queue and reworked along with the new proposed changes. The industry is waiting on and needs these RFCs to get work done. I do not think it's reasonable to ask the industry to now wait even longer to go back and rewrite what is already good enough and ready for publication and use.

Thanks,
Chris.

>
> /js


From nobody Sat Feb 24 11:35:05 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9ED7712D77D; Sat, 24 Feb 2018 11:35:03 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Duplicate header field: "Cc"
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yW7p53Ydz17S; Sat, 24 Feb 2018 11:35:02 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2BB1112D77B; Sat, 24 Feb 2018 11:35:02 -0800 (PST)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 616CF62A28; Sat, 24 Feb 2018 19:35:01 +0000 (UTC)
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps 
To: "netconf\@ietf.org" 
Cc: "netmod\@ietf.org" 
Cc: chopps@chopps.org
Date: Sat, 24 Feb 2018 14:35:00 -0500
Message-ID: <87o9ke9o63.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: [netmod] Open source filtering code?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 19:35:04 -0000

I've developed a basic python based netconf server and client (https://github.com/choppsv1/netconf), but it currently lacks any decent filtering capability. I was wondering can anyone point me at any open source (or way to use open source) that implements netconf/yang subtree/xpath filtering?

For this project something simple that takes a result and prunes it down would probably work OK.

FWIW I looked at lxml and xpath thinking that I could translate subtree filters to xpath first and then use xpath; however, lxml xpath is not really designed to support returning results from the root of the tree. Failing to find anything else I'll probably try and make that work anyway.

Thanks,
Chris.


From nobody Sat Feb 24 15:42:01 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6B0312D946; Sat, 24 Feb 2018 15:41:54 -0800 (PST)
X-Quarantine-ID: 
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BANNED, message contains text/plain,.exe
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RTD19QSz8EHQ; Sat, 24 Feb 2018 15:41:53 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 2B472126C22; Sat, 24 Feb 2018 15:41:53 -0800 (PST)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 81C8F62A28; Sat, 24 Feb 2018 23:41:52 +0000 (UTC)
References: <87o9ke9o63.fsf@chopps.org>
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps 
To: "netconf\@ietf.org" 
Cc: "netmod\@ietf.org" 
In-reply-to: <87o9ke9o63.fsf@chopps.org>
Date: Sat, 24 Feb 2018 18:41:50 -0500
Message-ID: <87vaemarb5.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] Open source filtering code?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sat, 24 Feb 2018 23:41:55 -0000

Still interested in any answers to this query; however, I thought I would followup..

A somewhat sub-optimal but working solution using lxml for pruning results turned out to be pretty simple after all. :)

`data` is the data lxlm.Element containing the get[-config] result, and `xpath` is an xpath string.

def xpath_filter_result(data, xpath):

    # First get a copy we can safely modify.
    data = copy.deepcopy(data)
    results = data.xpath(xpath, namespaces=NSMAP)

    # Mark the tree up
    for result in results:
        # Mark all children
        for elm in result.iterdescendants():
            elm.attrib['__filter_marked__'] = ""
        # Mark this element and all parents
        while result is not data:
            result.attrib['__filter_marked__'] = ""
            result = result.getparent()

    def prunedecendants(elm):
        for child in elm.getchildren():
            if '__filter_marked__' not in child.attrib:
                elm.remove(child)
            else:
                # Recurse
                prunedecendants(child)
                # Remove the mark
                del child.attrib['__filter_marked__']

    prunedecendants(data)

    return data

Thanks,
Chris.


Christian Hopps  writes:

> I've developed a basic python based netconf server and client (https://github.com/choppsv1/netconf), but it currently lacks any decent filtering capability. I was wondering can anyone point me at any open source (or way to use open source) that implements netconf/yang subtree/xpath filtering?
>
> For this project something simple that takes a result and prunes it down would probably work OK.
>
> FWIW I looked at lxml and xpath thinking that I could translate subtree filters to xpath first and then use xpath; however, lxml xpath is not really designed to support returning results from the root of the tree. Failing to find anything else I'll probably try and make that work anyway.
>
> Thanks,
> Chris.


From nobody Sun Feb 25 06:02:11 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D5FA1242F5 for ; Sun, 25 Feb 2018 06:02:09 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VVttHHdAhRhY for ; Sun, 25 Feb 2018 06:02:07 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 686F3120227 for ; Sun, 25 Feb 2018 06:02:07 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id 2FC816A2; Sun, 25 Feb 2018 15:02:06 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id mSqeki7yeB1K; Sun, 25 Feb 2018 15:02:03 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Sun, 25 Feb 2018 15:02:06 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 1A35820154; Sun, 25 Feb 2018 15:02:06 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id RjUGvWenTkTE; Sun, 25 Feb 2018 15:02:05 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 5D3D720153; Sun, 25 Feb 2018 15:02:05 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 928FD4256457; Sun, 25 Feb 2018 15:02:03 +0100 (CET)
Date: Sun, 25 Feb 2018 15:02:03 +0100
From: Juergen Schoenwaelder 
To: Christian Hopps 
Cc: Lou Berger , netmod@ietf.org
Message-ID: <20180225140203.5osj7szmyudwwpxp@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Christian Hopps , Lou Berger , netmod@ietf.org
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net> <20180223.135509.1022283362077802966.mbj@tail-f.com>  <8760c49e-1304-0d55-6e38-004dfaca570c@cisco.com> <161c3185fd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180223192814.xpicpsmsbpcqnwyg@elstar.local> <87vaem9weg.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <87vaem9weg.fsf@chopps.org>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 14:02:09 -0000

On Sat, Feb 24, 2018 at 11:37:11AM -0500, Christian Hopps wrote:
> 
> Juergen Schoenwaelder  writes:
> > - For the pre 09 'camp', it seems integration with YLbis is the key
> >   technical requirement that is driving them.
> > 
> > What is the key technical critical issue for the other camp?
> 
> We have RFCs in the publication queue (i.e., awaiting RFC numbers) to manage VPNs, VMs, etc, that are literally only blocked on this work being published (as written). To change this document in the proposed fashion invalidates the pending RFCs which would then need to be pulled from the publication queue and reworked along with the new proposed changes. The industry is waiting on and needs these RFCs to get work done. I do not think it's reasonable to ask the industry to now wait even longer to go back and rewrite what is already good enough and ready for publication and use.
>

If the change to schema mount (i.e., how schema information is
exposed) invalidates the normative parts of documents that define data
models that may exist under a mount point, then I think we got the
coupling between documents wrong.

Anyway, if we can't find a solution that can work for everybody
involved, then we may be left with the only alternative to escalate
this further. My guess is that we will only loose time and we will all
look stupid at the end, hence I was hoping we could avoid this.

/js

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


From nobody Sun Feb 25 06:36:34 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97C61120227 for ; Sun, 25 Feb 2018 06:36:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id nMQlhtVAlRQI for ; Sun, 25 Feb 2018 06:36:31 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id DE940126C89 for ; Sun, 25 Feb 2018 06:36:30 -0800 (PST)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id A3FE262A28; Sun, 25 Feb 2018 14:36:29 +0000 (UTC)
References: <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <61afc424-4131-2871-b752-59c086dd4727@labn.net> <20180223.135509.1022283362077802966.mbj@tail-f.com>  <8760c49e-1304-0d55-6e38-004dfaca570c@cisco.com> <161c3185fd0.27d3.9b4188e636579690ba6c69f2c8a0f1fd@labn.net> <20180223192814.xpicpsmsbpcqnwyg@elstar.local> <87vaem9weg.fsf@chopps.org> <20180225140203.5osj7szmyudwwpxp@elstar.local>
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps 
To: Juergen Schoenwaelder 
Cc: Christian Hopps , Lou Berger , netmod@ietf.org
In-reply-to: <20180225140203.5osj7szmyudwwpxp@elstar.local>
Date: Sun, 25 Feb 2018 09:36:28 -0500
Message-ID: <87r2p9xhjn.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 14:36:33 -0000

Juergen Schoenwaelder  writes:

> On Sat, Feb 24, 2018 at 11:37:11AM -0500, Christian Hopps wrote:
>>
>> Juergen Schoenwaelder  writes:
>> > - For the pre 09 'camp', it seems integration with YLbis is the key
>> >   technical requirement that is driving them.
>> >
>> > What is the key technical critical issue for the other camp?
>>
>> We have RFCs in the publication queue (i.e., awaiting RFC numbers) to manage VPNs, VMs, etc, that are literally only blocked on this work being published (as written). To change this document in the proposed fashion invalidates the pending RFCs which would then need to be pulled from the publication queue and reworked along with the new proposed changes. The industry is waiting on and needs these RFCs to get work done. I do not think it's reasonable to ask the industry to now wait even longer to go back and rewrite what is already good enough and ready for publication and use.
>>
>
> If the change to schema mount (i.e., how schema information is
> exposed) invalidates the normative parts of documents that define data
> models that may exist under a mount point, then I think we got the
> coupling between documents wrong.

It invalidates the examples for sure. But normative vs informative isn't the point. Doing the examples last time exposed issues with the design. There's no reason to think that won't occur here. The point is that people are justifying the proposed change by saying it's quick and non-disruptive, and that's simply *not* the case.

We have finished this work, and important stuff that the industry requires is waiting (one wonders how much longer though)

It's time to publish the good work we've done.

> Anyway, if we can't find a solution that can work for everybody
> involved, then we may be left with the only alternative to escalate
> this further. My guess is that we will only loose time and we will all
> look stupid at the end, hence I was hoping we could avoid this.

If by escalation you mean protests to hold up the work the industry needs during the IESG/IETF LC versus just doing the new work separately?

 Yeah, that'll make us look *really* competent to the industry too. 

One hopes that we don't end up with that nonsense.

Thanks,
Chris.

>
> /js


From nobody Sun Feb 25 10:38:18 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 409C31270AE for ; Sun, 25 Feb 2018 10:38:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NJRKINPEVDJ6 for ; Sun, 25 Feb 2018 10:38:14 -0800 (PST)
Received: from aer-iport-2.cisco.com (aer-iport-2.cisco.com [173.38.203.52]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C26D124D6C for ; Sun, 25 Feb 2018 10:38:14 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=10206; q=dns/txt; s=iport; t=1519583894; x=1520793494; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=3j8w91XVVTLiPJir5/GyDKESxuYA+7e/UP9ms20SNu8=; b=DXYCsKGuHWopg1cs32bVuLIDin/GU+HeXuH9904n8NFJV3ieQ3iOwMEC q8oWDMKXasXBDT6WbuKE0qi1BRwGh8+kH5i65GJZBQN1VKm6JMROiC5r0 jsgI+aCqXXaVVWGLwkv8cBeu0ghxU2HGR0GUxoTr0yTQE4migwyQVW0kP o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAAA8AZNa/xbLJq1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGENXAog1SKInSOVzJ7G5YFFIICChgLhEFPAoMMGAECAQEBAQE?= =?us-ascii?q?BAmsohSQBAQQBASEECwEFNgIJEAsOCgICERUCAicwBg0GAgEBF4R1EKsggW06h?= =?us-ascii?q?HSDboIUAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWBD4gKgWYpgXZYNoMuAQGBLBo?= =?us-ascii?q?LAQEeP4JOgmUFkS6QMwmUIIIGhWaDP4c1iWeEaoQrK4JOgS8eOIFRMxoIGxU6g?= =?us-ascii?q?kOEWkA3ijeCOQEBAQ?=
X-IronPort-AV: E=Sophos;i="5.47,393,1515456000";  d="scan'208";a="2282655"
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; 25 Feb 2018 18:38:11 +0000
Received: from [10.61.197.158] ([10.61.197.158]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1PIcBNP022348; Sun, 25 Feb 2018 18:38:11 GMT
To: Christian Hopps 
Cc: Martin Bjorklund , netmod@ietf.org
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <87woz2a3x1.fsf@chopps.org>
From: Robert Wilton 
Message-ID: <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com>
Date: Sun, 25 Feb 2018 18:38:11 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <87woz2a3x1.fsf@chopps.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Sun, 25 Feb 2018 18:38:17 -0000

Hi Chris,

I've got no desire or intent to try and slow down the NI and LNE drafts, 
or any that depend on them.  I actually agree that this is critically 
important that IETF gets modules standardized/finished so that everyone 
can use them.

However, ...

YLbis has quite a different structure to YL.  The main part of this 
change was to support NMDA, the other part of this change was to better 
support things like SM, or YANG packages.

I don't think that there is a clean, backwards compatible, way to go 
from the YANG module in SM -08 to one that is going to work well with 
YLbis and other YLbis extensions/augmentations that seem to be coming 
down the line.  Given what we know now, I believe that the correct 
medium/long term structure for the SM YANG module, taking YLbis into 
account, is the one proposed in pre09, because it directly augments the 
YLbis structure, and hence any future augmentations to YLbis should 
automatically extend to SM mounted schema as well.

I think that the likely future technical issues with the -08 module will be:
- supporting NMDA in a clean consistent way
- adding in support for SemVer
- additional capability reporting as an augmentation to YANG library

So, if -08 proceeds as is, then it seems to me like one of three things 
will need to happen:
1) Their will need to be a non backwards compatible update to the SM 
model that is the same/similar to pre09.
2) YLbis and SM diverge, stuff that augments YLbis doesn't work for 
explicitly mounted schema.
3) We accrue technical debt, implementations need to support two YL 
module structures, the one in SM and the one in YLbis, and future 
extensions need to augment both the SM structure and YLbis structure.

I don't like the idea of (2) or (3), but I don't know if others will 
find (1) acceptable.

But I do agree that we are just going round in circles on this:
- Using the pre09 structure is not acceptable to some folks
- Publishing a draft with both -08 and pre09 structure is liked by even 
less folks.

Perhaps publishing -08 is the only option.  My hope is that the WG will 
support somebody subsequently doing solution (1), otherwise it seems 
like a missed opportunity to get this right.

Thanks,
Rob


On 24/02/2018 13:54, Christian Hopps wrote:
> My position,
>
> It may be the case that there's even a better cleaner solution; 
> however, it's simply too late for major modifications to this work 
> that don't actually address functional failures.  The draft as 
> proposed works for the people who need to get work done.
>
> We have multiple pending RFCs - MISREF on this document. These RFCs 
> would have to be pulled from the RFC EDITOR queue, and reworked to be 
> compliant again, and this very well could lead to discovering issues 
> with your new proposal. Any new issues discovered in either the 
> pending RFCs *or* in the new solution would then need to be worked out 
> and fixed. Please recall that this actually occurred on the first 
> round (i.e., doing the examples led to discovering problems with the 
> drafts), so it's not unreasonable at all to assume this would happen 
> again.
>
> Look this just isn't a simple change your proposing. It involves a 
> large upheaval, killing the pending RFC status on multiple documents 
> that the industry is waiting on. Please see this.
>
> Thanks,
> Chris.
>
>
> Martin Bjorklund  writes:
>
>> Hi,
>>
>> Robert Wilton  wrote:
>>> Hi Lou,
>>>
>>> I think that this solution is inferior to the model presented in
>>> pre-09.
>>
>> I agree.  Servers that are NMDA-compliant, or implements YANG Library
>> bis will have to present schemas in two different structures,
>> depending on where the schema is used, and clients will have to code
>> for both.  With the solution in pre-09, there is just one structure.
>> A single structure also has other benefits (apart from being simpler),
>> e.g., if we augment it with the meta data that has been discussed
>> recently, we can augment a single structure.
>
>> /martin
>>
>>
>>
>>> I would prefer that we publish pre09 instead, potentially including
>>> the -08 model in the appendix if that helps progress the document in a
>>> more expedient fashion.
>>>
>>> Thanks,
>>> Rob
>>>
>>>
>>> On 22/02/2018 16:18, Lou Berger wrote:
>>> > Hi,
>>> >
>>> > (I have a bunch of different roles WRT this work. This mail is being
>>> > sent as an individual - as chair, I fully support the previous chair
>>> > statements on this draft.)
>>> >
>>> > Chris and I have come up with a proposal on how to provide full NMDA
>>> > as part the existing schema-mount module. Our motivation was to
>>> > enable full NMDA support with *minimal* change to the model and
>>> > disruption to the LC'ed work. The key NMDA limitation, with -08, that
>>> > we are aiming to address is the ability to support different mounted
>>> > schema in different datastores for non-inline mount points. (See more
>>> > detailed description below if interested full nuances of limitations
>>> > of -08)
>>> >
>>> > What we came up with was to simply add a (leaf)list to identify in
>>> > which datastores a
>>> > schema-mount schema is valid/present. This is somewhat similar to
>>> > YL-bis schema/module-set. Specifically we're proposing (see below for
>>> > full tree below):
>>> >
>>> >  +--ro schema* [name]
>>> >  +--ro name string
>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>> >
>>> > This approach has the advantages of supporting different mounted
>>> > schema in different DSes, working with both NMDA and non-NMDA
>>> > implementations, supporting all of the extensively discussed features
>>> > of schema mount (including recursive mounts), and having minor/scoped
>>> > impact on all dependent work. The main downside is that it isn't the
>>> > most optimal/compact solution possible if we were to base this 
>>> work on
>>> > YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from all
>>> > perspectives, but it is what was agreed to as sufficient by those who
>>> > contribute to the WG discussion.
>>> >
>>> > In short, we see this as a solution to addresses the raised last call
>>> > issue with the minimal impact on -08 and dependent work -- which is
>>> > what is appropriate given where we are in the process.
>>> >
>>> > So our/my question really is:
>>> >
>>> >  Is this a solution that you/all can live with?
>>> >
>>> > Note: optimization, design preference and perfect alignment with use
>>> > or YL-bis are not part of our question as we both don't think that is
>>> > the right question given where we are in the WG process.
>>> >
>>> > Lou (with ideas developed with Chris, and chair hat off)
>>> >
>>> > ======
>>> > Details -- for those who want
>>> > ======
>>> > As background, my understanding/view is that the -08 version of the
>>> > both NMDA and non-NMDA supporting implementations, but there are
>>> > limitations in its NMDA applicability. Used with Yang Library,
>>> > [rfc7895], only non-NMDA implementations can be supported. When used
>>> > with the revised Yang Library defined in
>>> > [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
>>> > supported with certain limitations. Specifically, this document
>>> > requires use of the now deprecated module-list grouping, and the same
>>> > schema represented in schema list of the Schema Mount module MUST be
>>> > used in all datastores. Inline type mount points, which don't use the
>>> > schema list, can support different schema in different data stores
>>> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>> > YANG library under the inline mount point.
>>> >
>>> >  module: ietf-yang-schema-mount
>>> >  +--ro schema-mounts
>>> >  +--ro namespace* [prefix]
>>> >  | +--ro prefix yang:yang-identifier
>>> >  | +--ro uri? inet:uri
>>> >  +--ro mount-point* [module name]
>>> >  | +--ro module yang:yang-identifier
>>> >  | +--ro name yang:yang-identifier
>>> >  | +--ro config? boolean
>>> >  | +--ro (schema-ref)?
>>> >  | +--:(inline)
>>> >  | | +--ro inline? empty
>>> >  | +--:(use-schema)
>>> >  | +--ro use-schema* [name]
>>> >  | +--ro name
>>> >  | | -> /schema-mounts/schema/name
>>> >  | +--ro parent-reference* yang:xpath1.0
>>> >  +--ro schema* [name]
>>> >  +--ro name string
>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>> >   +--ro module* [name revision]
>>> >  | +--ro name yang:yang-identifier
>>> >  | +--ro revision union
>>> >  | +--ro schema? inet:uri
>>> >  | +--ro namespace inet:uri
>>> >  | +--ro feature* yang:yang-identifier
>>> >  | +--ro deviation* [name revision]
>>> >  | | +--ro name yang:yang-identifier
>>> >  | | +--ro revision union
>>> >  | +--ro conformance-type enumeration
>>> >  | +--ro submodule* [name revision]
>>> >  | +--ro name yang:yang-identifier
>>> >  | +--ro revision union
>>> >  | +--ro schema? inet:uri
>>> >  +--ro mount-point* [module name]
>>> >  +--ro module yang:yang-identifier
>>> >  +--ro name yang:yang-identifier
>>> >  +--ro config? boolean
>>> >  +--ro (schema-ref)?
>>> >  +--:(inline)
>>> >  | +--ro inline? empty
>>> >  +--:(use-schema)
>>> >  +--ro use-schema* [name]
>>> >  +--ro name
>>> >  | -> /schema-mounts/schema/name
>>> >  +--ro parent-reference* yang:xpath1.0
>>> >
>>> > We would expect that the revised-datastores feature would be used
>>> > (perhaps required) for any implementation that supports
>>> > ietf-datastores
>>> > and yl-bis.
>>> >
>>> >
>>> >
>>> > _______________________________________________
>>> > netmod mailing list
>>> > netmod@ietf.org
>>> > https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
>
> .
>


From nobody Sun Feb 25 18:46:36 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B9111243F3; Sun, 25 Feb 2018 18:46:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level: 
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_NEUTRAL=0.779] 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 tlk94RTrTrhV; Sun, 25 Feb 2018 18:46:33 -0800 (PST)
Received: from newdragon.webhostserver.biz (newdragon.webhostserver.biz [69.25.136.252]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2BB3A120713; Sun, 25 Feb 2018 18:46:33 -0800 (PST)
Received: from [::1] (port=55931) by newdragon.webhostserver.biz with esmtpsa (TLSv1:DHE-RSA-AES128-SHA:128) (Exim 4.86_1) (envelope-from ) id 1eq8oB-0005la-Me; Mon, 26 Feb 2018 05:46:31 +0300
From: Lou Berger 
To: NetMod WG Chairs , NetMod WG 
Message-ID: 
Date: Sun, 25 Feb 2018 21:46:30 -0500
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
X-AntiAbuse: This header was added to track abuse, please include it with any abuse report
X-AntiAbuse: Primary Hostname - newdragon.webhostserver.biz
X-AntiAbuse: Original Domain - ietf.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - labn.net
X-Get-Message-Sender-Via: newdragon.webhostserver.biz: authenticated_id: lberger@blabn.com
X-Authenticated-Sender: newdragon.webhostserver.biz: lberger@blabn.com
X-Source: 
X-Source-Args: 
X-Source-Dir: 
Archived-At: 
Subject: [netmod] IETF 101 Slot Requests
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 02:46:34 -0000

Hi,

The IETF agenda has been posted:

https://datatracker.ietf.org/meeting/101/agenda.html

We're scheduled to meet:

TUESDAY, March 20, 2018
    1550-1820  Afternoon Session II
WEDNESDAY, March 21, 2018
    1330-1500  Afternoon Session I

Please send any slot requests to the chairs alias (see above) no later 
than March 5th.  Please include draft names(s), presenter and desired 
slot length.  Keep in mind priority is given to WG drafts and other 
drafts/topics discussed on the mailing list.

If you are an author/editor of a WG document that has not reached WG LC 
and are not requesting a slot, please send status of the work (e.g., 
plan to get to LC) to the WG list no later than March 16th.

Also don't forget the draft cutoff date, see 
https://datatracker.ietf.org/meeting/important-dates/

Cheers


From nobody Sun Feb 25 21:50:17 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C6AB2129C6B; Sun, 25 Feb 2018 21:50:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id y5FvgpGbtKn6; Sun, 25 Feb 2018 21:50:10 -0800 (PST)
Received: from mail-pg0-x22d.google.com (mail-pg0-x22d.google.com [IPv6:2607:f8b0:400e:c05::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A00DA129C5D; Sun, 25 Feb 2018 21:50:10 -0800 (PST)
Received: by mail-pg0-x22d.google.com with SMTP id e9so1477415pgs.10; Sun, 25 Feb 2018 21:50:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=09rHVbfQauRnXgQPxakPDGu242E2yWScMXP1Vb0cBcs=; b=kW5Mrm8jmTvMCaqstSEwaN4ztC/VDH6Y+rm2bgplbZ0Z/7VJ+tZEdld/8GuKZTiiUs Wdvfg1+EgzUwfaqCY6oYd4zy1afwTGRmV/Y5sFA1ujPGLitP7uumIXkhICWUBAZO2MX7 BovL75GOcH71JF07A62dkUptmbTFP62C2fpG+/UtYmk4MRGPNKP6OQvDTOKyYVzPXK/T ODEnHa685smqWqe3FaOkJ5xiA8M9nc6LZhy/v0NAPPWpsNAhDHtKT//4fl1Uf5G/ulz0 Y7wC4iKgQdQI/iAQRhxFMmu7PH0jrqn9wOAXOkkuWfjo7RDFC/zhrR0jTJd+8tfSYyRS /j7A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=09rHVbfQauRnXgQPxakPDGu242E2yWScMXP1Vb0cBcs=; b=gdIxbiMsWIYnunkybm50pysf6rZ0dOT5hUrmK+VtF190wMjXy44vGRIB0xXiW8N3tR X51uhpV/p1/3WMwDwGMlxFSxdioCuAB59A51qhzjWiTghZ61v3b7LlzNE3t7FBUWC8QB 9Sjhh98wygSZM6mFLD5KsVPndRvOM8do2YvtZAIjjJ+MQDthBKwXuekeO4v181LiJAjy EFYDqeKFm9q1FmYi78pMQvCUhA5dXGUOIXT2s7W57ofDGqdA80aOZ2fFTzOtymEohagV 0GwuSrNQgMg9VoZXCfi2gEhrwj6+u1tQ4EAYGqM84k+06B9hZNhGlwTDv7HaPNYOP0JX UjCQ==
X-Gm-Message-State: APf1xPDuz41eQkn8uB5sREJ7TDSFZEAd7RmMiidUl3koJtY6XybY7EaP 6sU6IjzFXyXF07RBL5iMSRI=
X-Google-Smtp-Source: AH8x225cyJLdX66/1e8P9VfixoHBNSv27UEx10VG1hmpHTPEBjwTCg1R+V0YjL8e99HdOVU0y0XizQ==
X-Received: by 10.101.69.205 with SMTP id m13mr7648069pgr.323.1519624209783; Sun, 25 Feb 2018 21:50:09 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:f95b:566c:c56e:e915? ([2601:647:4700:1280:f95b:566c:c56e:e915]) by smtp.gmail.com with ESMTPSA id e25sm8299406pfn.67.2018.02.25.21.50.06 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 25 Feb 2018 21:50:07 -0800 (PST)
From: Mahesh Jethanandani 
Message-Id: <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_CB681D64-5312-4FDE-87EB-66BEB7303717"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Sun, 25 Feb 2018 21:55:53 -0800
In-Reply-To: <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net>
Cc: "draft-ietf-netmod-acl-model@ietf.org" ,  "netmod@ietf.org" 
To: Kent Watsen 
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net> <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com> <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 05:50:14 -0000

--Apple-Mail=_CB681D64-5312-4FDE-87EB-66BEB7303717
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8



> On Feb 23, 2018, at 12:12 PM, Kent Watsen  wrote:
>=20
> Hi Mahesh,
> =20
> Please search for  below (6 instances)
> =20
> Thanks,
> Kent // shepherd
> =20
> =20
> On 2/17/18, 8:26 PM, "Mahesh Jethanandani" > wrote:
> =20
> Kent,=20
> =20
> Thanks for a detailed review. See inline.
>=20
>=20
>> On Feb 13, 2018, at 2:30 PM, Kent Watsen > wrote:
>> =20
>> [sorry, wrong WG, moving netconf to BCC!]
>>=20
>>=20
>> ACL Authors,
>>=20
>> Below are some issues I found while looking at doing the Shepherd
>> write-up today.  Please take a look.
>>=20
>> Also, with regards to the request for those having Last Call comments
>> to please verify that their comments were addressed, I only saw one
>> response from Kristian, but should we be expecting respeonses from
>> others too, perhaps Einar or Elliot?
> =20
> Eliot can confirm if he feels his issues have been addressed.
>=20
>=20
>>=20
>>=20
>> 1 IDNITS
>>=20
>>  - some issues found by idnits
>>  - using =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_tools_=
idnits_&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zk=
P0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7Bx3hgofSFxvNRV7Xz7FuaJcKKfzE=
B0sBJzN_KOCtSg&s=3D_5f-lxCoJW2TidcrjW_KbDkdPhfxLoL67kn1A2okgs0&e=3D =

>>  - without selecting "verbose output"
>>=20
>>=20
>> 1.1
>>=20
>>  ** There are 5 instances of too long lines in the document, the =
longest one
>>     being 5 characters in excess of 72.
> =20
> Fixed.
>=20
>=20
>>=20
>>=20
>>  This "**" is being flagged as an "error". =20
>>  Idnits label, not mine.  Please fix.
>>=20
>>=20
>> 1.2
>>=20
>>  =3D=3D There are 7 instances of lines with non-RFC6890-compliant =
IPv4 addresses
>>     in the document.  If these are example addresses, they should be =
changed.
>>=20
>>  This is just a warning, but given that there are seven occurrences, =
it
>>  might be a good idea to fix.  Please see Section 3, point #6 in this
>>  document for details: =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_id-2Di=
nfo_checklist&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=
=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7Bx3hgofSFxvNRV7Xz7FuaJ=
cKKfzEB0sBJzN_KOCtSg&s=3DAYo8ZHPY4SAHMqcy1qV9yr7BjoxGy_C9zcJ_ZbwXBT4&e=3D =
.
> =20
> Fixed.
>=20
>=20
>>=20
>>=20
>> 1.3
>>=20
>>  ** The document seems to lack a both a reference to RFC 2119 and the
>>     recommended RFC 2119 boilerplate, even if it appears to use RFC =
2119
>>     keywords.=20
>>=20
>>     RFC 2119 keyword, line 797: '...s-list. A device MAY restrict the =
leng...'
>>=20
>>=20
>>  There needs to be a section that looks like RFC 8174, paragraph 11:
>>=20
>>     The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL =
NOT",
>>     "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY",
>>     and "OPTIONAL" in this document are to be interpreted as
>>     described in BCP 14 [RFC2119] [RFC8174] when, and only when, they
>>     appear in all capitals, as shown here.
> =20
> Added.
>=20
>=20
>>=20
>>=20
>> 1.4.
>>=20
>>  -- The document date (February 2, 2018) is 11 days in the past.  Is =
this
>>     intentional?
>>=20
>>  This is fine, ignore it.
>>=20
>> 1.5
>>=20
>>  ** Obsolete normative reference: RFC 2460
>>=20
>>  This needs to be fixed.
> =20
> Updated the reference to RFC 8200.
>=20
>=20
>>=20
>> 1.6
>>=20
>>  ** Downref: Normative reference to an Historic RFC: RFC 3540
>>=20
>>  Hmmmm, another HISTORIC document, but this time not due to an IESG
>>  action.  The question is how important this reference is, is this
>>  "ns" bit (ECN-nonce concealment protection) commonly used in the=20
>>  industry?  =20
> =20
> I do not know enough to know it is not used. If the consensus is that =
we do not use it, I can drop it from the model.
>=20
>  As shepherd, I would like the normative reference to a historic =
RFC removed from this draft.   My recommendation is to remove it.  As =
chair, if anyone wants to make a case for keeping the "ns" bit, *now* is
> your time to say something.

Unless I hear otherwise, I will remove it.

>> =20
>>=20
>> 1.7
>>=20
>>  =3D=3D Outdated reference: A later version (-06) exists of
>>     draft-ietf-netmod-yang-tree-diagrams-04
>>=20
>>  Please update to -06
> =20
> This might be because the draft was last published when -04 was =
around. I do not reference any particular version. My reference is to=20
> =
. The tool pulls in the latest when it generates the draft.
> =20
>>=20
>> 1.8
>>=20
>>  -- Obsolete informational reference (is this intentional?): RFC 5101
>>     (Obsoleted by RFC 7011)
>>=20
>>  Please update to RFC 7011
> =20
> Done.
>=20
>=20
>>=20
>>=20
>>=20
>> 2  YANG VALIDATION
>>=20
>> 2.1 Normative Modules
>>=20
>>  All of the following passed:
>>=20
>>    pyang --ietf ietf-access-control-list\@2018-02-02.yang=20
>>    pyang --ietf ietf-packet-fields\@2018-02-02.yang=20
>>    pyang --ietf ietf-ethertypes\@2018-02-02.yang
>>=20
>>    yanglint -s ietf-access-control-list\@2018-02-02.yang=20
>>    yanglint -s ietf-packet-fields\@2018-02-02.yang=20
>>    yanglint -s ietf-ethertypes\@2018-02-02.yang=20
>>=20
>> 2.2 Example Module
>>=20
>>  Example module passed `yanglint -s`, but not `pyang --lint`:
>>=20
>>    yanglint -s example-newco-acl.yang
>>    pyang --lint example-newco-acl.yang=20
>>=20
>>    example-newco-acl.yang:78: error: keyword "description" not in
>>    canonical order, expected "type", (See RFC 6020, Section 12)
>>=20
>>    example-newco-acl.yang:79: error: keyword "type" not in=20
>>    canonical order, (See RFC 6020, Section 12)
>>=20
>>    example-newco-acl.yang:82: error: keyword "default" not in=20
>>    canonical order, (See RFC 6020, Section 12)
>>=20
>>  Please fix.
> =20
> Fixed.
>=20
>=20
>>=20
>>=20
>> 2.3 XML Examples from Section 4.3
>>=20
>>  yanglint didn't find any issues:
>>=20
>>    yanglint ietf-access-control-list\@2018-02-02.yang ex-4.3.xml=20
>>=20
>>=20
>> 2.4 Examples from Section 4.4
>>=20
>>  I had to stitch these into the 4.3 example.  It found one issue, a =
typo
>>  in the last closing tag in the first example in this section:
>>=20
>>    yanglint ietf-access-control-list\@2018-02-02.yang ex-4.4++.xml=20
>>    err : Invalid (mixed names) opening =
(source-port-range-or-operator) and closing (tcp) element tags. =
(/data/access-lists/acl/aces/ace/matches/l4/tcp/source-port-range-or-opera=
tor/source-port-range-or-operator)
>>=20
>>  Please fix.
> =20
> Made them complete examples so you do not have to stitch them anymore. =
And made sure yanglint validated the examples before it includes it in =
the draft.
>=20
>=20
>>=20
>>=20
>>  PS: And this is not a shepherd directive, but I found the whole=20
>>      "source-port-range-or-operator" syntax clumsy.  I'm surprised
>>      it didn't look something like:
>>=20
>>          OLD
>>                
>>                   
>>                     
>>                       16384
>>                       65535
>>                     
>>                   
>>                
>>=20
>>                
>>                  
>>                    
>>                      eq
>>                      21
>>                    
>>                  
>>                
>>=20
>>          NEW
>>=20
>>                
>>                  
>>                    16384
>>                    65535
>>                  
>>                
>>=20
>>                
>>                  
>>                    eq
>>                    21
>>                  
>>                
>>=20
> =20
> Did you try making the change in the model to see if it work? It will =
complain that  is already used within the container and that it =
cannot be repeated (for destination-port).
>=20
>  No, I did not, nor do I intend to get that deep into it.  But I =
recall that Kristian made the same comment before, and was making pull =
requests before, so maybe he can suggest something?

Kristian=E2=80=99s suggestion requires changing the module. It is not an =
editorial change. And that change will have an impact on the MUD draft, =
which has been sent for publication.=20

>>=20
>>=20
>> 3 Key Draft Sections
>>=20
>>=20
>> 3.1 Abstract
>>=20
>>  First, I'm unsure if that first "sentence" is properly worded, but I
>>  definitely think that it is a bit too much on the terse side.  Can =
you
>>  embellish it a little?
> =20
> How about this:
> =20
> OLD:
>   This document describes a data model of Access Control List (ACL)
>   basic building blocks.
> NEW:
> =20
>   This document describes a data model for Access Control List (ACL). =20=

>   ACL is a ordered-by-user set of rules, used to configure the =
forwarding=20
>   behavior in device.  Each rule is used to find a match on a packet,=20=

>   and define actions that will be performed on the packet.
> =20
>  good.
>> =20
>>=20
>>  Second, am I reading it correct? - is the "Editorial Note" in the
>>  Abstract section.  I strongly advise moving=20
> =20
> Moved it to Introduction section.
> =20
>  was it before in a  element?   It may have just been a =
rendering issue that made it look like it was par of the abstract.  If =
it was a  before, then that is actually a common use of the  =
element.  It doesn't really matter, the RFC Editor will remove the =
section anyway.
> =20
>>=20
>> 3.2 RFC Editor Note
>>=20
>>  There is no request to replace "I-D.ietf-netmod-yang-tree-diagrams" =
with
>>  the final RFC assignment.
> =20
> Added.
>=20
>=20
>>=20
>>  You might want to add what the current date value used in the draft =
is
>>  (i.e., 2018-02-02).   PS: my draft build tools, which I think you're
>>  using, should set the value for you automatically if you put =
YYYY-MM-DD
>>  into the text.
> =20
> Added text to replace the revision date in the model with the date the =
draft gets published.
>=20
>=20
>>=20
>> 3.3 Import statements missing references
>>=20
>>  All import statements in all modules are missing reference =
statements
>>     - why wasn't this caught by the tools?!
>>=20
>>  Please see rfc6087bis Section 4.7. =20
> =20
> Adding reference implies import by revision, which we want to avoid, =
specially since we do not want to import by revision. Right?
>=20
>  I wrote "reference" (not "revision").  A reference statement =
just specifies which RFC the imported module is defined in.

But by saying:

reference =E2=80=9CRFC 7223=E2=80=9D

you are also implying import by revision, which is not what the module =
wants to do. The module wants to import the latest revision of =
ietf-interfaces, not necessarily the module in RFC 7223.=20

I would suggest that we let the yang-doctors discussion on this topic =
decide how we are going to reference import statements.

>>=20
>>=20
>> 3.4 Security Considerations
>>=20
>>  Please reformat the last paragraph so the "aces" path is more =
pronounced.
>>  Perhaps use hangText.
> =20
> What is hangText? I italicized it.
>=20
>  https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#q_hanging_lists =

Done.

Cheers.

> =20
>>=20
>>=20
>> 3.5 IANA Considerations
>>=20
>>  This section is hard to read.
>>=20
>>  Consideration breaking up the "XML" and the "YANG Module Names" =
registry
>>  requests into two subsections.
>>=20
>>  Consider making the registration entry requests themselves artwork =
so
>>  they're line-spaced and indented as such.
>>=20
>>  The first paragraph of the "XML" registry request says "a URI", but =
it=20
>>  should be "two URIs"
>>=20
>>  The first paragraph of the "YANG Module Names" registry request says=20=

>>  "a YANG module", but it should be "two YANG modules=E2=80=9D
> =20
> Split into two sections and upped the count of URIs and YANG models to =
three (was missing the ietf-ethertypes module).
>=20
>=20
>>=20
>>=20
>> 3.6 References
>>=20
>>  I haven't checked yet, but please verify that all the references are
>>  properly sorted as to being Normative or Informative.
>>=20
>>=20
>> 3.7 Appendix A
>>=20
>>  It took me awhile to figure out what I was looking at.  The =
tree-diagram
>>  is poorly indented and there is no text preceding the example =
module.=20
> =20
> I have moved the example module after the first paragraph, that =
describes the module. Let me know if that looks ok.
>=20
>=20
>>=20
>>  I recommend you fold the lines of your tree diagram at a certain =
column
>>  whilst adding a '\' character.  I've since added this ability to my =
draft
>>  build tools, let me know if interested in an update.  You might also =
want
>>  to look at draft-wu-netmod-yang-xml-doc-conventions.
> =20
> Shortened the prefix so the augment statement fits within 72 columns.=20=

> =20
> BTW, I use 'pyang  -f tree =E2=80=94tree-line-length=3D69' to generate =
the tree. Plus I use fold -w 71 to fold the diagram, but I guess it does =
not work for augment statement.
>=20
>=20
>>=20
>>  Also, please fix the example module's namespace per the end of=20
>>  rfc6087bis Section 4.9.
> =20
> Updated the namespace to =E2=80=9Chttp://example.com/ns/example-newco-ac=
l =
=E2=80=9D
> =20
> Cheers.
>=20
>=20
>>=20
>>=20
>>=20
>> Thanks,
>> Kent
>>=20
>>=20
>>=20
>>=20
>> _______________________________________________
>> Netconf mailing list
>> Netconf@ietf.org 
>> =
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf.org_mailma=
n_listinfo_netconf&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWz=
oCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7Bx3hgofSFxvNRV7Xz=
7FuaJcKKfzEB0sBJzN_KOCtSg&s=3DXknLqgAu3Z9t1ME6FO-_mZY2oCN61867VB0ubLeiv3Q&=
e=3D =

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

> =20
> Mahesh Jethanandani
> mjethanandani@gmail.com 
> =20

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_CB681D64-5312-4FDE-87EB-66BEB7303717
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8



On Feb 23, 2018, at 12:12 PM, Kent Watsen <kwatsen@juniper.net>=
 wrote:

Hi Mahesh,
 
Please =
search for <KENT> below (6 instances)
 
Thanks,
Kent // =
shepherd
 
 
On 2/17/18, 8:26 PM, "Mahesh =
Jethanandani" <mjethanandani@gmail.com> wrote:
 
Kent, 
 
Thanks for a detailed review. =
See inline.


On Feb 13, 2018, at 2:30 PM, =
Kent Watsen <kwatsen@juniper.net> wrote:
 
[sorry, wrong WG, =
moving netconf to BCC!]


ACL =
Authors,

Below are some issues I found =
while looking at doing the Shepherd
write-up today. =
 Please take a look.

Also, with =
regards to the request for those having Last Call comments
to please verify that their comments were addressed, I only =
saw one
response from Kristian, but should we be expecting =
respeonses from
others too, perhaps Einar or Elliot?
 
Eliot can confirm if he feels his issues have been =
addressed.




1 IDNITS

 - some issues =
found by idnits
 - using https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_tools_idnits_&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3=
voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&m=3D7B=
x3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg&s=3D_5f-lxCoJW2TidcrjW_KbDkd=
PhfxLoL67kn1A2okgs0&e=3D
 - without selecting =
"verbose output"


1.1

 ** There are 5 instances of too long =
lines in the document, the longest one
    being 5 characters in excess of =
72.
 
Fixed.




 This "**" is being flagged as an "error".  
 Idnits label, not mine.  Please fix.


1.2

 =3D=3D There are 7 instances of lines with =
non-RFC6890-compliant IPv4 addresses
    in the document.  If these are =
example addresses, they should be changed.

 This is just a warning, but given that there are seven =
occurrences, it
 might be a good idea to fix. =
 Please see Section 3, point #6 in this
 document =
for details: https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_id-2Dinfo_checklist&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0UjBXeM=
K-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo&=
m=3D7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg&s=3DAYo8ZHPY4SAHMqcy1q=
V9yr7BjoxGy_C9zcJ_ZbwXBT4&e=3D.
 
Fixed.




1.3

 ** The document seems =
to lack a both a reference to RFC 2119 and the
    recommended RFC 2119 boilerplate, =
even if it appears to use RFC 2119
    keywords. 

    RFC 2119 keyword, line 797: =
'...s-list. A device MAY restrict the leng...'


 There needs to be a section that looks =
like RFC 8174, paragraph 11:

    The key words "MUST", "MUST NOT", =
"REQUIRED", "SHALL", "SHALL NOT",
    "SHOULD", "SHOULD NOT", =
"RECOMMENDED", "NOT RECOMMENDED", "MAY",
    and "OPTIONAL" in this document are =
to be interpreted as
    described in =
BCP 14 [RFC2119] [RFC8174] when, and only when, they
    appear in all capitals, as shown =
here.
 
Added.




1.4.

 -- The document date =
(February 2, 2018) is 11 days in the past.  Is this
    intentional?

 This is fine, ignore it.

1.5

 ** Obsolete normative =
reference: RFC 2460

 This needs to be =
fixed.
 
Updated the reference to RFC 8200.



1.6

 ** Downref: Normative =
reference to an Historic RFC: RFC 3540

 Hmmmm, another HISTORIC document, but this time not due =
to an IESG
 action.  The question is how =
important this reference is, is this
 "ns" bit =
(ECN-nonce concealment protection) commonly used in the 
 industry?   
 
I do not know enough to know it is not used. If the consensus =
is that we do not use it, I can drop it from the model.

<KENT> As shepherd, I =
would like the normative reference to a historic RFC removed from this =
draft.   My recommendation is to remove it.  As chair, if =
anyone wants to make a case for keeping the "ns" bit, *now* is
your time to say =
something.

Unless I hear otherwise, I will remove =
it.

 
1.7

 =3D=3D Outdated =
reference: A later version (-06) exists of
    draft-ietf-netmod-yang-tree-diagrams-04=


 Please update to -06
 
This might be because the draft was last published when -04 =
was around. I do not reference any particular version. My reference is =
to 
<?rfc =
include=3D'reference.I-D.ietf-netmod-yang-tree-diagrams=E2=80=99?>. =
The tool pulls in the latest when it generates the draft.
 

1.8

 -- Obsolete =
informational reference (is this intentional?): RFC 5101
    (Obsoleted by RFC 7011)

 Please update to RFC 7011
 
Done.





2  YANG VALIDATION

2.1 Normative Modules

 All =
of the following passed:

   pyang --ietf =
ietf-access-control-list\@2018-02-02.yang 
   pyang --ietf =
ietf-packet-fields\@2018-02-02.yang 
   pyang --ietf =
ietf-ethertypes\@2018-02-02.yang

   yanglint -s =
ietf-access-control-list\@2018-02-02.yang 
   yanglint -s =
ietf-packet-fields\@2018-02-02.yang 
   yanglint -s =
ietf-ethertypes\@2018-02-02.yang 

2.2 Example Module

 Example =
module passed `yanglint -s`, but not `pyang --lint`:

   yanglint -s example-newco-acl.yang
   pyang --lint example-newco-acl.yang 

   example-newco-acl.yang:78: error: keyword =
"description" not in
   canonical order, =
expected "type", (See RFC 6020, Section 12)

   example-newco-acl.yang:79: error: keyword =
"type" not in 
   canonical order, (See RFC 6020, Section =
12)

   example-newco-acl.yang:82: error: keyword =
"default" not in 
   canonical order, (See RFC 6020, Section =
12)

 Please fix.
 
Fixed.




2.3 XML Examples from Section 4.3

 yanglint didn't find any issues:

   yanglint =
ietf-access-control-list\@2018-02-02.yang ex-4.3.xml 


2.4 Examples from Section 4.4

 I had to stitch these into the 4.3 example.  It =
found one issue, a typo
 in the last closing tag in =
the first example in this section:

   yanglint =
ietf-access-control-list\@2018-02-02.yang ex-4.4++.xml 
   err : Invalid (mixed names) opening =
(source-port-range-or-operator) and closing (tcp) element tags. =
(/data/access-lists/acl/aces/ace/matches/l4/tcp/source-port-range-or-opera=
tor/source-port-range-or-operator)

 Please fix.
 
Made them complete examples so you do not have to stitch them =
anymore. And made sure yanglint validated the examples before it =
includes it in the draft.




 PS: And this is not a shepherd =
directive, but I found the whole 
     "source-port-range-or-operator" =
syntax clumsy.  I'm surprised
     it didn't look something =
like:

         OLD
          &nb=
sp;    <source-port-range-or-operator>
          &nb=
sp;       <port-range-or-operator>=
;
          &nb=
sp;         <range>
          &nb=
sp;           <l=
ower-port>16384</lower-port>
          &nb=
sp;           <u=
pper-port>65535</upper-port>
          &nb=
sp;         </range>          &nb=
sp;       </port-range-or-operator&g=
t;
          &nb=
sp;    </source-port-range-or-operator>

          &nb=
sp;    <source-port-range-or-operator>
          &nb=
sp;      <port-range-or-operator>
          &nb=
sp;        <operator>
          &nb=
sp;          <operato=
r>eq</operator>
          &nb=
sp;          <port>=
;21</port>
          &nb=
sp;        </operator>
          &nb=
sp;      </port-range-or-operator>
          &nb=
sp;    </source-port-range-or-operator>

         NEW

          &nb=
sp;    <source-port>
          &nb=
sp;      <range>
          &nb=
sp;        <lower>16384</=
lower>
          &nb=
sp;        <upper>65535</=
upper>
          &nb=
sp;      </range>
          &nb=
sp;    </source-port>

          &nb=
sp;    <source-port>
          &nb=
sp;      <operator>
          &nb=
sp;        <operator>eq</=
operator>
          &nb=
sp;        <port>21</port=
>
          &nb=
sp;      </operator>
          &nb=
sp;    </source-port>
 
Did you try making the change in the model to see if it work? =
It will complain that <range> is already used within the container =
and that it cannot be repeated (for destination-port).

<KENT> No, I did not, nor =
do I intend to get that deep into it.  But I recall that Kristian =
made the same comment before, and was making pull requests before, so =
maybe he can suggest =
something?

Kristian=E2=80=99s suggestion requires changing the =
module. It is not an editorial change. And that change will have an =
impact on the MUD draft, which has been sent for =
publication. 



3 Key Draft Sections


3.1 Abstract

 First, I'm =
unsure if that first "sentence" is properly worded, but I
 definitely think that it is a bit too much on the terse =
side.  Can you
 embellish it a little?
 
How about this:
 
OLD:
  =
This document describes a data model of Access Control List (ACL)
  basic building =
blocks.
NEW:
 
  This document describes a data model for Access =
Control List (ACL).  
  ACL is a =
ordered-by-user set of rules, used to configure the forwarding 
  behavior in device.  Each rule is =
used to find a match on a packet, 
  and define actions that will be =
performed on the packet.
 
<KENT> good.
 

 Second, am =
I reading it correct? - is the "Editorial Note" in the
 Abstract section.  I strongly advise moving 
 
Moved it to Introduction section.
 
<KENT> was it before in a =
<note> element?   It may have just been a rendering =
issue that made it look like it was par of the abstract.  If it was =
a <note> before, then that is actually a common use of the =
<note> element.  It doesn't really matter, the RFC Editor =
will remove the section anyway.
 

3.2 RFC Editor Note

 There is no request to replace =
"I-D.ietf-netmod-yang-tree-diagrams" with
 the final =
RFC assignment.
 
Added.



 You might want to add what the current date value used =
in the draft is
 (i.e., 2018-02-02).   PS: =
my draft build tools, which I think you're
 using, =
should set the value for you automatically if you put YYYY-MM-DD
 into the text.
 
Added text to replace the revision date in the model with the =
date the draft gets published.



3.3 =
Import statements missing references

 All import statements in all modules are missing =
reference statements
    - why wasn't =
this caught by the tools?!

 Please see =
rfc6087bis Section 4.7.  
 
Adding reference implies import by revision, which we want to =
avoid, specially since we do not want to import by revision. Right?

<KENT> I wrote "reference" =
(not "revision").  A reference statement just specifies which RFC =
the imported module is defined =
in.

But by saying:

reference =E2=80=9CRFC 7223=E2=80=9D

you are also implying import by revision, which is =
not what the module wants to do. The module wants to import the latest =
revision of ietf-interfaces, not necessarily the module in RFC =
7223. 

I would suggest that we =
let the yang-doctors discussion on this topic decide how we are going to =
reference import statements.



3.4 Security Considerations

 Please reformat the last paragraph so the "aces" path =
is more pronounced.
 Perhaps use hangText.
 
What is hangText? I italicized it.

<KENT> https://xml2rfc.tools.ietf.org/xml2rfcFAQ.html#q_hanging_lists<=
/a>

Done.


 


3.5 IANA =
Considerations

 This section is hard =
to read.

 Consideration breaking up =
the "XML" and the "YANG Module Names" registry
 requests into two subsections.

 Consider making the registration entry requests =
themselves artwork so
 they're line-spaced and =
indented as such.

 The first paragraph =
of the "XML" registry request says "a URI", but it 
 should =
be "two URIs"

 The first paragraph of =
the "YANG Module Names" registry request says 
 "a =
YANG module", but it should be "two YANG modules=E2=80=9D
 
Split into two sections and upped the count of URIs and YANG =
models to three (was missing the ietf-ethertypes module).




3.6 References

 I haven't =
checked yet, but please verify that all the references are
 properly sorted as to being Normative or =
Informative.


3.7 Appendix =
A

 It took me awhile to figure out =
what I was looking at.  The tree-diagram
 is =
poorly indented and there is no text preceding the example =
module. 
 
I have moved the example module after the first paragraph, =
that describes the module. Let me know if that looks ok.



 I recommend you fold the lines of your tree diagram at =
a certain column
 whilst adding a '\' character. =
 I've since added this ability to my draft
 build =
tools, let me know if interested in an update.  You might also =
want
 to look at =
draft-wu-netmod-yang-xml-doc-conventions.
 
Shortened the prefix so the augment statement fits within 72 =
columns. 
 
BTW, I use 'pyang  -f tree =
=E2=80=94tree-line-length=3D69' to generate the tree. Plus I use fold -w =
71 to fold the diagram, but I guess it does not work for augment =
statement.



 Also, please fix the example module's namespace per the =
end of 
 rfc6087bis Section 4.9.
 
 
Cheers.





Thanks,
Kent




_______________________________________________
Netconf mailing list
Netconf@ietf.org
https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman_listinfo_netconf&d=3DDwICAg&c=3DHAkYuh63rsuhr6Scbfh0U=
jBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=
&m=3D7Bx3hgofSFxvNRV7Xz7FuaJcKKfzEB0sBJzN_KOCtSg&s=3DXknLqgAu3Z9t1=
ME6FO-_mZY2oCN61867VB0ubLeiv3Q&e=3D


_______________________________________________
netmod mailing list
netmod@ietf.org
https://www.ietf.org/mailman/listinfo/netmod
 
Mahesh Jethanandani
mjethanandani@gmail.com
 



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_CB681D64-5312-4FDE-87EB-66BEB7303717--


From nobody Mon Feb 26 00:15:26 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DC244120721; Mon, 26 Feb 2018 00:15:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.51
X-Spam-Level: 
X-Spam-Status: No, score=-14.51 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RJDcN-yU5cWu; Mon, 26 Feb 2018 00:15:23 -0800 (PST)
Received: from aer-iport-4.cisco.com (aer-iport-4.cisco.com [173.38.203.54]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9121412D0C3; Mon, 26 Feb 2018 00:15:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=15661; q=dns/txt; s=iport; t=1519632922; x=1520842522; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=b0YiC5DiAexi9Mm4bYX97G54SQhRBoWtvgvn2wSnsdw=; b=TW7CngH9OxFXwihoqt4zSAn7EiBiZHPFZauK581iDVhaWZ16/3nsydAq EOFbPsRImyjLZ/z1kCqCeQjraSk1ssWMgOzZ8DkKG0J2eWXdvRPGmZS1n SLz6RWxBqf5S3/8VY+vQVypN1SUlo/wGq1IncvRSvvYke1DocTu00qRSj c=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos;i="5.47,396,1515456000";  d="asc'?scan'208,217";a="2238628"
Received: from aer-iport-nat.cisco.com (HELO aer-core-1.cisco.com) ([173.38.203.22]) by aer-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 08:15:20 +0000
Received: from [10.61.241.233] ([10.61.241.233]) by aer-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1Q8FJYl012880; Mon, 26 Feb 2018 08:15:20 GMT
To: Mahesh Jethanandani , Kent Watsen 
Cc: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" , Warren Kumari , "Joe Clarke (jclarke)" 
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net> <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com> <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net> <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com>
From: Eliot Lear 
Message-ID: <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com>
Date: Mon, 26 Feb 2018 09:15:19 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com>
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="wlaIfPnTvq1gpOiBwvotjaUIsCXCoBuG0"
Archived-At: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 08:15:25 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--wlaIfPnTvq1gpOiBwvotjaUIsCXCoBuG0
Content-Type: multipart/mixed; boundary="bVstQIfHmBackiUmu03qH6Sx0LiX6vEvc";
 protected-headers="v1"
From: Eliot Lear 
To: Mahesh Jethanandani ,
 Kent Watsen 
Cc: "draft-ietf-netmod-acl-model@ietf.org"
 , "netmod@ietf.org" ,
 Warren Kumari , "Joe Clarke (jclarke)" 
Message-ID: <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com>
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net>
 <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com>
 <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net>
 <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com>
In-Reply-To: <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com>

--bVstQIfHmBackiUmu03qH6Sx0LiX6vEvc
Content-Type: multipart/alternative;
 boundary="------------E8499418C6D8D375F83DF53C"
Content-Language: en-US

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

CgpPbiAyNi4wMi4xOCAwNjo1NSwgTWFoZXNoIEpldGhhbmFuZGFuaSB3cm90ZToKPj4KPj4+
Cj4+Pgo+Pj4gwqBQUzogQW5kIHRoaXMgaXMgbm90IGEgc2hlcGhlcmQgZGlyZWN0aXZlLCBi
dXQgSSBmb3VuZCB0aGUgd2hvbGXCoAo+Pj4gwqDCoMKgwqDCoCJzb3VyY2UtcG9ydC1yYW5n
ZS1vci1vcGVyYXRvciIgc3ludGF4IGNsdW1zeS4gwqBJJ20gc3VycHJpc2VkCj4+PiDCoMKg
wqDCoMKgaXQgZGlkbid0IGxvb2sgc29tZXRoaW5nIGxpa2U6Cj4+Pgo+Pj4gwqDCoMKgwqDC
oMKgwqDCoMKgT0xECj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8c291cmNl
LXBvcnQtcmFuZ2Utb3Itb3BlcmF0b3I+Cj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqA8cG9ydC1yYW5nZS1vci1vcGVyYXRvcj4KPj4+IMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8cmFuZ2U+Cj4+PiDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxsb3dlci1wb3J0PjE2Mzg0PC9sb3dlci1w
b3J0Pgo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8
dXBwZXItcG9ydD42NTUzNTwvdXBwZXItcG9ydD4KPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqA8L3JhbmdlPgo+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgPC9wb3J0LXJhbmdlLW9yLW9wZXJhdG9yPgo+Pj4gwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9zb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcj4K
Pj4+Cj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8c291cmNlLXBvcnQtcmFu
Z2Utb3Itb3BlcmF0b3I+Cj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
PHBvcnQtcmFuZ2Utb3Itb3BlcmF0b3I+Cj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoDxvcGVyYXRvcj4KPj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoDxvcGVyYXRvcj5lcTwvb3BlcmF0b3I+Cj4+PiDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8cG9ydD4yMTwvcG9ydD4KPj4+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9vcGVyYXRvcj4KPj4+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L3BvcnQtcmFuZ2Utb3Itb3BlcmF0
b3I+Cj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L3NvdXJjZS1wb3J0LXJh
bmdlLW9yLW9wZXJhdG9yPgo+Pj4KPj4+IMKgwqDCoMKgwqDCoMKgwqDCoE5FVwo+Pj4KPj4+
IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxzb3VyY2UtcG9ydD4KPj4+IMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8cmFuZ2U+Cj4+PiDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxsb3dlcj4xNjM4NDwvbG93ZXI+Cj4+PiDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDx1cHBlcj42NTUzNTwvdXBwZXI+
Cj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9yYW5nZT4KPj4+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwvc291cmNlLXBvcnQ+Cj4+Pgo+Pj4gwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHNvdXJjZS1wb3J0Pgo+Pj4gwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxvcGVyYXRvcj4KPj4+IMKgwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPG9wZXJhdG9yPmVxPC9vcGVyYXRvcj4KPj4+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHBvcnQ+MjE8L3BvcnQ+Cj4+
PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9vcGVyYXRvcj4KPj4+IMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwvc291cmNlLXBvcnQ+Cj4+Pgo+PiDCoAo+
PiBEaWQgeW91IHRyeSBtYWtpbmcgdGhlIGNoYW5nZSBpbiB0aGUgbW9kZWwgdG8gc2VlIGlm
IGl0IHdvcms/IEl0IHdpbGwKPj4gY29tcGxhaW4gdGhhdCA8cmFuZ2U+IGlzIGFscmVhZHkg
dXNlZCB3aXRoaW4gdGhlIGNvbnRhaW5lciBhbmQgdGhhdAo+PiBpdCBjYW5ub3QgYmUgcmVw
ZWF0ZWQgKGZvciBkZXN0aW5hdGlvbi1wb3J0KS4KPj4KPj4gPEtFTlQ+IE5vLCBJIGRpZCBu
b3QsIG5vciBkbyBJIGludGVuZCB0byBnZXQgdGhhdCBkZWVwIGludG8gaXQuwqAgQnV0Cj4+
IEkgcmVjYWxsIHRoYXQgS3Jpc3RpYW4gbWFkZSB0aGUgc2FtZSBjb21tZW50IGJlZm9yZSwg
YW5kIHdhcyBtYWtpbmcKPj4gcHVsbCByZXF1ZXN0cyBiZWZvcmUsIHNvIG1heWJlIGhlIGNh
biBzdWdnZXN0IHNvbWV0aGluZz8KPgo+IEtyaXN0aWFu4oCZcyBzdWdnZXN0aW9uIHJlcXVp
cmVzIGNoYW5naW5nIHRoZSBtb2R1bGUuIEl0IGlzIG5vdCBhbgo+IGVkaXRvcmlhbCBjaGFu
Z2UuIEFuZCB0aGF0IGNoYW5nZSB3aWxsIGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBNVUQKPiBk
cmFmdCwgd2hpY2ggaGFzIGJlZW4gc2VudCBmb3IgcHVibGljYXRpb24uwqAKPgoKQXMgaXQg
aGFwcGVucywgd2UgZm91bmQgYSBidWcgaW4gb3VyIGF1Z21lbnQgc3RhdGVtZW50cywgYW5k
IHNvIHdlIHdpbGwKbmVlZCB0byByZXYgb25lIG1vcmUgdGltZS7CoCBJZiB0aGUgY2hhbmdl
IGNhbiBiZSBtYWRlIHF1aWNrbHksIEkgY2FuCmxpdmUgd2l0aCBpdC4KCkVsaW90Cg==
--------------E8499418C6D8D375F83DF53C
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    


    

    

    
On 26.02.18 06:55, Mahesh Jethanandani=

      wrote:

    

    

      

        

          

            

              

                

                  


                    

                  

                    

                      

                        


                          

                          =C2=A0PS: And this is not a shepherd directive,=
 but
                          I found the whole=C2=A0=


                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"source-port-rang=
e-or-operator" syntax
                          clumsy. =C2=A0I'm surprised

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0it didn't look so=
mething like:

                          

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0OLD

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0<source-port-range-or-operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<port-range-or-operator>

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&=
lt;range>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<lower-port&g=
t;16384</lower-port>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<upper-port&g=
t;65535</upper-port>

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0&=
lt;/range>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</port-range-or-operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0</source-port-range-or-operator>

                          

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0<source-port-range-or-operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0<port-range-or-operator>

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<ope=
rator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<operator>eq<=
/operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<port>21</por=
t>

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</op=
erator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0</port-range-or-operator>
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0</source-port-range-or-operator>

                          

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0NEW

                          

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<source-port>

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<range>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<lower>16384</lower>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<upper>65535</upper>
                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</range>

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</source-port>

                          

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<source-port>

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<operator>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<operator>eq</operator>=
;

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<por=
t>21</port>

                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</operator>
                          =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</source-port>

                      

                    

                  

                  

                    
=C2=A0

                  

                  
Did
                    you try making the change in the model to see if it
                    work? It will complain that <range> is already
                    used within the container and that it cannot be
                    repeated (for destination-port).

                

                

                  


                    <KENT> No, I did not, nor do I intend to get
                    that deep into it.=C2=A0 But I recall that Kristian m=
ade
                    the same comment before, and was making pull
                    requests before, so maybe he can suggest something?
                

              

            

          

        

        


        

        Kristian=E2=80=99s suggestion requires changing the module. It is=
 not an
        editorial change. And that change will have an impact on the MUD
        draft, which has been sent for publication.=C2=A0

      


      

    

    

    As it happens, we found a bug in our augment statements, and so we
    will need to rev one more time.=C2=A0 If the change can be made quick=
ly,
    I can live with it.

    

    Eliot

  


--------------E8499418C6D8D375F83DF53C--

--bVstQIfHmBackiUmu03qH6Sx0LiX6vEvc--

--wlaIfPnTvq1gpOiBwvotjaUIsCXCoBuG0
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlqTwhcACgkQh7ZrRtnS
ejNpSAf8DDBjTTJozkGVCx27uDkp2cH59B+dTZkMNcf+AZaZMjwWN9ugQPvEDSis
svq5ETsb3caedMpkPy+HfNYFknAXxebGfDdRdkpq5+S5XP0a1WAXkPiNdc+JVMbx
CsMm0WxBR3NUycWEoAuzj2uQrziArleWchuATGuOqMubuf7WL4bjlLZ4Cfq5vQ/D
RhgAHEOnPFKn08LdSmTue+IQYTg0JiZjIE4Xip4ClWdpYTqaLIGgRJCY+PtM00S6
ubEAT6RajhT53X59nVxR63D4OQvibqLpAkZCb+IVOe4PjQtIJCgwqII63LftJOtl
hdSMvKQNdMSCafpFYOPy/Q4rYOihXg==
=G/EW
-----END PGP SIGNATURE-----

--wlaIfPnTvq1gpOiBwvotjaUIsCXCoBuG0--


From nobody Mon Feb 26 00:38:25 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 244C912D77C; Mon, 26 Feb 2018 00:38:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.311
X-Spam-Level: 
X-Spam-Status: No, score=-4.311 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=swm.pp.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QXlhUiNZVFu; Mon, 26 Feb 2018 00:38:18 -0800 (PST)
Received: from uplift.swm.pp.se (ipv6.swm.pp.se [IPv6:2a00:801::f]) (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 1B94612D77A; Mon, 26 Feb 2018 00:38:18 -0800 (PST)
Received: by uplift.swm.pp.se (Postfix, from userid 501) id 89146AF; Mon, 26 Feb 2018 09:38:15 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=swm.pp.se; s=mail; t=1519634295; bh=v9BBBQSrcbZbUJlalOFXMZtVK1lAeOSaFswZNVT0EkI=; h=Date:From:To:cc:Subject:In-Reply-To:References:From; b=PbwEW515sUyciIchaSVBNKz1bTlBUOVw14bYwIXGdG8Qw+5Yd9cNxaNiShKlzLznG Ry7iiLtIdU+CXfayno/haJqaT4O8C24crVfVgk9fzoCUc+63mT2clSxVgwLhT1hpIS dCfr+2HO3U0wLz2Yc7Da03RtdfKdDLdik1mhFFW4=
Received: from localhost (localhost [127.0.0.1]) by uplift.swm.pp.se (Postfix) with ESMTP id 874459F; Mon, 26 Feb 2018 09:38:15 +0100 (CET)
Date: Mon, 26 Feb 2018 09:38:15 +0100 (CET)
From: Mikael Abrahamsson 
To: Christian Hopps 
cc: "netconf@ietf.org" , "netmod@ietf.org" 
In-Reply-To: <87vaemarb5.fsf@chopps.org>
Message-ID: 
References: <87o9ke9o63.fsf@chopps.org> <87vaemarb5.fsf@chopps.org>
User-Agent: Alpine 2.20 (DEB 67 2015-01-07)
Organization: People's Front Against WWW
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII; format=flowed
Archived-At: 
Subject: Re: [netmod] [Netconf] Open source filtering code?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 08:38:20 -0000

On Sat, 24 Feb 2018, Christian Hopps wrote:

>
> Still interested in any answers to this query; however, I thought I would 
> followup..

Have you looked at libyang ?

https://github.com/CESNET/libyang

It's heavily used in Sysrepo/Netopeer2 for all the YANG related functions.

-- 
Mikael Abrahamsson    email: swmike@swm.pp.se


From nobody Mon Feb 26 03:52:26 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E524F126D85 for ; Mon, 26 Feb 2018 03:52:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rDQLrqni5Aok for ; Mon, 26 Feb 2018 03:52:14 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 4D582126CB6 for ; Mon, 26 Feb 2018 03:52:14 -0800 (PST)
Received: from pip.chopps.org (mobile-166-177-56-80.mycingular.net [166.177.56.80]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 6791B62A2F; Mon, 26 Feb 2018 11:52:12 +0000 (UTC)
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com>
User-agent: mu4e 0.9.19; emacs 25.3.1
From: Christian Hopps 
To: Robert Wilton 
Cc: Christian Hopps , Martin Bjorklund , netmod@ietf.org
In-reply-to: <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com>
Date: Mon, 26 Feb 2018 06:52:10 -0500
Message-ID: <87lgfg9ded.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 11:52:24 -0000

Hi Rob,

You do realize that no-one trying to actually deploy and run networks cares about live-discovery of different schema per datastore for the same mount point right? Like 99.999% of the clients know where things are supposed to reside and expect them to be there. At most (although still not common) they may want to know what modules are supported under a mount point. What your talking about is a severe edge case that apparently has achieved extreme importance in a very small group of people's views.

Thanks,
Chris.

Robert Wilton  writes:

> Hi Chris,
>
> I've got no desire or intent to try and slow down the NI and LNE drafts, or any
> that depend on them. I actually agree that this is critically important that
> IETF gets modules standardized/finished so that everyone can use them.
>
> However, ...
>
> YLbis has quite a different structure to YL. The main part of this change was
> to support NMDA, the other part of this change was to better support things like
> SM, or YANG packages.
>
> I don't think that there is a clean, backwards compatible, way to go from the
> YANG module in SM -08 to one that is going to work well with YLbis and other
> YLbis extensions/augmentations that seem to be coming down the line. Given what
> we know now, I believe that the correct medium/long term structure for the SM
> YANG module, taking YLbis into account, is the one proposed in pre09, because it
> directly augments the YLbis structure, and hence any future augmentations to
> YLbis should automatically extend to SM mounted schema as well.
>
> I think that the likely future technical issues with the -08 module will be:
> - supporting NMDA in a clean consistent way
> - adding in support for SemVer
> - additional capability reporting as an augmentation to YANG library
>
> So, if -08 proceeds as is, then it seems to me like one of three things will
> need to happen:
> 1) Their will need to be a non backwards compatible update to the SM model that
> is the same/similar to pre09.
> 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for explicitly
> mounted schema.
> 3) We accrue technical debt, implementations need to support two YL module
> structures, the one in SM and the one in YLbis, and future extensions need to
> augment both the SM structure and YLbis structure.
>
> I don't like the idea of (2) or (3), but I don't know if others will find (1)
> acceptable.
>
> But I do agree that we are just going round in circles on this:
> - Using the pre09 structure is not acceptable to some folks
> - Publishing a draft with both -08 and pre09 structure is liked by even less
> folks.
>
> Perhaps publishing -08 is the only option. My hope is that the WG will support
> somebody subsequently doing solution (1), otherwise it seems like a missed
> opportunity to get this right.
>
> Thanks,
> Rob
>
>
> On 24/02/2018 13:54, Christian Hopps wrote:
>> My position,
>>
>> It may be the case that there's even a better cleaner solution; however, it's
>> simply too late for major modifications to this work that don't actually
>> address functional failures. The draft as proposed works for the people who
>> need to get work done.
>>
>> We have multiple pending RFCs - MISREF on this document. These RFCs would have
>> to be pulled from the RFC EDITOR queue, and reworked to be compliant again,
>> and this very well could lead to discovering issues with your new proposal.
>> Any new issues discovered in either the pending RFCs *or* in the new solution
>> would then need to be worked out and fixed. Please recall that this actually
>> occurred on the first round (i.e., doing the examples led to discovering
>> problems with the drafts), so it's not unreasonable at all to assume this
>> would happen again.
>>
>> Look this just isn't a simple change your proposing. It involves a large
>> upheaval, killing the pending RFC status on multiple documents that the
>> industry is waiting on. Please see this.
>>
>> Thanks,
>> Chris.
>>
>>
>> Martin Bjorklund  writes:
>>
>>> Hi,
>>>
>>> Robert Wilton  wrote:
>>>> Hi Lou,
>>>>
>>>> I think that this solution is inferior to the model presented in
>>>> pre-09.
>>>
>>> I agree. Servers that are NMDA-compliant, or implements YANG Library
>>> bis will have to present schemas in two different structures,
>>> depending on where the schema is used, and clients will have to code
>>> for both. With the solution in pre-09, there is just one structure.
>>> A single structure also has other benefits (apart from being simpler),
>>> e.g., if we augment it with the meta data that has been discussed
>>> recently, we can augment a single structure.
>>
>>> /martin
>>>
>>>
>>>
>>>> I would prefer that we publish pre09 instead, potentially including
>>>> the -08 model in the appendix if that helps progress the document in a
>>>> more expedient fashion.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> On 22/02/2018 16:18, Lou Berger wrote:
>>>> > Hi,
>>>> >
>>>> > (I have a bunch of different roles WRT this work. This mail is being
>>>> > sent as an individual - as chair, I fully support the previous chair
>>>> > statements on this draft.)
>>>> >
>>>> > Chris and I have come up with a proposal on how to provide full NMDA
>>>> > as part the existing schema-mount module. Our motivation was to
>>>> > enable full NMDA support with *minimal* change to the model and
>>>> > disruption to the LC'ed work. The key NMDA limitation, with -08, that
>>>> > we are aiming to address is the ability to support different mounted
>>>> > schema in different datastores for non-inline mount points. (See more
>>>> > detailed description below if interested full nuances of limitations
>>>> > of -08)
>>>> >
>>>> > What we came up with was to simply add a (leaf)list to identify in
>>>> > which datastores a
>>>> > schema-mount schema is valid/present. This is somewhat similar to
>>>> > YL-bis schema/module-set. Specifically we're proposing (see below for
>>>> > full tree below):
>>>> >
>>>> > +--ro schema* [name]
>>>> > +--ro name string
>>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>>> >
>>>> > This approach has the advantages of supporting different mounted
>>>> > schema in different DSes, working with both NMDA and non-NMDA
>>>> > implementations, supporting all of the extensively discussed features
>>>> > of schema mount (including recursive mounts), and having minor/scoped
>>>> > impact on all dependent work. The main downside is that it isn't the
>>>> > most optimal/compact solution possible if we were to base this work on
>>>> > YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from all
>>>> > perspectives, but it is what was agreed to as sufficient by those who
>>>> > contribute to the WG discussion.
>>>> >
>>>> > In short, we see this as a solution to addresses the raised last call
>>>> > issue with the minimal impact on -08 and dependent work -- which is
>>>> > what is appropriate given where we are in the process.
>>>> >
>>>> > So our/my question really is:
>>>> >
>>>> > Is this a solution that you/all can live with?
>>>> >
>>>> > Note: optimization, design preference and perfect alignment with use
>>>> > or YL-bis are not part of our question as we both don't think that is
>>>> > the right question given where we are in the WG process.
>>>> >
>>>> > Lou (with ideas developed with Chris, and chair hat off)
>>>> >
>>>> > ======
>>>> > Details -- for those who want
>>>> > ======
>>>> > As background, my understanding/view is that the -08 version of the
>>>> > both NMDA and non-NMDA supporting implementations, but there are
>>>> > limitations in its NMDA applicability. Used with Yang Library,
>>>> > [rfc7895], only non-NMDA implementations can be supported. When used
>>>> > with the revised Yang Library defined in
>>>> > [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
>>>> > supported with certain limitations. Specifically, this document
>>>> > requires use of the now deprecated module-list grouping, and the same
>>>> > schema represented in schema list of the Schema Mount module MUST be
>>>> > used in all datastores. Inline type mount points, which don't use the
>>>> > schema list, can support different schema in different data stores
>>>> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>>> > YANG library under the inline mount point.
>>>> >
>>>> > module: ietf-yang-schema-mount
>>>> > +--ro schema-mounts
>>>> > +--ro namespace* [prefix]
>>>> > | +--ro prefix yang:yang-identifier
>>>> > | +--ro uri? inet:uri
>>>> > +--ro mount-point* [module name]
>>>> > | +--ro module yang:yang-identifier
>>>> > | +--ro name yang:yang-identifier
>>>> > | +--ro config? boolean
>>>> > | +--ro (schema-ref)?
>>>> > | +--:(inline)
>>>> > | | +--ro inline? empty
>>>> > | +--:(use-schema)
>>>> > | +--ro use-schema* [name]
>>>> > | +--ro name
>>>> > | | -> /schema-mounts/schema/name
>>>> > | +--ro parent-reference* yang:xpath1.0
>>>> > +--ro schema* [name]
>>>> > +--ro name string
>>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>>> > +--ro module* [name revision]
>>>> > | +--ro name yang:yang-identifier
>>>> > | +--ro revision union
>>>> > | +--ro schema? inet:uri
>>>> > | +--ro namespace inet:uri
>>>> > | +--ro feature* yang:yang-identifier
>>>> > | +--ro deviation* [name revision]
>>>> > | | +--ro name yang:yang-identifier
>>>> > | | +--ro revision union
>>>> > | +--ro conformance-type enumeration
>>>> > | +--ro submodule* [name revision]
>>>> > | +--ro name yang:yang-identifier
>>>> > | +--ro revision union
>>>> > | +--ro schema? inet:uri
>>>> > +--ro mount-point* [module name]
>>>> > +--ro module yang:yang-identifier
>>>> > +--ro name yang:yang-identifier
>>>> > +--ro config? boolean
>>>> > +--ro (schema-ref)?
>>>> > +--:(inline)
>>>> > | +--ro inline? empty
>>>> > +--:(use-schema)
>>>> > +--ro use-schema* [name]
>>>> > +--ro name
>>>> > | -> /schema-mounts/schema/name
>>>> > +--ro parent-reference* yang:xpath1.0
>>>> >
>>>> > We would expect that the revised-datastores feature would be used
>>>> > (perhaps required) for any implementation that supports
>>>> > ietf-datastores
>>>> > and yl-bis.
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > netmod mailing list
>>>> > netmod@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> .
>>


From nobody Mon Feb 26 04:36:06 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F4BC126BF3 for ; Mon, 26 Feb 2018 04:36:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mhr2zQDQ_Vkl for ; Mon, 26 Feb 2018 04:36:02 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 33873124234 for ; Mon, 26 Feb 2018 04:36:02 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=12363; q=dns/txt; s=iport; t=1519648562; x=1520858162; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=UHq/ww7i/sS1/Aj2a+5xL320BRdTQ1gzg34d8dVJU4s=; b=RoK9FYMmUztyIYUSAB0+7q+HnojI0d4cwDjMNpTL6l7Yd9Yo5WfnhQkH fA0HHz/ie+Klc0oW6Uvni74aouJ/lW2mICSaGgV9zeifzJABPgI4wxRY3 guGm3vRS8iPNyhykVoM88DaDlI+Ua0YFwiQb6VBvAJsLdSJ1vwSFdgYaW k=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CSAAC3/ZNa/xbLJq1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGENXAog1SKInSOWAsnexuWBRSCAgoYC4RBTwKDFBgBAgEBAQE?= =?us-ascii?q?BAQJrKIUkAQEEAQEhBAsBBTYCCRALDgoCAhEVAgInMAYNBgIBAReEdRCqdoFtO?= =?us-ascii?q?oR0g3CCFAEBAQEBAQEBAQEBAQEBAQEBAQEBARgFgQ+ICoFmKQyBalg2gy4BAYE?= =?us-ascii?q?sGgsBAR4/gk6CZQWRLpAzCZQgggaFZoM/hzWJZ4RqhCsrgk6BLx44gVEzGggbF?= =?us-ascii?q?TqCQ4RaQDeKHoI5AQEB?=
X-IronPort-AV: E=Sophos;i="5.47,396,1515456000";  d="scan'208";a="2249032"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 12:36:00 +0000
Received: from [10.63.23.77] (dhcp-ensft1-uk-vla370-10-63-23-77.cisco.com [10.63.23.77]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1QCZxMd022268; Mon, 26 Feb 2018 12:35:59 GMT
To: Christian Hopps 
Cc: Martin Bjorklund , netmod@ietf.org
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87lgfg9ded.fsf@chopps.org>
From: Robert Wilton 
Message-ID: 
Date: Mon, 26 Feb 2018 12:35:59 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <87lgfg9ded.fsf@chopps.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 12:36:05 -0000

Hi Chris,

The future issues that I'm predicting is not tied to per datastore 
schema, but because the SM YANG module is tied to a version of YL that 
is being deprecated and replaced by a similar but different structure in 
YLbis.

If all mounted modules are also available at top level modules, and 
hence will be reported in YLbis regardless, then I agree that it 
probably doesn't matter so much.

But if there are YANG modules that are only available at mounted 
locations (and not at the top level) then they would not be listed in 
the top level YANG library and I think that you will hit the issues that 
I describe below.  E.g. you wouldn't be able to retrieve the SemVer 
information for those mounted modules, etc.

Thanks,
Rob


On 26/02/2018 11:52, Christian Hopps wrote:
>
> Hi Rob,
>
> You do realize that no-one trying to actually deploy and run networks 
> cares about live-discovery of different schema per datastore for the 
> same mount point right? Like 99.999% of the clients know where things 
> are supposed to reside and expect them to be there. At most (although 
> still not common) they may want to know what modules are supported 
> under a mount point. What your talking about is a severe edge case 
> that apparently has achieved extreme importance in a very small group 
> of people's views.
>
> Thanks,
> Chris.
>
> Robert Wilton  writes:
>
>> Hi Chris,
>>
>> I've got no desire or intent to try and slow down the NI and LNE 
>> drafts, or any
>> that depend on them. I actually agree that this is critically 
>> important that
>> IETF gets modules standardized/finished so that everyone can use them.
>>
>> However, ...
>>
>> YLbis has quite a different structure to YL. The main part of this 
>> change was
>> to support NMDA, the other part of this change was to better support 
>> things like
>> SM, or YANG packages.
>>
>> I don't think that there is a clean, backwards compatible, way to go 
>> from the
>> YANG module in SM -08 to one that is going to work well with YLbis 
>> and other
>> YLbis extensions/augmentations that seem to be coming down the line. 
>> Given what
>> we know now, I believe that the correct medium/long term structure 
>> for the SM
>> YANG module, taking YLbis into account, is the one proposed in pre09, 
>> because it
>> directly augments the YLbis structure, and hence any future 
>> augmentations to
>> YLbis should automatically extend to SM mounted schema as well.
>>
>> I think that the likely future technical issues with the -08 module 
>> will be:
>> - supporting NMDA in a clean consistent way
>> - adding in support for SemVer
>> - additional capability reporting as an augmentation to YANG library
>>
>> So, if -08 proceeds as is, then it seems to me like one of three 
>> things will
>> need to happen:
>> 1) Their will need to be a non backwards compatible update to the SM 
>> model that
>> is the same/similar to pre09.
>> 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for 
>> explicitly
>> mounted schema.
>> 3) We accrue technical debt, implementations need to support two YL 
>> module
>> structures, the one in SM and the one in YLbis, and future extensions 
>> need to
>> augment both the SM structure and YLbis structure.
>>
>> I don't like the idea of (2) or (3), but I don't know if others will 
>> find (1)
>> acceptable.
>>
>> But I do agree that we are just going round in circles on this:
>> - Using the pre09 structure is not acceptable to some folks
>> - Publishing a draft with both -08 and pre09 structure is liked by 
>> even less
>> folks.
>>
>> Perhaps publishing -08 is the only option. My hope is that the WG 
>> will support
>> somebody subsequently doing solution (1), otherwise it seems like a 
>> missed
>> opportunity to get this right.
>>
>> Thanks,
>> Rob
>>
>>
>> On 24/02/2018 13:54, Christian Hopps wrote:
>>> My position,
>>>
>>> It may be the case that there's even a better cleaner solution; 
>>> however, it's
>>> simply too late for major modifications to this work that don't 
>>> actually
>>> address functional failures. The draft as proposed works for the 
>>> people who
>>> need to get work done.
>>>
>>> We have multiple pending RFCs - MISREF on this document. These RFCs 
>>> would have
>>> to be pulled from the RFC EDITOR queue, and reworked to be compliant 
>>> again,
>>> and this very well could lead to discovering issues with your new 
>>> proposal.
>>> Any new issues discovered in either the pending RFCs *or* in the new 
>>> solution
>>> would then need to be worked out and fixed. Please recall that this 
>>> actually
>>> occurred on the first round (i.e., doing the examples led to 
>>> discovering
>>> problems with the drafts), so it's not unreasonable at all to assume 
>>> this
>>> would happen again.
>>>
>>> Look this just isn't a simple change your proposing. It involves a 
>>> large
>>> upheaval, killing the pending RFC status on multiple documents that the
>>> industry is waiting on. Please see this.
>>>
>>> Thanks,
>>> Chris.
>>>
>>>
>>> Martin Bjorklund  writes:
>>>
>>>> Hi,
>>>>
>>>> Robert Wilton  wrote:
>>>>> Hi Lou,
>>>>>
>>>>> I think that this solution is inferior to the model presented in
>>>>> pre-09.
>>>>
>>>> I agree. Servers that are NMDA-compliant, or implements YANG Library
>>>> bis will have to present schemas in two different structures,
>>>> depending on where the schema is used, and clients will have to code
>>>> for both. With the solution in pre-09, there is just one structure.
>>>> A single structure also has other benefits (apart from being simpler),
>>>> e.g., if we augment it with the meta data that has been discussed
>>>> recently, we can augment a single structure.
>>>
>>>> /martin
>>>>
>>>>
>>>>
>>>>> I would prefer that we publish pre09 instead, potentially including
>>>>> the -08 model in the appendix if that helps progress the document 
>>>>> in a
>>>>> more expedient fashion.
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On 22/02/2018 16:18, Lou Berger wrote:
>>>>> > Hi,
>>>>> >
>>>>> > (I have a bunch of different roles WRT this work. This mail is 
>>>>> being
>>>>> > sent as an individual - as chair, I fully support the previous 
>>>>> chair
>>>>> > statements on this draft.)
>>>>> >
>>>>> > Chris and I have come up with a proposal on how to provide full 
>>>>> NMDA
>>>>> > as part the existing schema-mount module. Our motivation was to
>>>>> > enable full NMDA support with *minimal* change to the model and
>>>>> > disruption to the LC'ed work. The key NMDA limitation, with -08, 
>>>>> that
>>>>> > we are aiming to address is the ability to support different 
>>>>> mounted
>>>>> > schema in different datastores for non-inline mount points. (See 
>>>>> more
>>>>> > detailed description below if interested full nuances of 
>>>>> limitations
>>>>> > of -08)
>>>>> >
>>>>> > What we came up with was to simply add a (leaf)list to identify in
>>>>> > which datastores a
>>>>> > schema-mount schema is valid/present. This is somewhat similar to
>>>>> > YL-bis schema/module-set. Specifically we're proposing (see 
>>>>> below for
>>>>> > full tree below):
>>>>> >
>>>>> > +--ro schema* [name]
>>>>> > +--ro name string
>>>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>>>> >
>>>>> > This approach has the advantages of supporting different mounted
>>>>> > schema in different DSes, working with both NMDA and non-NMDA
>>>>> > implementations, supporting all of the extensively discussed 
>>>>> features
>>>>> > of schema mount (including recursive mounts), and having 
>>>>> minor/scoped
>>>>> > impact on all dependent work. The main downside is that it isn't 
>>>>> the
>>>>> > most optimal/compact solution possible if we were to base this 
>>>>> work on
>>>>> > YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from 
>>>>> all
>>>>> > perspectives, but it is what was agreed to as sufficient by 
>>>>> those who
>>>>> > contribute to the WG discussion.
>>>>> >
>>>>> > In short, we see this as a solution to addresses the raised last 
>>>>> call
>>>>> > issue with the minimal impact on -08 and dependent work -- which is
>>>>> > what is appropriate given where we are in the process.
>>>>> >
>>>>> > So our/my question really is:
>>>>> >
>>>>> > Is this a solution that you/all can live with?
>>>>> >
>>>>> > Note: optimization, design preference and perfect alignment with 
>>>>> use
>>>>> > or YL-bis are not part of our question as we both don't think 
>>>>> that is
>>>>> > the right question given where we are in the WG process.
>>>>> >
>>>>> > Lou (with ideas developed with Chris, and chair hat off)
>>>>> >
>>>>> > ======
>>>>> > Details -- for those who want
>>>>> > ======
>>>>> > As background, my understanding/view is that the -08 version of the
>>>>> > both NMDA and non-NMDA supporting implementations, but there are
>>>>> > limitations in its NMDA applicability. Used with Yang Library,
>>>>> > [rfc7895], only non-NMDA implementations can be supported. When 
>>>>> used
>>>>> > with the revised Yang Library defined in
>>>>> > [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
>>>>> > supported with certain limitations. Specifically, this document
>>>>> > requires use of the now deprecated module-list grouping, and the 
>>>>> same
>>>>> > schema represented in schema list of the Schema Mount module 
>>>>> MUST be
>>>>> > used in all datastores. Inline type mount points, which don't 
>>>>> use the
>>>>> > schema list, can support different schema in different data stores
>>>>> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>>>> > YANG library under the inline mount point.
>>>>> >
>>>>> > module: ietf-yang-schema-mount
>>>>> > +--ro schema-mounts
>>>>> > +--ro namespace* [prefix]
>>>>> > | +--ro prefix yang:yang-identifier
>>>>> > | +--ro uri? inet:uri
>>>>> > +--ro mount-point* [module name]
>>>>> > | +--ro module yang:yang-identifier
>>>>> > | +--ro name yang:yang-identifier
>>>>> > | +--ro config? boolean
>>>>> > | +--ro (schema-ref)?
>>>>> > | +--:(inline)
>>>>> > | | +--ro inline? empty
>>>>> > | +--:(use-schema)
>>>>> > | +--ro use-schema* [name]
>>>>> > | +--ro name
>>>>> > | | -> /schema-mounts/schema/name
>>>>> > | +--ro parent-reference* yang:xpath1.0
>>>>> > +--ro schema* [name]
>>>>> > +--ro name string
>>>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>>>> > +--ro module* [name revision]
>>>>> > | +--ro name yang:yang-identifier
>>>>> > | +--ro revision union
>>>>> > | +--ro schema? inet:uri
>>>>> > | +--ro namespace inet:uri
>>>>> > | +--ro feature* yang:yang-identifier
>>>>> > | +--ro deviation* [name revision]
>>>>> > | | +--ro name yang:yang-identifier
>>>>> > | | +--ro revision union
>>>>> > | +--ro conformance-type enumeration
>>>>> > | +--ro submodule* [name revision]
>>>>> > | +--ro name yang:yang-identifier
>>>>> > | +--ro revision union
>>>>> > | +--ro schema? inet:uri
>>>>> > +--ro mount-point* [module name]
>>>>> > +--ro module yang:yang-identifier
>>>>> > +--ro name yang:yang-identifier
>>>>> > +--ro config? boolean
>>>>> > +--ro (schema-ref)?
>>>>> > +--:(inline)
>>>>> > | +--ro inline? empty
>>>>> > +--:(use-schema)
>>>>> > +--ro use-schema* [name]
>>>>> > +--ro name
>>>>> > | -> /schema-mounts/schema/name
>>>>> > +--ro parent-reference* yang:xpath1.0
>>>>> >
>>>>> > We would expect that the revised-datastores feature would be used
>>>>> > (perhaps required) for any implementation that supports
>>>>> > ietf-datastores
>>>>> > and yl-bis.
>>>>> >
>>>>> >
>>>>> >
>>>>> > _______________________________________________
>>>>> > netmod mailing list
>>>>> > netmod@ietf.org
>>>>> > https://www.ietf.org/mailman/listinfo/netmod
>>>>>
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> .
>>>
>
> .
>


From nobody Mon Feb 26 05:25:07 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 51EDE12D779 for ; Mon, 26 Feb 2018 05:25:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Hv5yBT65Z7rh for ; Mon, 26 Feb 2018 05:25:04 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E66F7126DED for ; Mon, 26 Feb 2018 05:25:03 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 17A221820413; Mon, 26 Feb 2018 14:21:54 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 0F5E718203F6; Mon, 26 Feb 2018 14:21:50 +0100 (CET)
From: Ladislav Lhotka 
To: Per Hedeland , "netmod\@ietf.org" 
In-Reply-To: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com>
References: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com>
Mail-Followup-To: Per Hedeland , "netmod\@ietf.org" 
Date: Mon, 26 Feb 2018 14:24:58 +0100
Message-ID: <87y3jf51ed.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] derived-from() vs derived-from-or-self() in acl model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 13:25:06 -0000

Per Hedeland  writes:

> Hi,
>
> A customer of ours using one of the draft versions of the
> ietf-access-control-list module reported that it was not possible to
> configure an ethernet ace with type acl:eth-acl-type, due to the
> derived-from() in
>
>                container eth {
>                  when "derived-from(../../../../type, " +
>                       "'acl:eth-acl-type')";
>                  if-feature match-on-eth;
>                  uses pf:acl-eth-header-fields;
>                  description
>                    "Rule set that matches ethernet headers.";
>                }
>
> evaluating to "false". I pointed out that this is correct behavior of
> our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
> it would need to be derived-from-or-self() in order to evaluate to
> "true". I also ventured a guess (not having followed the development of
> the acl model in detail) that the intent was that vendors should define
> their own identities, that actually *were* derived from acl:eth-acl-type
> (and ditto for all the other *-acl-type identities, of course).
>
> However I'm not at all sure that the guess is correct, and if so why
> this should be *enforced* by excluding the base identity. And having a
> look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
> seems to be doing exactly what our customer tried, alhough with
> ipv4-acl-type:
>
> 
>    
>      
>        sample-ipv4-acl
>        ipv4-acl-type
>        
>          
>            rule1
>            
>              
>                
>                  tcp
>
> As far as I can see, this snippet is invalid for the model, since the
> 'ipv4' container has
>
>                container ipv4 {
>                  when "derived-from(../../../../type, " +
>                       "'acl:ipv4-acl-type')";
>
> - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
> there shouldn't be any  element either, but that's another thing.)
>
> So, is it the case that the derived-from()s should actually be
> derived-from-or-self()s, or is the example wrong?

This has to do with the irreflexivity property of identity derivation,
which is, in my view, an unnecessary complication. It would be simpler
but sufficient to define derivation as a reflexive relation, and have
only one "derived-from()" XPath function.

Identities that are considered "abstract" should not be instantiated, and
then derived-from() and derived-from-or-self() give the same result.

Lada

>
> --Per Hedeland
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Mon Feb 26 06:05:24 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AA01126E64 for ; Mon, 26 Feb 2018 06:05:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c3RCB5vfGFrT for ; Mon, 26 Feb 2018 06:05:16 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id E7CB3120725 for ; Mon, 26 Feb 2018 06:05:15 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 923CC1820414; Mon, 26 Feb 2018 15:02:05 +0100 (CET)
Received: from localhost (nat-2.nic.cz [217.31.205.2]) by trail.lhotka.name (Postfix) with ESMTPSA id 1C9E318203F6; Mon, 26 Feb 2018 15:02:01 +0100 (CET)
From: Ladislav Lhotka 
To: Robert Wilton , Christian Hopps 
Cc: netmod@ietf.org
In-Reply-To: <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com>
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com>
Mail-Followup-To: Robert Wilton , Christian Hopps , netmod@ietf.org
Date: Mon, 26 Feb 2018 15:05:09 +0100
Message-ID: <87vaej4zje.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 14:05:23 -0000

Hi Rob,

Robert Wilton  writes:

> Hi Chris,
>
> I've got no desire or intent to try and slow down the NI and LNE drafts,=
=20
> or any that depend on them.=C2=A0 I actually agree that this is criticall=
y=20
> important that IETF gets modules standardized/finished so that everyone=20
> can use them.
>
> However, ...
>
> YLbis has quite a different structure to YL.=C2=A0 The main part of this=
=20
> change was to support NMDA, the other part of this change was to better=20
> support things like SM, or YANG packages.
>
> I don't think that there is a clean, backwards compatible, way to go=20
> from the YANG module in SM -08 to one that is going to work well with=20
> YLbis and other YLbis extensions/augmentations that seem to be coming

I don't think this is true - all YANG modules that work with -08 should
work with pre-09.

> down the line.=C2=A0 Given what we know now, I believe that the correct=20
> medium/long term structure for the SM YANG module, taking YLbis into=20
> account, is the one proposed in pre09, because it directly augments the=20
> YLbis structure, and hence any future augmentations to YLbis should=20
> automatically extend to SM mounted schema as well.
>
> I think that the likely future technical issues with the -08 module will =
be:
> - supporting NMDA in a clean consistent way
> - adding in support for SemVer
> - additional capability reporting as an augmentation to YANG library
>
> So, if -08 proceeds as is, then it seems to me like one of three things=20
> will need to happen:
> 1) Their will need to be a non backwards compatible update to the SM=20
> model that is the same/similar to pre09.
> 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for=20
> explicitly mounted schema.

An acceptable compromise for me would be to publish -08 and accept both
1 and 2 above. The benefits of doing so would be

- LNE/NI work won't be blocked

- some experience may be gained from the implementers that can improve
  the ultimate YLbis-based solution

- there will be more time to reconsider the design and presentation of
  the two concepts (inline and use-schema).

> 3) We accrue technical debt, implementations need to support two YL=20
> module structures, the one in SM and the one in YLbis, and future=20
> extensions need to augment both the SM structure and YLbis structure.

If we eventually do the right thing, then SM in the -08 form will be
abandoned along with the old YL.

Lada

>
> I don't like the idea of (2) or (3), but I don't know if others will=20
> find (1) acceptable.
>
> But I do agree that we are just going round in circles on this:
> - Using the pre09 structure is not acceptable to some folks
> - Publishing a draft with both -08 and pre09 structure is liked by even=20
> less folks.
>
> Perhaps publishing -08 is the only option.=C2=A0 My hope is that the WG w=
ill=20
> support somebody subsequently doing solution (1), otherwise it seems=20
> like a missed opportunity to get this right.
>
> Thanks,
> Rob
>
>
> On 24/02/2018 13:54, Christian Hopps wrote:
>> My position,
>>
>> It may be the case that there's even a better cleaner solution;=20
>> however, it's simply too late for major modifications to this work=20
>> that don't actually address functional failures.=C2=A0 The draft as=20
>> proposed works for the people who need to get work done.
>>
>> We have multiple pending RFCs - MISREF on this document. These RFCs=20
>> would have to be pulled from the RFC EDITOR queue, and reworked to be=20
>> compliant again, and this very well could lead to discovering issues=20
>> with your new proposal. Any new issues discovered in either the=20
>> pending RFCs *or* in the new solution would then need to be worked out=20
>> and fixed. Please recall that this actually occurred on the first=20
>> round (i.e., doing the examples led to discovering problems with the=20
>> drafts), so it's not unreasonable at all to assume this would happen=20
>> again.
>>
>> Look this just isn't a simple change your proposing. It involves a=20
>> large upheaval, killing the pending RFC status on multiple documents=20
>> that the industry is waiting on. Please see this.
>>
>> Thanks,
>> Chris.
>>
>>
>> Martin Bjorklund  writes:
>>
>>> Hi,
>>>
>>> Robert Wilton  wrote:
>>>> Hi Lou,
>>>>
>>>> I think that this solution is inferior to the model presented in
>>>> pre-09.
>>>
>>> I agree.=C2=A0 Servers that are NMDA-compliant, or implements YANG Libr=
ary
>>> bis will have to present schemas in two different structures,
>>> depending on where the schema is used, and clients will have to code
>>> for both.=C2=A0 With the solution in pre-09, there is just one structur=
e.
>>> A single structure also has other benefits (apart from being simpler),
>>> e.g., if we augment it with the meta data that has been discussed
>>> recently, we can augment a single structure.
>>
>>> /martin
>>>
>>>
>>>
>>>> I would prefer that we publish pre09 instead, potentially including
>>>> the -08 model in the appendix if that helps progress the document in a
>>>> more expedient fashion.
>>>>
>>>> Thanks,
>>>> Rob
>>>>
>>>>
>>>> On 22/02/2018 16:18, Lou Berger wrote:
>>>> > Hi,
>>>> >
>>>> > (I have a bunch of different roles WRT this work. This mail is being
>>>> > sent as an individual - as chair, I fully support the previous chair
>>>> > statements on this draft.)
>>>> >
>>>> > Chris and I have come up with a proposal on how to provide full NMDA
>>>> > as part the existing schema-mount module. Our motivation was to
>>>> > enable full NMDA support with *minimal* change to the model and
>>>> > disruption to the LC'ed work. The key NMDA limitation, with -08, that
>>>> > we are aiming to address is the ability to support different mounted
>>>> > schema in different datastores for non-inline mount points. (See more
>>>> > detailed description below if interested full nuances of limitations
>>>> > of -08)
>>>> >
>>>> > What we came up with was to simply add a (leaf)list to identify in
>>>> > which datastores a
>>>> > schema-mount schema is valid/present. This is somewhat similar to
>>>> > YL-bis schema/module-set. Specifically we're proposing (see below for
>>>> > full tree below):
>>>> >
>>>> >=C2=A0 +--ro schema* [name]
>>>> >=C2=A0 +--ro name string
>>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>>> >
>>>> > This approach has the advantages of supporting different mounted
>>>> > schema in different DSes, working with both NMDA and non-NMDA
>>>> > implementations, supporting all of the extensively discussed features
>>>> > of schema mount (including recursive mounts), and having minor/scoped
>>>> > impact on all dependent work. The main downside is that it isn't the
>>>> > most optimal/compact solution possible if we were to base this=20
>>>> work on
>>>> > YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from all
>>>> > perspectives, but it is what was agreed to as sufficient by those who
>>>> > contribute to the WG discussion.
>>>> >
>>>> > In short, we see this as a solution to addresses the raised last call
>>>> > issue with the minimal impact on -08 and dependent work -- which is
>>>> > what is appropriate given where we are in the process.
>>>> >
>>>> > So our/my question really is:
>>>> >
>>>> >=C2=A0 Is this a solution that you/all can live with?
>>>> >
>>>> > Note: optimization, design preference and perfect alignment with use
>>>> > or YL-bis are not part of our question as we both don't think that is
>>>> > the right question given where we are in the WG process.
>>>> >
>>>> > Lou (with ideas developed with Chris, and chair hat off)
>>>> >
>>>> > =3D=3D=3D=3D=3D=3D
>>>> > Details -- for those who want
>>>> > =3D=3D=3D=3D=3D=3D
>>>> > As background, my understanding/view is that the -08 version of the
>>>> > both NMDA and non-NMDA supporting implementations, but there are
>>>> > limitations in its NMDA applicability. Used with Yang Library,
>>>> > [rfc7895], only non-NMDA implementations can be supported. When used
>>>> > with the revised Yang Library defined in
>>>> > [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
>>>> > supported with certain limitations. Specifically, this document
>>>> > requires use of the now deprecated module-list grouping, and the same
>>>> > schema represented in schema list of the Schema Mount module MUST be
>>>> > used in all datastores. Inline type mount points, which don't use the
>>>> > schema list, can support different schema in different data stores
>>>> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>>> > YANG library under the inline mount point.
>>>> >
>>>> >=C2=A0 module: ietf-yang-schema-mount
>>>> >=C2=A0 +--ro schema-mounts
>>>> >=C2=A0 +--ro namespace* [prefix]
>>>> >=C2=A0 | +--ro prefix yang:yang-identifier
>>>> >=C2=A0 | +--ro uri? inet:uri
>>>> >=C2=A0 +--ro mount-point* [module name]
>>>> >=C2=A0 | +--ro module yang:yang-identifier
>>>> >=C2=A0 | +--ro name yang:yang-identifier
>>>> >=C2=A0 | +--ro config? boolean
>>>> >=C2=A0 | +--ro (schema-ref)?
>>>> >=C2=A0 | +--:(inline)
>>>> >=C2=A0 | | +--ro inline? empty
>>>> >=C2=A0 | +--:(use-schema)
>>>> >=C2=A0 | +--ro use-schema* [name]
>>>> >=C2=A0 | +--ro name
>>>> >=C2=A0 | | -> /schema-mounts/schema/name
>>>> >=C2=A0 | +--ro parent-reference* yang:xpath1.0
>>>> >=C2=A0 +--ro schema* [name]
>>>> >=C2=A0 +--ro name string
>>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>>> >=C2=A0=C2=A0 +--ro module* [name revision]
>>>> >=C2=A0 | +--ro name yang:yang-identifier
>>>> >=C2=A0 | +--ro revision union
>>>> >=C2=A0 | +--ro schema? inet:uri
>>>> >=C2=A0 | +--ro namespace inet:uri
>>>> >=C2=A0 | +--ro feature* yang:yang-identifier
>>>> >=C2=A0 | +--ro deviation* [name revision]
>>>> >=C2=A0 | | +--ro name yang:yang-identifier
>>>> >=C2=A0 | | +--ro revision union
>>>> >=C2=A0 | +--ro conformance-type enumeration
>>>> >=C2=A0 | +--ro submodule* [name revision]
>>>> >=C2=A0 | +--ro name yang:yang-identifier
>>>> >=C2=A0 | +--ro revision union
>>>> >=C2=A0 | +--ro schema? inet:uri
>>>> >=C2=A0 +--ro mount-point* [module name]
>>>> >=C2=A0 +--ro module yang:yang-identifier
>>>> >=C2=A0 +--ro name yang:yang-identifier
>>>> >=C2=A0 +--ro config? boolean
>>>> >=C2=A0 +--ro (schema-ref)?
>>>> >=C2=A0 +--:(inline)
>>>> >=C2=A0 | +--ro inline? empty
>>>> >=C2=A0 +--:(use-schema)
>>>> >=C2=A0 +--ro use-schema* [name]
>>>> >=C2=A0 +--ro name
>>>> >=C2=A0 | -> /schema-mounts/schema/name
>>>> >=C2=A0 +--ro parent-reference* yang:xpath1.0
>>>> >
>>>> > We would expect that the revised-datastores feature would be used
>>>> > (perhaps required) for any implementation that supports
>>>> > ietf-datastores
>>>> > and yl-bis.
>>>> >
>>>> >
>>>> >
>>>> > _______________________________________________
>>>> > netmod mailing list
>>>> > netmod@ietf.org
>>>> > https://www.ietf.org/mailman/listinfo/netmod
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>>
>> .
>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Mon Feb 26 06:16:52 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B155D120725 for ; Mon, 26 Feb 2018 06:16:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HmoppFKqw2Da for ; Mon, 26 Feb 2018 06:16:50 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4E305127599 for ; Mon, 26 Feb 2018 06:16:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=11986; q=dns/txt; s=iport; t=1519654609; x=1520864209; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=gOpFH2EJyZetPu4b4fSx7cEAlO24wqrJztACV4u4krU=; b=DEh2dMuZhbcpG+hI+ET6DkZR4gZXyUDFuXj6U/I6rf8a+HhW/kn3Rra3 jIKm2KoA8KdUVLkviOZHVXZ5yN1DKzbfQNehwU6Rzko10rASS0tzYGg7g tGtJVmWq98Dn1oW/lfesyJVJTTTOYYhbh0qxLdvpcUJNrg9Csgklr93mk E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CQAABnFpRa/xbLJq1SChkBAQEBAQEBA?= =?us-ascii?q?QEBAQEHAQEBAQGENXAog1SKInSOWTJ7G5YFFIICChgLhEFPAoMWGAECAQEBAQE?= =?us-ascii?q?BAmsohSMBAQEDAQEBIQQLAQU0AgIZCw4KAgIRFQICJzAGAQwGAgEBF4RtCBCqf?= =?us-ascii?q?oFtOoR0g3GCFAEBAQEBAQEDAQEBAQEBAQEBAQEYBYEPiAqBZimBdlg2gy4BAYE?= =?us-ascii?q?sGgsBAR4/gk6CZQWRLpAzCZQgggaFZoM/hzWJZ4RqhCsrgk6BLx44gVEzGggbF?= =?us-ascii?q?TqCQ4RaQDeKHoI5AQEB?=
X-IronPort-AV: E=Sophos;i="5.47,396,1515456000";  d="scan'208";a="2251020"
Received: from aer-iport-nat.cisco.com (HELO aer-core-3.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 14:16:29 +0000
Received: from [10.63.23.77] (dhcp-ensft1-uk-vla370-10-63-23-77.cisco.com [10.63.23.77]) by aer-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id w1QEGTEm025734; Mon, 26 Feb 2018 14:16:29 GMT
To: Christian Hopps , netmod@ietf.org
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87vaej4zje.fsf@nic.cz>
From: Robert Wilton 
Message-ID: <81c80358-75fa-d7a6-3ead-c1c1e6633e22@cisco.com>
Date: Mon, 26 Feb 2018 14:16:29 +0000
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <87vaej4zje.fsf@nic.cz>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 14:16:52 -0000

Hi Lada,


On 26/02/2018 14:05, Ladislav Lhotka wrote:
> Hi Rob,
>
> Robert Wilton  writes:
>
>> Hi Chris,
>>
>> I've got no desire or intent to try and slow down the NI and LNE drafts,
>> or any that depend on them.  I actually agree that this is critically
>> important that IETF gets modules standardized/finished so that everyone
>> can use them.
>>
>> However, ...
>>
>> YLbis has quite a different structure to YL.  The main part of this
>> change was to support NMDA, the other part of this change was to better
>> support things like SM, or YANG packages.
>>
>> I don't think that there is a clean, backwards compatible, way to go
>> from the YANG module in SM -08 to one that is going to work well with
>> YLbis and other YLbis extensions/augmentations that seem to be coming
> I don't think this is true - all YANG modules that work with -08 should
> work with pre-09.
Sorry, I think that my point wasn't clear:

I don't think that you can go from the ietf-yang-schema-mount YANG 
module defined in SM -08 to something like the ietf-yang-schema-mount 
YANG module defined in pre09 in a backwards compatible way.  I.e. just 
following the "Updating a Module" in RFC 7950 chapter 11.

In terms of the actual modules that are being mounted, I agree, all 
modules will work in both.


>
>> down the line.  Given what we know now, I believe that the correct
>> medium/long term structure for the SM YANG module, taking YLbis into
>> account, is the one proposed in pre09, because it directly augments the
>> YLbis structure, and hence any future augmentations to YLbis should
>> automatically extend to SM mounted schema as well.
>>
>> I think that the likely future technical issues with the -08 module will be:
>> - supporting NMDA in a clean consistent way
>> - adding in support for SemVer
>> - additional capability reporting as an augmentation to YANG library
>>
>> So, if -08 proceeds as is, then it seems to me like one of three things
>> will need to happen:
>> 1) Their will need to be a non backwards compatible update to the SM
>> model that is the same/similar to pre09.
>> 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
>> explicitly mounted schema.
> An acceptable compromise for me would be to publish -08 and accept both
> 1 and 2 above. The benefits of doing so would be
>
> - LNE/NI work won't be blocked
>
> - some experience may be gained from the implementers that can improve
>    the ultimate YLbis-based solution
>
> - there will be more time to reconsider the design and presentation of
>    the two concepts (inline and use-schema).
>
>> 3) We accrue technical debt, implementations need to support two YL
>> module structures, the one in SM and the one in YLbis, and future
>> extensions need to augment both the SM structure and YLbis structure.
> If we eventually do the right thing, then SM in the -08 form will be
> abandoned along with the old YL.
>
> Lada
Thanks,
Rob


>
>> I don't like the idea of (2) or (3), but I don't know if others will
>> find (1) acceptable.
>>
>> But I do agree that we are just going round in circles on this:
>> - Using the pre09 structure is not acceptable to some folks
>> - Publishing a draft with both -08 and pre09 structure is liked by even
>> less folks.
>>
>> Perhaps publishing -08 is the only option.  My hope is that the WG will
>> support somebody subsequently doing solution (1), otherwise it seems
>> like a missed opportunity to get this right.
>>
>> Thanks,
>> Rob
>>
>>
>> On 24/02/2018 13:54, Christian Hopps wrote:
>>> My position,
>>>
>>> It may be the case that there's even a better cleaner solution;
>>> however, it's simply too late for major modifications to this work
>>> that don't actually address functional failures.  The draft as
>>> proposed works for the people who need to get work done.
>>>
>>> We have multiple pending RFCs - MISREF on this document. These RFCs
>>> would have to be pulled from the RFC EDITOR queue, and reworked to be
>>> compliant again, and this very well could lead to discovering issues
>>> with your new proposal. Any new issues discovered in either the
>>> pending RFCs *or* in the new solution would then need to be worked out
>>> and fixed. Please recall that this actually occurred on the first
>>> round (i.e., doing the examples led to discovering problems with the
>>> drafts), so it's not unreasonable at all to assume this would happen
>>> again.
>>>
>>> Look this just isn't a simple change your proposing. It involves a
>>> large upheaval, killing the pending RFC status on multiple documents
>>> that the industry is waiting on. Please see this.
>>>
>>> Thanks,
>>> Chris.
>>>
>>>
>>> Martin Bjorklund  writes:
>>>
>>>> Hi,
>>>>
>>>> Robert Wilton  wrote:
>>>>> Hi Lou,
>>>>>
>>>>> I think that this solution is inferior to the model presented in
>>>>> pre-09.
>>>> I agree.  Servers that are NMDA-compliant, or implements YANG Library
>>>> bis will have to present schemas in two different structures,
>>>> depending on where the schema is used, and clients will have to code
>>>> for both.  With the solution in pre-09, there is just one structure.
>>>> A single structure also has other benefits (apart from being simpler),
>>>> e.g., if we augment it with the meta data that has been discussed
>>>> recently, we can augment a single structure.
>>>> /martin
>>>>
>>>>
>>>>
>>>>> I would prefer that we publish pre09 instead, potentially including
>>>>> the -08 model in the appendix if that helps progress the document in a
>>>>> more expedient fashion.
>>>>>
>>>>> Thanks,
>>>>> Rob
>>>>>
>>>>>
>>>>> On 22/02/2018 16:18, Lou Berger wrote:
>>>>>> Hi,
>>>>>>
>>>>>> (I have a bunch of different roles WRT this work. This mail is being
>>>>>> sent as an individual - as chair, I fully support the previous chair
>>>>>> statements on this draft.)
>>>>>>
>>>>>> Chris and I have come up with a proposal on how to provide full NMDA
>>>>>> as part the existing schema-mount module. Our motivation was to
>>>>>> enable full NMDA support with *minimal* change to the model and
>>>>>> disruption to the LC'ed work. The key NMDA limitation, with -08, that
>>>>>> we are aiming to address is the ability to support different mounted
>>>>>> schema in different datastores for non-inline mount points. (See more
>>>>>> detailed description below if interested full nuances of limitations
>>>>>> of -08)
>>>>>>
>>>>>> What we came up with was to simply add a (leaf)list to identify in
>>>>>> which datastores a
>>>>>> schema-mount schema is valid/present. This is somewhat similar to
>>>>>> YL-bis schema/module-set. Specifically we're proposing (see below for
>>>>>> full tree below):
>>>>>>
>>>>>>    +--ro schema* [name]
>>>>>>    +--ro name string
>>>>>> ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>>>>>
>>>>>> This approach has the advantages of supporting different mounted
>>>>>> schema in different DSes, working with both NMDA and non-NMDA
>>>>>> implementations, supporting all of the extensively discussed features
>>>>>> of schema mount (including recursive mounts), and having minor/scoped
>>>>>> impact on all dependent work. The main downside is that it isn't the
>>>>>> most optimal/compact solution possible if we were to base this
>>>>> work on
>>>>>> YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from all
>>>>>> perspectives, but it is what was agreed to as sufficient by those who
>>>>>> contribute to the WG discussion.
>>>>>>
>>>>>> In short, we see this as a solution to addresses the raised last call
>>>>>> issue with the minimal impact on -08 and dependent work -- which is
>>>>>> what is appropriate given where we are in the process.
>>>>>>
>>>>>> So our/my question really is:
>>>>>>
>>>>>>    Is this a solution that you/all can live with?
>>>>>>
>>>>>> Note: optimization, design preference and perfect alignment with use
>>>>>> or YL-bis are not part of our question as we both don't think that is
>>>>>> the right question given where we are in the WG process.
>>>>>>
>>>>>> Lou (with ideas developed with Chris, and chair hat off)
>>>>>>
>>>>>> ======
>>>>>> Details -- for those who want
>>>>>> ======
>>>>>> As background, my understanding/view is that the -08 version of the
>>>>>> both NMDA and non-NMDA supporting implementations, but there are
>>>>>> limitations in its NMDA applicability. Used with Yang Library,
>>>>>> [rfc7895], only non-NMDA implementations can be supported. When used
>>>>>> with the revised Yang Library defined in
>>>>>> [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
>>>>>> supported with certain limitations. Specifically, this document
>>>>>> requires use of the now deprecated module-list grouping, and the same
>>>>>> schema represented in schema list of the Schema Mount module MUST be
>>>>>> used in all datastores. Inline type mount points, which don't use the
>>>>>> schema list, can support different schema in different data stores
>>>>>> not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>>>>> YANG library under the inline mount point.
>>>>>>
>>>>>>    module: ietf-yang-schema-mount
>>>>>>    +--ro schema-mounts
>>>>>>    +--ro namespace* [prefix]
>>>>>>    | +--ro prefix yang:yang-identifier
>>>>>>    | +--ro uri? inet:uri
>>>>>>    +--ro mount-point* [module name]
>>>>>>    | +--ro module yang:yang-identifier
>>>>>>    | +--ro name yang:yang-identifier
>>>>>>    | +--ro config? boolean
>>>>>>    | +--ro (schema-ref)?
>>>>>>    | +--:(inline)
>>>>>>    | | +--ro inline? empty
>>>>>>    | +--:(use-schema)
>>>>>>    | +--ro use-schema* [name]
>>>>>>    | +--ro name
>>>>>>    | | -> /schema-mounts/schema/name
>>>>>>    | +--ro parent-reference* yang:xpath1.0
>>>>>>    +--ro schema* [name]
>>>>>>    +--ro name string
>>>>>> ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>>>>>     +--ro module* [name revision]
>>>>>>    | +--ro name yang:yang-identifier
>>>>>>    | +--ro revision union
>>>>>>    | +--ro schema? inet:uri
>>>>>>    | +--ro namespace inet:uri
>>>>>>    | +--ro feature* yang:yang-identifier
>>>>>>    | +--ro deviation* [name revision]
>>>>>>    | | +--ro name yang:yang-identifier
>>>>>>    | | +--ro revision union
>>>>>>    | +--ro conformance-type enumeration
>>>>>>    | +--ro submodule* [name revision]
>>>>>>    | +--ro name yang:yang-identifier
>>>>>>    | +--ro revision union
>>>>>>    | +--ro schema? inet:uri
>>>>>>    +--ro mount-point* [module name]
>>>>>>    +--ro module yang:yang-identifier
>>>>>>    +--ro name yang:yang-identifier
>>>>>>    +--ro config? boolean
>>>>>>    +--ro (schema-ref)?
>>>>>>    +--:(inline)
>>>>>>    | +--ro inline? empty
>>>>>>    +--:(use-schema)
>>>>>>    +--ro use-schema* [name]
>>>>>>    +--ro name
>>>>>>    | -> /schema-mounts/schema/name
>>>>>>    +--ro parent-reference* yang:xpath1.0
>>>>>>
>>>>>> We would expect that the revised-datastores feature would be used
>>>>>> (perhaps required) for any implementation that supports
>>>>>> ietf-datastores
>>>>>> and yl-bis.
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> .
>>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod


From nobody Mon Feb 26 07:03:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 641BC126C22 for ; Mon, 26 Feb 2018 07:03:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.01
X-Spam-Level: 
X-Spam-Status: No, score=-7.01 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8ULT7_0SFqsz for ; Mon, 26 Feb 2018 07:03:31 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60196124B17 for ; Mon, 26 Feb 2018 07:03:30 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:857:64ff:fe40:80fe]) by mail.nic.cz (Postfix) with ESMTPSA id B2C896093E for ; Mon, 26 Feb 2018 16:03:28 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1519657408; bh=VFKc6UAXqRrIT7RSe8+F1TyWhg9RRmp4yTkOwB+aNP0=; h=From:To:Date; b=c+17n6casZcCPusVUdLsihRpMaA4tXsukRlmNq4/6akppEjoHwtw93+bxTCH5lcKk Nk9SfZHUpQoTkxzPaG1vbwVRc7JRcLxC48/tX621qy2ew4ahOVXYC5EsJgAkAs2ryN ezKrt5YTka8YjKQPySMOUEJVSaWG3mpaQijNFxEY=
Message-ID: <1519657408.21103.35.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Mon, 26 Feb 2018 16:03:28 +0100
In-Reply-To: <81c80358-75fa-d7a6-3ead-c1c1e6633e22@cisco.com>
References: <090b951e-8627-183b-6fe1-ae46da5a90bc@labn.net> <195c3186-25ce-3019-1eda-34096fbc8de3@cisco.com> <20180223.103628.1174590223555999274.mbj@tail-f.com> <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87vaej4zje.fsf@nic.cz> <81c80358-75fa-d7a6-3ead-c1c1e6633e22@cisco.com>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 15:03:34 -0000

On Mon, 2018-02-26 at 14:16 +0000, Robert Wilton wrote:
> Hi Lada,
> 
> 
> On 26/02/2018 14:05, Ladislav Lhotka wrote:
> > Hi Rob,
> > 
> > Robert Wilton  writes:
> > 
> > > Hi Chris,
> > > 
> > > I've got no desire or intent to try and slow down the NI and LNE drafts,
> > > or any that depend on them.  I actually agree that this is critically
> > > important that IETF gets modules standardized/finished so that everyone
> > > can use them.
> > > 
> > > However, ...
> > > 
> > > YLbis has quite a different structure to YL.  The main part of this
> > > change was to support NMDA, the other part of this change was to better
> > > support things like SM, or YANG packages.
> > > 
> > > I don't think that there is a clean, backwards compatible, way to go
> > > from the YANG module in SM -08 to one that is going to work well with
> > > YLbis and other YLbis extensions/augmentations that seem to be coming
> > 
> > I don't think this is true - all YANG modules that work with -08 should
> > work with pre-09.
> 
> Sorry, I think that my point wasn't clear:
> 
> I don't think that you can go from the ietf-yang-schema-mount YANG 
> module defined in SM -08 to something like the ietf-yang-schema-mount 
> YANG module defined in pre09 in a backwards compatible way.  I.e. just 
> following the "Updating a Module" in RFC 7950 chapter 11.

OK, right, but in this case it is necessary to start from a clean slate - old
clients supporting only RFC 7895 cannot work with YLbis, even if the update
rules are followed.

Lada  

> 
> In terms of the actual modules that are being mounted, I agree, all 
> modules will work in both.
> 
> 
> > 
> > > down the line.  Given what we know now, I believe that the correct
> > > medium/long term structure for the SM YANG module, taking YLbis into
> > > account, is the one proposed in pre09, because it directly augments the
> > > YLbis structure, and hence any future augmentations to YLbis should
> > > automatically extend to SM mounted schema as well.
> > > 
> > > I think that the likely future technical issues with the -08 module will
> > > be:
> > > - supporting NMDA in a clean consistent way
> > > - adding in support for SemVer
> > > - additional capability reporting as an augmentation to YANG library
> > > 
> > > So, if -08 proceeds as is, then it seems to me like one of three things
> > > will need to happen:
> > > 1) Their will need to be a non backwards compatible update to the SM
> > > model that is the same/similar to pre09.
> > > 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
> > > explicitly mounted schema.
> > 
> > An acceptable compromise for me would be to publish -08 and accept both
> > 1 and 2 above. The benefits of doing so would be
> > 
> > - LNE/NI work won't be blocked
> > 
> > - some experience may be gained from the implementers that can improve
> >    the ultimate YLbis-based solution
> > 
> > - there will be more time to reconsider the design and presentation of
> >    the two concepts (inline and use-schema).
> > 
> > > 3) We accrue technical debt, implementations need to support two YL
> > > module structures, the one in SM and the one in YLbis, and future
> > > extensions need to augment both the SM structure and YLbis structure.
> > 
> > If we eventually do the right thing, then SM in the -08 form will be
> > abandoned along with the old YL.
> > 
> > Lada
> 
> Thanks,
> Rob
> 
> 
> > 
> > > I don't like the idea of (2) or (3), but I don't know if others will
> > > find (1) acceptable.
> > > 
> > > But I do agree that we are just going round in circles on this:
> > > - Using the pre09 structure is not acceptable to some folks
> > > - Publishing a draft with both -08 and pre09 structure is liked by even
> > > less folks.
> > > 
> > > Perhaps publishing -08 is the only option.  My hope is that the WG will
> > > support somebody subsequently doing solution (1), otherwise it seems
> > > like a missed opportunity to get this right.
> > > 
> > > Thanks,
> > > Rob
> > > 
> > > 
> > > On 24/02/2018 13:54, Christian Hopps wrote:
> > > > My position,
> > > > 
> > > > It may be the case that there's even a better cleaner solution;
> > > > however, it's simply too late for major modifications to this work
> > > > that don't actually address functional failures.  The draft as
> > > > proposed works for the people who need to get work done.
> > > > 
> > > > We have multiple pending RFCs - MISREF on this document. These RFCs
> > > > would have to be pulled from the RFC EDITOR queue, and reworked to be
> > > > compliant again, and this very well could lead to discovering issues
> > > > with your new proposal. Any new issues discovered in either the
> > > > pending RFCs *or* in the new solution would then need to be worked out
> > > > and fixed. Please recall that this actually occurred on the first
> > > > round (i.e., doing the examples led to discovering problems with the
> > > > drafts), so it's not unreasonable at all to assume this would happen
> > > > again.
> > > > 
> > > > Look this just isn't a simple change your proposing. It involves a
> > > > large upheaval, killing the pending RFC status on multiple documents
> > > > that the industry is waiting on. Please see this.
> > > > 
> > > > Thanks,
> > > > Chris.
> > > > 
> > > > 
> > > > Martin Bjorklund  writes:
> > > > 
> > > > > Hi,
> > > > > 
> > > > > Robert Wilton  wrote:
> > > > > > Hi Lou,
> > > > > > 
> > > > > > I think that this solution is inferior to the model presented in
> > > > > > pre-09.
> > > > > 
> > > > > I agree.  Servers that are NMDA-compliant, or implements YANG Library
> > > > > bis will have to present schemas in two different structures,
> > > > > depending on where the schema is used, and clients will have to code
> > > > > for both.  With the solution in pre-09, there is just one structure.
> > > > > A single structure also has other benefits (apart from being simpler),
> > > > > e.g., if we augment it with the meta data that has been discussed
> > > > > recently, we can augment a single structure.
> > > > > /martin
> > > > > 
> > > > > 
> > > > > 
> > > > > > I would prefer that we publish pre09 instead, potentially including
> > > > > > the -08 model in the appendix if that helps progress the document in
> > > > > > a
> > > > > > more expedient fashion.
> > > > > > 
> > > > > > Thanks,
> > > > > > Rob
> > > > > > 
> > > > > > 
> > > > > > On 22/02/2018 16:18, Lou Berger wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > (I have a bunch of different roles WRT this work. This mail is
> > > > > > > being
> > > > > > > sent as an individual - as chair, I fully support the previous
> > > > > > > chair
> > > > > > > statements on this draft.)
> > > > > > > 
> > > > > > > Chris and I have come up with a proposal on how to provide full
> > > > > > > NMDA
> > > > > > > as part the existing schema-mount module. Our motivation was to
> > > > > > > enable full NMDA support with *minimal* change to the model and
> > > > > > > disruption to the LC'ed work. The key NMDA limitation, with -08,
> > > > > > > that
> > > > > > > we are aiming to address is the ability to support different
> > > > > > > mounted
> > > > > > > schema in different datastores for non-inline mount points. (See
> > > > > > > more
> > > > > > > detailed description below if interested full nuances of
> > > > > > > limitations
> > > > > > > of -08)
> > > > > > > 
> > > > > > > What we came up with was to simply add a (leaf)list to identify in
> > > > > > > which datastores a
> > > > > > > schema-mount schema is valid/present. This is somewhat similar to
> > > > > > > YL-bis schema/module-set. Specifically we're proposing (see below
> > > > > > > for
> > > > > > > full tree below):
> > > > > > > 
> > > > > > >    +--ro schema* [name]
> > > > > > >    +--ro name string
> > > > > > > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
> > > > > > > 
> > > > > > > This approach has the advantages of supporting different mounted
> > > > > > > schema in different DSes, working with both NMDA and non-NMDA
> > > > > > > implementations, supporting all of the extensively discussed
> > > > > > > features
> > > > > > > of schema mount (including recursive mounts), and having
> > > > > > > minor/scoped
> > > > > > > impact on all dependent work. The main downside is that it isn't
> > > > > > > the
> > > > > > > most optimal/compact solution possible if we were to base this
> > > > > > 
> > > > > > work on
> > > > > > > YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from
> > > > > > > all
> > > > > > > perspectives, but it is what was agreed to as sufficient by those
> > > > > > > who
> > > > > > > contribute to the WG discussion.
> > > > > > > 
> > > > > > > In short, we see this as a solution to addresses the raised last
> > > > > > > call
> > > > > > > issue with the minimal impact on -08 and dependent work -- which
> > > > > > > is
> > > > > > > what is appropriate given where we are in the process.
> > > > > > > 
> > > > > > > So our/my question really is:
> > > > > > > 
> > > > > > >    Is this a solution that you/all can live with?
> > > > > > > 
> > > > > > > Note: optimization, design preference and perfect alignment with
> > > > > > > use
> > > > > > > or YL-bis are not part of our question as we both don't think that
> > > > > > > is
> > > > > > > the right question given where we are in the WG process.
> > > > > > > 
> > > > > > > Lou (with ideas developed with Chris, and chair hat off)
> > > > > > > 
> > > > > > > ======
> > > > > > > Details -- for those who want
> > > > > > > ======
> > > > > > > As background, my understanding/view is that the -08 version of
> > > > > > > the
> > > > > > > both NMDA and non-NMDA supporting implementations, but there are
> > > > > > > limitations in its NMDA applicability. Used with Yang Library,
> > > > > > > [rfc7895], only non-NMDA implementations can be supported. When
> > > > > > > used
> > > > > > > with the revised Yang Library defined in
> > > > > > > [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
> > > > > > > supported with certain limitations. Specifically, this document
> > > > > > > requires use of the now deprecated module-list grouping, and the
> > > > > > > same
> > > > > > > schema represented in schema list of the Schema Mount module MUST
> > > > > > > be
> > > > > > > used in all datastores. Inline type mount points, which don't use
> > > > > > > the
> > > > > > > schema list, can support different schema in different data stores
> > > > > > > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
> > > > > > > YANG library under the inline mount point.
> > > > > > > 
> > > > > > >    module: ietf-yang-schema-mount
> > > > > > >    +--ro schema-mounts
> > > > > > >    +--ro namespace* [prefix]
> > > > > > >    | +--ro prefix yang:yang-identifier
> > > > > > >    | +--ro uri? inet:uri
> > > > > > >    +--ro mount-point* [module name]
> > > > > > >    | +--ro module yang:yang-identifier
> > > > > > >    | +--ro name yang:yang-identifier
> > > > > > >    | +--ro config? boolean
> > > > > > >    | +--ro (schema-ref)?
> > > > > > >    | +--:(inline)
> > > > > > >    | | +--ro inline? empty
> > > > > > >    | +--:(use-schema)
> > > > > > >    | +--ro use-schema* [name]
> > > > > > >    | +--ro name
> > > > > > >    | | -> /schema-mounts/schema/name
> > > > > > >    | +--ro parent-reference* yang:xpath1.0
> > > > > > >    +--ro schema* [name]
> > > > > > >    +--ro name string
> > > > > > > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
> > > > > > >     +--ro module* [name revision]
> > > > > > >    | +--ro name yang:yang-identifier
> > > > > > >    | +--ro revision union
> > > > > > >    | +--ro schema? inet:uri
> > > > > > >    | +--ro namespace inet:uri
> > > > > > >    | +--ro feature* yang:yang-identifier
> > > > > > >    | +--ro deviation* [name revision]
> > > > > > >    | | +--ro name yang:yang-identifier
> > > > > > >    | | +--ro revision union
> > > > > > >    | +--ro conformance-type enumeration
> > > > > > >    | +--ro submodule* [name revision]
> > > > > > >    | +--ro name yang:yang-identifier
> > > > > > >    | +--ro revision union
> > > > > > >    | +--ro schema? inet:uri
> > > > > > >    +--ro mount-point* [module name]
> > > > > > >    +--ro module yang:yang-identifier
> > > > > > >    +--ro name yang:yang-identifier
> > > > > > >    +--ro config? boolean
> > > > > > >    +--ro (schema-ref)?
> > > > > > >    +--:(inline)
> > > > > > >    | +--ro inline? empty
> > > > > > >    +--:(use-schema)
> > > > > > >    +--ro use-schema* [name]
> > > > > > >    +--ro name
> > > > > > >    | -> /schema-mounts/schema/name
> > > > > > >    +--ro parent-reference* yang:xpath1.0
> > > > > > > 
> > > > > > > We would expect that the revised-datastores feature would be used
> > > > > > > (perhaps required) for any implementation that supports
> > > > > > > ietf-datastores
> > > > > > > and yl-bis.
> > > > > > > 
> > > > > > > 
> > > > > > > 
> > > > > > > _______________________________________________
> > > > > > > netmod mailing list
> > > > > > > netmod@ietf.org
> > > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > > 
> > > > > > _______________________________________________
> > > > > > netmod mailing list
> > > > > > netmod@ietf.org
> > > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > > 
> > > > > _______________________________________________
> > > > > netmod mailing list
> > > > > netmod@ietf.org
> > > > > https://www.ietf.org/mailman/listinfo/netmod
> > > > 
> > > > .
> > > > 
> > > 
> > > _______________________________________________
> > > netmod mailing list
> > > netmod@ietf.org
> > > https://www.ietf.org/mailman/listinfo/netmod
> 
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Mon Feb 26 07:09:28 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66438127136 for ; Mon, 26 Feb 2018 07:09:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rC0JKAW0hkO6 for ; Mon, 26 Feb 2018 07:09:23 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3A1E112D7EF for ; Mon, 26 Feb 2018 07:09:23 -0800 (PST)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id 1B0001AE02BE; Mon, 26 Feb 2018 16:09:22 +0100 (CET)
Date: Mon, 26 Feb 2018 16:09:21 +0100 (CET)
Message-Id: <20180226.160921.622063322182936097.mbj@tail-f.com>
To: chopps@chopps.org
Cc: rwilton@cisco.com, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <87lgfg9ded.fsf@chopps.org>
References: <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87lgfg9ded.fsf@chopps.org>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 15:09:26 -0000

Hi,

Christian Hopps  wrote:
> 
> Hi Rob,
> 
> You do realize that no-one trying to actually deploy and run networks
> cares about live-discovery of different schema per datastore for the
> same mount point right? Like 99.999% of the clients know where things
> are supposed to reside and expect them to be there.

But then why advertise anything at all?   We can do a *much* simpler
solution by just having the mountpoint extension, and nothing else.
Clients will know what to find anyway.

My experience, which may differ from yours, is that correct knowledge
about the devices' datamodels and revisions is crucial for correct
implementation of automation of network services.  The application
programmer can program the intent for some set of data models, and
then the orchestrator can automatically decide what to do for a given
device depending on which data models it advertises.



/martin




At most (although
> still not common) they may want to know what modules are supported
> under a mount point. What your talking about is a severe edge case
> that apparently has achieved extreme importance in a very small group
> of people's views.
> 
> Thanks,
> Chris.
> 
> Robert Wilton  writes:
> 
> > Hi Chris,
> >
> > I've got no desire or intent to try and slow down the NI and LNE
> > drafts, or any
> > that depend on them. I actually agree that this is critically
> > important that
> > IETF gets modules standardized/finished so that everyone can use them.
> >
> > However, ...
> >
> > YLbis has quite a different structure to YL. The main part of this
> > change was
> > to support NMDA, the other part of this change was to better support
> > things like
> > SM, or YANG packages.
> >
> > I don't think that there is a clean, backwards compatible, way to go
> > from the
> > YANG module in SM -08 to one that is going to work well with YLbis and
> > other
> > YLbis extensions/augmentations that seem to be coming down the
> > line. Given what
> > we know now, I believe that the correct medium/long term structure for
> > the SM
> > YANG module, taking YLbis into account, is the one proposed in pre09,
> > because it
> > directly augments the YLbis structure, and hence any future
> > augmentations to
> > YLbis should automatically extend to SM mounted schema as well.
> >
> > I think that the likely future technical issues with the -08 module
> > will be:
> > - supporting NMDA in a clean consistent way
> > - adding in support for SemVer
> > - additional capability reporting as an augmentation to YANG library
> >
> > So, if -08 proceeds as is, then it seems to me like one of three
> > things will
> > need to happen:
> > 1) Their will need to be a non backwards compatible update to the SM
> > model that
> > is the same/similar to pre09.
> > 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
> > explicitly
> > mounted schema.
> > 3) We accrue technical debt, implementations need to support two YL
> > module
> > structures, the one in SM and the one in YLbis, and future extensions
> > need to
> > augment both the SM structure and YLbis structure.
> >
> > I don't like the idea of (2) or (3), but I don't know if others will
> > find (1)
> > acceptable.
> >
> > But I do agree that we are just going round in circles on this:
> > - Using the pre09 structure is not acceptable to some folks
> > - Publishing a draft with both -08 and pre09 structure is liked by even
> > - less
> > folks.
> >
> > Perhaps publishing -08 is the only option. My hope is that the WG will
> > support
> > somebody subsequently doing solution (1), otherwise it seems like a
> > missed
> > opportunity to get this right.
> >
> > Thanks,
> > Rob
> >
> >
> > On 24/02/2018 13:54, Christian Hopps wrote:
> >> My position,
> >>
> >> It may be the case that there's even a better cleaner solution;
> >> however, it's
> >> simply too late for major modifications to this work that don't
> >> actually
> >> address functional failures. The draft as proposed works for the
> >> people who
> >> need to get work done.
> >>
> >> We have multiple pending RFCs - MISREF on this document. These RFCs
> >> would have
> >> to be pulled from the RFC EDITOR queue, and reworked to be compliant
> >> again,
> >> and this very well could lead to discovering issues with your new
> >> proposal.
> >> Any new issues discovered in either the pending RFCs *or* in the new
> >> solution
> >> would then need to be worked out and fixed. Please recall that this
> >> actually
> >> occurred on the first round (i.e., doing the examples led to
> >> discovering
> >> problems with the drafts), so it's not unreasonable at all to assume
> >> this
> >> would happen again.
> >>
> >> Look this just isn't a simple change your proposing. It involves a
> >> large
> >> upheaval, killing the pending RFC status on multiple documents that
> >> the
> >> industry is waiting on. Please see this.
> >>
> >> Thanks,
> >> Chris.
> >>
> >>
> >> Martin Bjorklund  writes:
> >>
> >>> Hi,
> >>>
> >>> Robert Wilton  wrote:
> >>>> Hi Lou,
> >>>>
> >>>> I think that this solution is inferior to the model presented in
> >>>> pre-09.
> >>>
> >>> I agree. Servers that are NMDA-compliant, or implements YANG Library
> >>> bis will have to present schemas in two different structures,
> >>> depending on where the schema is used, and clients will have to code
> >>> for both. With the solution in pre-09, there is just one structure.
> >>> A single structure also has other benefits (apart from being simpler),
> >>> e.g., if we augment it with the meta data that has been discussed
> >>> recently, we can augment a single structure.
> >>
> >>> /martin
> >>>
> >>>
> >>>
> >>>> I would prefer that we publish pre09 instead, potentially including
> >>>> the -08 model in the appendix if that helps progress the document in a
> >>>> more expedient fashion.
> >>>>
> >>>> Thanks,
> >>>> Rob
> >>>>
> >>>>
> >>>> On 22/02/2018 16:18, Lou Berger wrote:
> >>>> > Hi,
> >>>> >
> >>>> > (I have a bunch of different roles WRT this work. This mail is being
> >>>> > sent as an individual - as chair, I fully support the previous chair
> >>>> > statements on this draft.)
> >>>> >
> >>>> > Chris and I have come up with a proposal on how to provide full NMDA
> >>>> > as part the existing schema-mount module. Our motivation was to
> >>>> > enable full NMDA support with *minimal* change to the model and
> >>>> > disruption to the LC'ed work. The key NMDA limitation, with -08, that
> >>>> > we are aiming to address is the ability to support different mounted
> >>>> > schema in different datastores for non-inline mount points. (See more
> >>>> > detailed description below if interested full nuances of limitations
> >>>> > of -08)
> >>>> >
> >>>> > What we came up with was to simply add a (leaf)list to identify in
> >>>> > which datastores a
> >>>> > schema-mount schema is valid/present. This is somewhat similar to
> >>>> > YL-bis schema/module-set. Specifically we're proposing (see below for
> >>>> > full tree below):
> >>>> >
> >>>> > +--ro schema* [name]
> >>>> > +--ro name string
> >>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
> >>>> >
> >>>> > This approach has the advantages of supporting different mounted
> >>>> > schema in different DSes, working with both NMDA and non-NMDA
> >>>> > implementations, supporting all of the extensively discussed features
> >>>> > of schema mount (including recursive mounts), and having minor/scoped
> >>>> > impact on all dependent work. The main downside is that it isn't the
> >>>> > most optimal/compact solution possible if we were to base this work on
> >>>> > YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from all
> >>>> > perspectives, but it is what was agreed to as sufficient by those who
> >>>> > contribute to the WG discussion.
> >>>> >
> >>>> > In short, we see this as a solution to addresses the raised last call
> >>>> > issue with the minimal impact on -08 and dependent work -- which is
> >>>> > what is appropriate given where we are in the process.
> >>>> >
> >>>> > So our/my question really is:
> >>>> >
> >>>> > Is this a solution that you/all can live with?
> >>>> >
> >>>> > Note: optimization, design preference and perfect alignment with use
> >>>> > or YL-bis are not part of our question as we both don't think that is
> >>>> > the right question given where we are in the WG process.
> >>>> >
> >>>> > Lou (with ideas developed with Chris, and chair hat off)
> >>>> >
> >>>> > ======
> >>>> > Details -- for those who want
> >>>> > ======
> >>>> > As background, my understanding/view is that the -08 version of the
> >>>> > both NMDA and non-NMDA supporting implementations, but there are
> >>>> > limitations in its NMDA applicability. Used with Yang Library,
> >>>> > [rfc7895], only non-NMDA implementations can be supported. When used
> >>>> > with the revised Yang Library defined in
> >>>> > [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
> >>>> > supported with certain limitations. Specifically, this document
> >>>> > requires use of the now deprecated module-list grouping, and the same
> >>>> > schema represented in schema list of the Schema Mount module MUST be
> >>>> > used in all datastores. Inline type mount points, which don't use the
> >>>> > schema list, can support different schema in different data stores
> >>>> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
> >>>> > YANG library under the inline mount point.
> >>>> >
> >>>> > module: ietf-yang-schema-mount
> >>>> > +--ro schema-mounts
> >>>> > +--ro namespace* [prefix]
> >>>> > | +--ro prefix yang:yang-identifier
> >>>> > | +--ro uri? inet:uri
> >>>> > +--ro mount-point* [module name]
> >>>> > | +--ro module yang:yang-identifier
> >>>> > | +--ro name yang:yang-identifier
> >>>> > | +--ro config? boolean
> >>>> > | +--ro (schema-ref)?
> >>>> > | +--:(inline)
> >>>> > | | +--ro inline? empty
> >>>> > | +--:(use-schema)
> >>>> > | +--ro use-schema* [name]
> >>>> > | +--ro name
> >>>> > | | -> /schema-mounts/schema/name
> >>>> > | +--ro parent-reference* yang:xpath1.0
> >>>> > +--ro schema* [name]
> >>>> > +--ro name string
> >>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
> >>>> > +--ro module* [name revision]
> >>>> > | +--ro name yang:yang-identifier
> >>>> > | +--ro revision union
> >>>> > | +--ro schema? inet:uri
> >>>> > | +--ro namespace inet:uri
> >>>> > | +--ro feature* yang:yang-identifier
> >>>> > | +--ro deviation* [name revision]
> >>>> > | | +--ro name yang:yang-identifier
> >>>> > | | +--ro revision union
> >>>> > | +--ro conformance-type enumeration
> >>>> > | +--ro submodule* [name revision]
> >>>> > | +--ro name yang:yang-identifier
> >>>> > | +--ro revision union
> >>>> > | +--ro schema? inet:uri
> >>>> > +--ro mount-point* [module name]
> >>>> > +--ro module yang:yang-identifier
> >>>> > +--ro name yang:yang-identifier
> >>>> > +--ro config? boolean
> >>>> > +--ro (schema-ref)?
> >>>> > +--:(inline)
> >>>> > | +--ro inline? empty
> >>>> > +--:(use-schema)
> >>>> > +--ro use-schema* [name]
> >>>> > +--ro name
> >>>> > | -> /schema-mounts/schema/name
> >>>> > +--ro parent-reference* yang:xpath1.0
> >>>> >
> >>>> > We would expect that the revised-datastores feature would be used
> >>>> > (perhaps required) for any implementation that supports
> >>>> > ietf-datastores
> >>>> > and yl-bis.
> >>>> >
> >>>> >
> >>>> >
> >>>> > _______________________________________________
> >>>> > netmod mailing list
> >>>> > netmod@ietf.org
> >>>> > https://www.ietf.org/mailman/listinfo/netmod
> >>>>
> >>>> _______________________________________________
> >>>> netmod mailing list
> >>>> netmod@ietf.org
> >>>> https://www.ietf.org/mailman/listinfo/netmod
> >>>
> >>> _______________________________________________
> >>> netmod mailing list
> >>> netmod@ietf.org
> >>> https://www.ietf.org/mailman/listinfo/netmod
> >>
> >> .
> >>
> 


From nobody Mon Feb 26 09:02:04 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8371512D864; Mon, 26 Feb 2018 09:01:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NHvQh1n-a5fu; Mon, 26 Feb 2018 09:01:54 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 1236912D88B; Mon, 26 Feb 2018 09:01:49 -0800 (PST)
Received: from mars.tail-f.com (unknown [173.38.220.47]) by mail.tail-f.com (Postfix) with ESMTPSA id 55FDA1B046BE; Mon, 26 Feb 2018 18:01:47 +0100 (CET)
To: "netmod@ietf.org" 
References: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com> <87y3jf51ed.fsf@nic.cz>
Cc: "draft-ietf-netmod-acl-model@ietf.org" 
From: Per Hedeland 
Message-ID: 
Date: Mon, 26 Feb 2018 18:01:46 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <87y3jf51ed.fsf@nic.cz>
Content-Type: text/plain; charset=windows-1252
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] derived-from() vs derived-from-or-self() in acl model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 17:01:56 -0000

[Adding Cc to draft-ietf-netmod-acl-model@ietf.org]

On 2018-02-26 14:24, Ladislav Lhotka wrote:
> Per Hedeland  writes:
> 
>> Hi,
>>
>> A customer of ours using one of the draft versions of the
>> ietf-access-control-list module reported that it was not possible to
>> configure an ethernet ace with type acl:eth-acl-type, due to the
>> derived-from() in
>>
>>                container eth {
>>                  when "derived-from(../../../../type, " +
>>                       "'acl:eth-acl-type')";
>>                  if-feature match-on-eth;
>>                  uses pf:acl-eth-header-fields;
>>                  description
>>                    "Rule set that matches ethernet headers.";
>>                }
>>
>> evaluating to "false". I pointed out that this is correct behavior of
>> our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
>> it would need to be derived-from-or-self() in order to evaluate to
>> "true". I also ventured a guess (not having followed the development of
>> the acl model in detail) that the intent was that vendors should define
>> their own identities, that actually *were* derived from acl:eth-acl-type
>> (and ditto for all the other *-acl-type identities, of course).
>>
>> However I'm not at all sure that the guess is correct, and if so why
>> this should be *enforced* by excluding the base identity. And having a
>> look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
>> seems to be doing exactly what our customer tried, alhough with
>> ipv4-acl-type:
>>
>> 
>>    
>>      
>>        sample-ipv4-acl
>>        ipv4-acl-type
>>        
>>          
>>            rule1
>>            
>>              
>>                
>>                  tcp
>>
>> As far as I can see, this snippet is invalid for the model, since the
>> 'ipv4' container has
>>
>>                container ipv4 {
>>                  when "derived-from(../../../../type, " +
>>                       "'acl:ipv4-acl-type')";
>>
>> - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
>> there shouldn't be any  element either, but that's another thing.)
>>
>> So, is it the case that the derived-from()s should actually be
>> derived-from-or-self()s, or is the example wrong?
> 
> This has to do with the irreflexivity property of identity derivation,
> which is, in my view, an unnecessary complication. It would be simpler
> but sufficient to define derivation as a reflexive relation, and have
> only one "derived-from()" XPath function.

Be that as it may, it is obviously not what RFC 7950 says.

> Identities that are considered "abstract" should not be instantiated, and
> then derived-from() and derived-from-or-self() give the same result.

So I guess your take is that the *-acl-type identities derived from
acl:acl-base in the ietf-access-control-list module should be considered
"abstract", and thus the example should not use ipv4-acl-type for the
'type' leaf, but instead some other identity derived from
acl:ipv4-acl-type. Do the authors agree?

--Per

> Lada
> 
>>
>> --Per Hedeland
>>
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org
>> https://www.ietf.org/mailman/listinfo/netmod
> 


From nobody Mon Feb 26 10:51:38 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 35BA5126C3D for ; Mon, 26 Feb 2018 10:51:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bZ2LopwnYMze for ; Mon, 26 Feb 2018 10:51:33 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id C658D124D6C for ; Mon, 26 Feb 2018 10:51:33 -0800 (PST)
Received: from pip.chopps.org (mobile-166-177-58-249.mycingular.net [166.177.58.249]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 6C16562A6F; Mon, 26 Feb 2018 18:51:32 +0000 (UTC)
References: <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87lgfg9ded.fsf@chopps.org> <20180226.160921.622063322182936097.mbj@tail-f.com>
User-agent: mu4e 0.9.19; emacs 25.3.1
From: Christian Hopps 
To: Martin Bjorklund 
Cc: chopps@chopps.org, rwilton@cisco.com, netmod@ietf.org
In-reply-to: <20180226.160921.622063322182936097.mbj@tail-f.com>
Date: Mon, 26 Feb 2018 13:51:31 -0500
Message-ID: <87efl7bn4c.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 18:51:37 -0000

Martin Bjorklund  writes:

> Hi,
>
> Christian Hopps  wrote:
>>
>> Hi Rob,
>>
>> You do realize that no-one trying to actually deploy and run networks
>> cares about live-discovery of different schema per datastore for the
>> same mount point right? Like 99.999% of the clients know where things
>> are supposed to reside and expect them to be there.
>
> But then why advertise anything at all?   We can do a *much* simpler
> solution by just having the mountpoint extension, and nothing else.
> Clients will know what to find anyway.

That was the idea Lou and I brought up over 2 *years* ago, yes. :)

But good points were made for something more general and powerful, and we all agreed with those, so..

> My experience, which may differ from yours, is that correct knowledge
> about the devices' datamodels and revisions is crucial for correct
> implementation of automation of network services.  The application
> programmer can program the intent for some set of data models, and
> then the orchestrator can automatically decide what to do for a given
> device depending on which data models it advertises.

and that's why we have a module list present in the work now ready to publish. It's enough for now. Perfect is killing good enough here.

Thanks,
Chris.

>
>
>
> /martin
>
>
>
>
> At most (although
>> still not common) they may want to know what modules are supported
>> under a mount point. What your talking about is a severe edge case
>> that apparently has achieved extreme importance in a very small group
>> of people's views.
>>
>> Thanks,
>> Chris.
>>
>> Robert Wilton  writes:
>>
>> > Hi Chris,
>> >
>> > I've got no desire or intent to try and slow down the NI and LNE
>> > drafts, or any
>> > that depend on them. I actually agree that this is critically
>> > important that
>> > IETF gets modules standardized/finished so that everyone can use them.
>> >
>> > However, ...
>> >
>> > YLbis has quite a different structure to YL. The main part of this
>> > change was
>> > to support NMDA, the other part of this change was to better support
>> > things like
>> > SM, or YANG packages.
>> >
>> > I don't think that there is a clean, backwards compatible, way to go
>> > from the
>> > YANG module in SM -08 to one that is going to work well with YLbis and
>> > other
>> > YLbis extensions/augmentations that seem to be coming down the
>> > line. Given what
>> > we know now, I believe that the correct medium/long term structure for
>> > the SM
>> > YANG module, taking YLbis into account, is the one proposed in pre09,
>> > because it
>> > directly augments the YLbis structure, and hence any future
>> > augmentations to
>> > YLbis should automatically extend to SM mounted schema as well.
>> >
>> > I think that the likely future technical issues with the -08 module
>> > will be:
>> > - supporting NMDA in a clean consistent way
>> > - adding in support for SemVer
>> > - additional capability reporting as an augmentation to YANG library
>> >
>> > So, if -08 proceeds as is, then it seems to me like one of three
>> > things will
>> > need to happen:
>> > 1) Their will need to be a non backwards compatible update to the SM
>> > model that
>> > is the same/similar to pre09.
>> > 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
>> > explicitly
>> > mounted schema.
>> > 3) We accrue technical debt, implementations need to support two YL
>> > module
>> > structures, the one in SM and the one in YLbis, and future extensions
>> > need to
>> > augment both the SM structure and YLbis structure.
>> >
>> > I don't like the idea of (2) or (3), but I don't know if others will
>> > find (1)
>> > acceptable.
>> >
>> > But I do agree that we are just going round in circles on this:
>> > - Using the pre09 structure is not acceptable to some folks
>> > - Publishing a draft with both -08 and pre09 structure is liked by even
>> > - less
>> > folks.
>> >
>> > Perhaps publishing -08 is the only option. My hope is that the WG will
>> > support
>> > somebody subsequently doing solution (1), otherwise it seems like a
>> > missed
>> > opportunity to get this right.
>> >
>> > Thanks,
>> > Rob
>> >
>> >
>> > On 24/02/2018 13:54, Christian Hopps wrote:
>> >> My position,
>> >>
>> >> It may be the case that there's even a better cleaner solution;
>> >> however, it's
>> >> simply too late for major modifications to this work that don't
>> >> actually
>> >> address functional failures. The draft as proposed works for the
>> >> people who
>> >> need to get work done.
>> >>
>> >> We have multiple pending RFCs - MISREF on this document. These RFCs
>> >> would have
>> >> to be pulled from the RFC EDITOR queue, and reworked to be compliant
>> >> again,
>> >> and this very well could lead to discovering issues with your new
>> >> proposal.
>> >> Any new issues discovered in either the pending RFCs *or* in the new
>> >> solution
>> >> would then need to be worked out and fixed. Please recall that this
>> >> actually
>> >> occurred on the first round (i.e., doing the examples led to
>> >> discovering
>> >> problems with the drafts), so it's not unreasonable at all to assume
>> >> this
>> >> would happen again.
>> >>
>> >> Look this just isn't a simple change your proposing. It involves a
>> >> large
>> >> upheaval, killing the pending RFC status on multiple documents that
>> >> the
>> >> industry is waiting on. Please see this.
>> >>
>> >> Thanks,
>> >> Chris.
>> >>
>> >>
>> >> Martin Bjorklund  writes:
>> >>
>> >>> Hi,
>> >>>
>> >>> Robert Wilton  wrote:
>> >>>> Hi Lou,
>> >>>>
>> >>>> I think that this solution is inferior to the model presented in
>> >>>> pre-09.
>> >>>
>> >>> I agree. Servers that are NMDA-compliant, or implements YANG Library
>> >>> bis will have to present schemas in two different structures,
>> >>> depending on where the schema is used, and clients will have to code
>> >>> for both. With the solution in pre-09, there is just one structure.
>> >>> A single structure also has other benefits (apart from being simpler),
>> >>> e.g., if we augment it with the meta data that has been discussed
>> >>> recently, we can augment a single structure.
>> >>
>> >>> /martin
>> >>>
>> >>>
>> >>>
>> >>>> I would prefer that we publish pre09 instead, potentially including
>> >>>> the -08 model in the appendix if that helps progress the document in a
>> >>>> more expedient fashion.
>> >>>>
>> >>>> Thanks,
>> >>>> Rob
>> >>>>
>> >>>>
>> >>>> On 22/02/2018 16:18, Lou Berger wrote:
>> >>>> > Hi,
>> >>>> >
>> >>>> > (I have a bunch of different roles WRT this work. This mail is being
>> >>>> > sent as an individual - as chair, I fully support the previous chair
>> >>>> > statements on this draft.)
>> >>>> >
>> >>>> > Chris and I have come up with a proposal on how to provide full NMDA
>> >>>> > as part the existing schema-mount module. Our motivation was to
>> >>>> > enable full NMDA support with *minimal* change to the model and
>> >>>> > disruption to the LC'ed work. The key NMDA limitation, with -08, that
>> >>>> > we are aiming to address is the ability to support different mounted
>> >>>> > schema in different datastores for non-inline mount points. (See more
>> >>>> > detailed description below if interested full nuances of limitations
>> >>>> > of -08)
>> >>>> >
>> >>>> > What we came up with was to simply add a (leaf)list to identify in
>> >>>> > which datastores a
>> >>>> > schema-mount schema is valid/present. This is somewhat similar to
>> >>>> > YL-bis schema/module-set. Specifically we're proposing (see below for
>> >>>> > full tree below):
>> >>>> >
>> >>>> > +--ro schema* [name]
>> >>>> > +--ro name string
>> >>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>> >>>> >
>> >>>> > This approach has the advantages of supporting different mounted
>> >>>> > schema in different DSes, working with both NMDA and non-NMDA
>> >>>> > implementations, supporting all of the extensively discussed features
>> >>>> > of schema mount (including recursive mounts), and having minor/scoped
>> >>>> > impact on all dependent work. The main downside is that it isn't the
>> >>>> > most optimal/compact solution possible if we were to base this work on
>> >>>> > YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from all
>> >>>> > perspectives, but it is what was agreed to as sufficient by those who
>> >>>> > contribute to the WG discussion.
>> >>>> >
>> >>>> > In short, we see this as a solution to addresses the raised last call
>> >>>> > issue with the minimal impact on -08 and dependent work -- which is
>> >>>> > what is appropriate given where we are in the process.
>> >>>> >
>> >>>> > So our/my question really is:
>> >>>> >
>> >>>> > Is this a solution that you/all can live with?
>> >>>> >
>> >>>> > Note: optimization, design preference and perfect alignment with use
>> >>>> > or YL-bis are not part of our question as we both don't think that is
>> >>>> > the right question given where we are in the WG process.
>> >>>> >
>> >>>> > Lou (with ideas developed with Chris, and chair hat off)
>> >>>> >
>> >>>> > ======
>> >>>> > Details -- for those who want
>> >>>> > ======
>> >>>> > As background, my understanding/view is that the -08 version of the
>> >>>> > both NMDA and non-NMDA supporting implementations, but there are
>> >>>> > limitations in its NMDA applicability. Used with Yang Library,
>> >>>> > [rfc7895], only non-NMDA implementations can be supported. When used
>> >>>> > with the revised Yang Library defined in
>> >>>> > [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
>> >>>> > supported with certain limitations. Specifically, this document
>> >>>> > requires use of the now deprecated module-list grouping, and the same
>> >>>> > schema represented in schema list of the Schema Mount module MUST be
>> >>>> > used in all datastores. Inline type mount points, which don't use the
>> >>>> > schema list, can support different schema in different data stores
>> >>>> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>> >>>> > YANG library under the inline mount point.
>> >>>> >
>> >>>> > module: ietf-yang-schema-mount
>> >>>> > +--ro schema-mounts
>> >>>> > +--ro namespace* [prefix]
>> >>>> > | +--ro prefix yang:yang-identifier
>> >>>> > | +--ro uri? inet:uri
>> >>>> > +--ro mount-point* [module name]
>> >>>> > | +--ro module yang:yang-identifier
>> >>>> > | +--ro name yang:yang-identifier
>> >>>> > | +--ro config? boolean
>> >>>> > | +--ro (schema-ref)?
>> >>>> > | +--:(inline)
>> >>>> > | | +--ro inline? empty
>> >>>> > | +--:(use-schema)
>> >>>> > | +--ro use-schema* [name]
>> >>>> > | +--ro name
>> >>>> > | | -> /schema-mounts/schema/name
>> >>>> > | +--ro parent-reference* yang:xpath1.0
>> >>>> > +--ro schema* [name]
>> >>>> > +--ro name string
>> >>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>> >>>> > +--ro module* [name revision]
>> >>>> > | +--ro name yang:yang-identifier
>> >>>> > | +--ro revision union
>> >>>> > | +--ro schema? inet:uri
>> >>>> > | +--ro namespace inet:uri
>> >>>> > | +--ro feature* yang:yang-identifier
>> >>>> > | +--ro deviation* [name revision]
>> >>>> > | | +--ro name yang:yang-identifier
>> >>>> > | | +--ro revision union
>> >>>> > | +--ro conformance-type enumeration
>> >>>> > | +--ro submodule* [name revision]
>> >>>> > | +--ro name yang:yang-identifier
>> >>>> > | +--ro revision union
>> >>>> > | +--ro schema? inet:uri
>> >>>> > +--ro mount-point* [module name]
>> >>>> > +--ro module yang:yang-identifier
>> >>>> > +--ro name yang:yang-identifier
>> >>>> > +--ro config? boolean
>> >>>> > +--ro (schema-ref)?
>> >>>> > +--:(inline)
>> >>>> > | +--ro inline? empty
>> >>>> > +--:(use-schema)
>> >>>> > +--ro use-schema* [name]
>> >>>> > +--ro name
>> >>>> > | -> /schema-mounts/schema/name
>> >>>> > +--ro parent-reference* yang:xpath1.0
>> >>>> >
>> >>>> > We would expect that the revised-datastores feature would be used
>> >>>> > (perhaps required) for any implementation that supports
>> >>>> > ietf-datastores
>> >>>> > and yl-bis.
>> >>>> >
>> >>>> >
>> >>>> >
>> >>>> > _______________________________________________
>> >>>> > netmod mailing list
>> >>>> > netmod@ietf.org
>> >>>> > https://www.ietf.org/mailman/listinfo/netmod
>> >>>>
>> >>>> _______________________________________________
>> >>>> netmod mailing list
>> >>>> netmod@ietf.org
>> >>>> https://www.ietf.org/mailman/listinfo/netmod
>> >>>
>> >>> _______________________________________________
>> >>> netmod mailing list
>> >>> netmod@ietf.org
>> >>> https://www.ietf.org/mailman/listinfo/netmod
>> >>
>> >> .
>> >>
>>


From nobody Mon Feb 26 11:15:12 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 66CBB126E64; Mon, 26 Feb 2018 11:15:11 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hJy9oS1jqQCt; Mon, 26 Feb 2018 11:15:08 -0800 (PST)
Received: from mail-pl0-x22d.google.com (mail-pl0-x22d.google.com [IPv6:2607:f8b0:400e:c01::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 93616126C26; Mon, 26 Feb 2018 11:15:08 -0800 (PST)
Received: by mail-pl0-x22d.google.com with SMTP id u13so9848329plq.1; Mon, 26 Feb 2018 11:15:08 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=aEIABOaquKeF9KEYTdoR9pihFr/SzQfw1a9Gbe+dQtw=; b=uRD7OF1eEAHhwSCetI3KNtRfSEUmE9KHLtTgkhfBME+FeWpjdACbZYapGjlbXIJt4d eHctQKmc1oy/1ZDe8SEhOad1g/x9ir4hKHdSx3tKaPZ1p82sj4l05Lq/CKVXLd6ptycg 8hvEzEZjrl7fS0mNTZ1GIa9JdgCG28P74hUn4E+7MD9yOBauA+9zUAIZAqHr7z3YGzGS bM4f1xGPPsXku3navwyqR+UIQBF1+S9Zqoga0/fjbFlw37hQacO+IAr5yx3M4zK1t1Bq h/u/EqNGfihYmjE81jJXHoZ9rldED11PqmFzBEqcuKaHSxKYgTE9BFMaSjBB9qMHtO7k iYDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=aEIABOaquKeF9KEYTdoR9pihFr/SzQfw1a9Gbe+dQtw=; b=HJgAjY1PSPEqusbPyvZN7lL14/EkrDPiKXE4kqeJwOI7C99j+chnNRFsP7FykYVGrq qslzfy+SUs9wyMQzg/hXR/NTMfyBCL7livf4iOMEo9+YGwa1TBIGOSCIpq1qBy5ajYRj van89yyWPNMZXA7sGpk8nKLPi1nNKpTr9K1XnBKmHVBYt5ARtN2T/WJtiPXRrJx/gZpy yn3zQwx0ykX5MBTMyKFTkCCXXl1ifrkjh8Kzbr83RTM4MBdk2x24/cfytpS/PcMr1w10 oQbM77cc4/LQgQ/0WQno+oiwwJjD5ItHRW9ermu41ins1taVjBqKqhga50BTi7KvVKVP 18pA==
X-Gm-Message-State: APf1xPBQpvEjjmuuBOeav01LQZQn1kVTFW2J4QiKtSpY7YJK9Axd/PBV axTavIZvQoDNO3utImGVljQ=
X-Google-Smtp-Source: AH8x2252nUzFdZ2Ltp0Vg6GZVjnA7wYV4k+Z2hz8Wug2iQ+uzHWZm9q3UYbuPd8g9MkJxFFSIHwgNw==
X-Received: by 2002:a17:902:ab84:: with SMTP id f4-v6mr11791834plr.239.1519672508050;  Mon, 26 Feb 2018 11:15:08 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:59d9:6f72:9685:4ce6? ([2601:647:4700:1280:59d9:6f72:9685:4ce6]) by smtp.gmail.com with ESMTPSA id k192sm8240820pfc.98.2018.02.26.11.15.07 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 11:15:07 -0800 (PST)
From: Mahesh Jethanandani 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_E1D4E7F4-1E32-49FC-8232-3AE9E349B709"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 26 Feb 2018 11:20:55 -0800
In-Reply-To: 
Cc: "netmod@ietf.org" , "draft-ietf-netmod-acl-model@ietf.org" 
To: Per Hedeland 
References: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com> <87y3jf51ed.fsf@nic.cz> 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] derived-from() vs derived-from-or-self() in acl model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 19:15:11 -0000

--Apple-Mail=_E1D4E7F4-1E32-49FC-8232-3AE9E349B709
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=us-ascii



> On Feb 26, 2018, at 9:01 AM, Per Hedeland  wrote:
>=20
> [Adding Cc to draft-ietf-netmod-acl-model@ietf.org =
]
>=20
> On 2018-02-26 14:24, Ladislav Lhotka wrote:
>> Per Hedeland  writes:
>>=20
>>> Hi,
>>>=20
>>> A customer of ours using one of the draft versions of the
>>> ietf-access-control-list module reported that it was not possible to
>>> configure an ethernet ace with type acl:eth-acl-type, due to the
>>> derived-from() in
>>>=20
>>>               container eth {
>>>                 when "derived-from(../../../../type, " +
>>>                      "'acl:eth-acl-type')";
>>>                 if-feature match-on-eth;
>>>                 uses pf:acl-eth-header-fields;
>>>                 description
>>>                   "Rule set that matches ethernet headers.";
>>>               }
>>>=20
>>> evaluating to "false". I pointed out that this is correct behavior =
of
>>> our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, =
and
>>> it would need to be derived-from-or-self() in order to evaluate to
>>> "true". I also ventured a guess (not having followed the development =
of
>>> the acl model in detail) that the intent was that vendors should =
define
>>> their own identities, that actually *were* derived from =
acl:eth-acl-type
>>> (and ditto for all the other *-acl-type identities, of course).
>>>=20
>>> However I'm not at all sure that the guess is correct, and if so why
>>> this should be *enforced* by excluding the base identity. And having =
a
>>> look at the example in section 4.3 of =
draft-ietf-netmod-acl-model-16, it
>>> seems to be doing exactly what our customer tried, alhough with
>>> ipv4-acl-type:
>>>=20
>>> 
>>>   
>>>     
>>>       sample-ipv4-acl
>>>       ipv4-acl-type
>>>       
>>>         
>>>           rule1
>>>           
>>>             
>>>               
>>>                 tcp
>>>=20
>>> As far as I can see, this snippet is invalid for the model, since =
the
>>> 'ipv4' container has
>>>=20
>>>               container ipv4 {
>>>                 when "derived-from(../../../../type, " +
>>>                      "'acl:ipv4-acl-type')";
>>>=20
>>> - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
>>> there shouldn't be any  element either, but that's another =
thing.)
>>>=20
>>> So, is it the case that the derived-from()s should actually be
>>> derived-from-or-self()s, or is the example wrong?
>>=20
>> This has to do with the irreflexivity property of identity =
derivation,
>> which is, in my view, an unnecessary complication. It would be =
simpler
>> but sufficient to define derivation as a reflexive relation, and have
>> only one "derived-from()" XPath function.
>=20
> Be that as it may, it is obviously not what RFC 7950 says.

I would agree that that is not how I am reading RFC 7950. For now my =
choice is to change all the derived-from() to derived-from-or-self().

>=20
>> Identities that are considered "abstract" should not be instantiated, =
and
>> then derived-from() and derived-from-or-self() give the same result.
>=20
> So I guess your take is that the *-acl-type identities derived from
> acl:acl-base in the ietf-access-control-list module should be =
considered
> "abstract", and thus the example should not use ipv4-acl-type for the
> 'type' leaf, but instead some other identity derived from
> acl:ipv4-acl-type. Do the authors agree?
>=20
> --Per
>=20
>> Lada
>>=20
>>>=20
>>> --Per Hedeland
>>>=20
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org 
>>> https://www.ietf.org/mailman/listinfo/netmod =

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_E1D4E7F4-1E32-49FC-8232-3AE9E349B709
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=us-ascii



On Feb 26, 2018, at 9:01 AM, Per Hedeland <per@tail-f.com> =
wrote:

[Adding Cc to draft-ietf-netmod-acl-model@ietf.org]

On 2018-02-26 14:24, Ladislav Lhotka =
wrote:
Per Hedeland <per@tail-f.com> writes:

Hi,

A customer of ours using one of the draft versions of the
ietf-access-control-list module reported that it was not =
possible to
configure an ethernet ace with type =
acl:eth-acl-type, due to the
derived-from() in

          &nb=
sp;   container eth {
          &nb=
sp;     when "derived-from(../../../../type, " =
+
          &nb=
sp;          "'acl:eth-a=
cl-type')";
          &nb=
sp;     if-feature match-on-eth;
          &nb=
sp;     uses pf:acl-eth-header-fields;
          &nb=
sp;     description
          &nb=
sp;       "Rule set that matches =
ethernet headers.";
          &nb=
sp;   }

evaluating to =
"false". I pointed out that this is correct behavior of
our =
SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
it would need to be derived-from-or-self() in order to =
evaluate to
"true". I also ventured a guess (not having =
followed the development of
the acl model in detail) that =
the intent was that vendors should define
their own =
identities, that actually *were* derived from acl:eth-acl-type
(and ditto for all the other *-acl-type identities, of =
course).

However I'm not at all sure that =
the guess is correct, and if so why
this should be =
*enforced* by excluding the base identity. And having a
look=
 at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
seems to be doing exactly what our customer tried, alhough =
with
ipv4-acl-type:

<data =
xmlns=3D"urn:ietf:params:xml:ns:netconf:base:1.0">
  <access-lists =
xmlns=3D"urn:ietf:params:xml:ns:yang:ietf-access-control-list">
    <acl>
      <name>sample-ipv4-acl=
</name>
      <type>ipv4-acl-type&l=
t;/type>
      <aces>
        <ace>
          <=
;name>rule1</name>
          <=
;matches>
          &nb=
sp; <l3>
          &nb=
sp;   <ipv4>
          &nb=
sp;     <protocol>tcp</protocol>

As far as I can see, this snippet is invalid =
for the model, since the
'ipv4' container has

          &nb=
sp;   container ipv4 {
          &nb=
sp;     when "derived-from(../../../../type, " =
+
          &nb=
sp;          "'acl:ipv4-=
acl-type')";

- and ipv4-acl-type is *not* =
derived from ipv4-acl-type. (Of course
there shouldn't be =
any <l3> element either, but that's another thing.)

So, is it the case that the derived-from()s =
should actually be
derived-from-or-self()s, or is the =
example wrong?

This has to do =
with the irreflexivity property of identity derivation,
which is, in my view, an unnecessary complication. It would =
be simpler
but sufficient to define derivation as a =
reflexive relation, and have
only one "derived-from()" =
XPath function.

Be that as it may, it is =
obviously not what RFC 7950 says.

I would agree =
that that is not how I am reading RFC 7950. For now my choice is to =
change all the derived-from() to derived-from-or-self().


Identities that are =
considered "abstract" should not be instantiated, and
then =
derived-from() and derived-from-or-self() give the same result.

So I guess your take is that the =
*-acl-type identities derived from
acl:acl-base in the =
ietf-access-control-list module should be considered
"abstract", and thus the example should not use =
ipv4-acl-type for the
'type' leaf, but instead some =
other identity derived from
acl:ipv4-acl-type. Do the =
authors agree?

--Per
Lada


--Per =
Hedeland

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



Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_E1D4E7F4-1E32-49FC-8232-3AE9E349B709--


From nobody Mon Feb 26 11:18:39 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 668541270A7; Mon, 26 Feb 2018 11:18:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sttsxZZ0PCnb; Mon, 26 Feb 2018 11:18:35 -0800 (PST)
Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 54F47126C26; Mon, 26 Feb 2018 11:18:35 -0800 (PST)
Received: by mail-pl0-x232.google.com with SMTP id w21so9836133plp.11; Mon, 26 Feb 2018 11:18:35 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=CL5b0C4wq1iQoK4LEmfKw81IJRqeLfsUEFrJZno9OZE=; b=Dy9UDfRtas/olw/+tLhRArMHzYUuc27qH9jwFqRR1q1hUzZmiroi+y9X57tZ9/uL7l 0amHnKXVpbAphm/KTX+A8Cwtvqd5ooFTOuuiX1HYWZh235D0RLAVDloQNFe7n1vbEsER E2Mx4DCSw8ebt8elL61dq00pX7OPfWrU9aUQo+w0kkkhZInEiPT6A1+liV/MDiPx3onm 3J9jK8Y3VoWbHMce+MIb4cI87hiWW3sapbsWQr6VWXQ/iFgNTGxG83sOdYV81mv0Crct oMPa+4AgeFx2PLym9jzpucvXXPHLyBgK9yvLfjQlrwxROnQIr4obYkNcjnaWSBMYt+gR wEtw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=CL5b0C4wq1iQoK4LEmfKw81IJRqeLfsUEFrJZno9OZE=; b=DL1wdunzrqkznRhUg+TVaXi6g+Dgm/IaUe031Eo6KaJshUO5NgnFqco+152U6BJKn1 0c8hiOfmhaywdClP8hmF8Y150M0svFUVYOApeXQNbaoOeCnpi69EOrkz6V8jdySldpzZ H65HoP2dS6xhSD8+wJOE8mmMg0iVHe9Ij5ob/N5hjMBiDWhAYjK4lyY4xwX6bPBnWRM0 bquQfNvj1y6HDMC45MHDbH9zqta0znVRu8ENvntBplC2hVwVHLxWRY8HCkxoEkDw55U0 jH4FlB2lQyNAl3cg3nUVZFn9g6oWOfkp90lufRMXbfnL07VrFukk01/liEe8uMaKHoVQ 4Fzw==
X-Gm-Message-State: APf1xPC8+8czuuIf6H2qKjHdK7Cilz8ISSabntCAc/GAa7h41WKJHaIA V7N/2XFINTLWdopWBppMb04=
X-Google-Smtp-Source: AH8x224dRU/yh1rqH1C4OK6ar1Hcfhc44j9W6St4SHHa0xTgoC3XLzJiPvq9iNUioegpyDj1KE2/1w==
X-Received: by 2002:a17:902:42a3:: with SMTP id h32-v6mr11868776pld.231.1519672714688;  Mon, 26 Feb 2018 11:18:34 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:59d9:6f72:9685:4ce6? ([2601:647:4700:1280:59d9:6f72:9685:4ce6]) by smtp.gmail.com with ESMTPSA id q66sm18864584pfi.95.2018.02.26.11.18.33 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 11:18:34 -0800 (PST)
From: Mahesh Jethanandani 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_94D63B92-91CA-4AA6-A8B1-47C0A2D058F4"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 26 Feb 2018 11:24:22 -0800
In-Reply-To: <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com>
Cc: Kent Watsen , "draft-ietf-netmod-acl-model@ietf.org" ,  "netmod@ietf.org" , Warren Kumari , "Joe Clarke (jclarke)" 
To: Eliot Lear 
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net> <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com> <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net> <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com> <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 19:18:37 -0000

--Apple-Mail=_94D63B92-91CA-4AA6-A8B1-47C0A2D058F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

A pull request to address LC, shepherd, this and the other comments, =
including derived-from(), can be reviewed here:

https://github.com/netmod-wg/acl-model/pull/24 =


Thanks.

> On Feb 26, 2018, at 12:15 AM, Eliot Lear  wrote:
>=20
>=20
>=20
> On 26.02.18 06:55, Mahesh Jethanandani wrote:
>>>=20
>>>>=20
>>>>=20
>>>>  PS: And this is not a shepherd directive, but I found the whole=20
>>>>      "source-port-range-or-operator" syntax clumsy.  I'm surprised
>>>>      it didn't look something like:
>>>>=20
>>>>          OLD
>>>>                
>>>>                   
>>>>                     
>>>>                       16384
>>>>                       65535
>>>>                     
>>>>                   
>>>>                
>>>>=20
>>>>                
>>>>                  
>>>>                    
>>>>                      eq
>>>>                      21
>>>>                    
>>>>                  
>>>>                
>>>>=20
>>>>          NEW
>>>>=20
>>>>                
>>>>                  
>>>>                    16384
>>>>                    65535
>>>>                  
>>>>                
>>>>=20
>>>>                
>>>>                  
>>>>                    eq
>>>>                    21
>>>>                  
>>>>                
>>>>=20
>>> =20
>>> Did you try making the change in the model to see if it work? It =
will complain that  is already used within the container and that =
it cannot be repeated (for destination-port).
>>>=20
>>>  No, I did not, nor do I intend to get that deep into it.  But =
I recall that Kristian made the same comment before, and was making pull =
requests before, so maybe he can suggest something?
>>=20
>> Kristian=E2=80=99s suggestion requires changing the module. It is not =
an editorial change. And that change will have an impact on the MUD =
draft, which has been sent for publication.=20
>>=20
>=20
> As it happens, we found a bug in our augment statements, and so we =
will need to rev one more time.  If the change can be made quickly, I =
can live with it.
>=20
> Eliot

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_94D63B92-91CA-4AA6-A8B1-47C0A2D058F4
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

A =
pull request to address LC, shepherd, this and the other comments, =
including derived-from(), can be reviewed here:

https://github.com/netmod-wg/acl-model/pull/24

Thanks.

On Feb 26, 2018, at 12:15 AM, Eliot Lear <lear@cisco.com> =
wrote:


 =20
    
 =20
  


    

    

    
On 26.02.18 06:55, Mahesh =
Jethanandani
      wrote:

    

    

      

        

          

            

              

                

                  


                    

                  

                    

                      


                          

                           PS: And this is not a shepherd =
directive, but
                          I found the whole 

                          =
     "source-port-range-or-operator" syntax
                          clumsy.  I'm surprised

                               it didn't look =
something like:

                          

                          =
         OLD

=
            &n=
bsp;  <source-port-range-or-operator>

=
            &n=
bsp;     <port-range-or-operator>

                          =
            &n=
bsp;       <range>
=

=
            &n=
bsp;         <lower-port&g=
t;16384</lower-port>

=
            &n=
bsp;         <upper-port&g=
t;65535</upper-port>

                          =
            &n=
bsp;       </range>

=
            &n=
bsp;     </port-range-or-operator>

=
            &n=
bsp;  </source-port-range-or-operator>

                          

=
            &n=
bsp;  <source-port-range-or-operator>

=
            &n=
bsp;    <port-range-or-operator>

                          =
            &n=
bsp;      <operator>

=
            &n=
bsp;        <operator>eq<=
/operator>

=
            &n=
bsp;        <port>21</por=
t>

                          =
            &n=
bsp;      </operator>

=
            &n=
bsp;    </port-range-or-operator>
=

=
            &n=
bsp;  </source-port-range-or-operator>

                          

                          =
         NEW

                          

                          =
            &n=
bsp;  <source-port>

                          =
            &n=
bsp;    <range>

=
            &n=
bsp;      <lower>16384</lower>
=
            &n=
bsp;      <upper>65535</upper>
                          =
            &n=
bsp;    </range>

                          =
            &n=
bsp;  </source-port>

                          

                          =
            &n=
bsp;  <source-port>

                          =
            &n=
bsp;    <operator>

=
            &n=
bsp;      <operator>eq</operator>=
;

                          =
            &n=
bsp;      <port>21</port>

                          =
            &n=
bsp;    </operator>

                          =
            &n=
bsp;  </source-port>

                      

                    

                  

                  

                    
 

                  

                  
Did
                    you try making the change in the model to see if it
                    work? It will complain that <range> is already
                    used within the container and that it cannot be
                    repeated (for destination-port).

                

                

                  


                    <KENT> No, I did not, nor do I intend to get
                    that deep into it.  But I recall that Kristian =
made
                    the same comment before, and was making pull
                    requests before, so maybe he can suggest =
something?

                

              

            

          

        

        


        

        Kristian=E2=80=99s suggestion requires changing the module. It =
is not an
        editorial change. And that change will have an impact on the MUD
        draft, which has been sent for publication. 

      


      

    

    

    As it happens, we found a bug in our augment statements, and so we
    will need to rev one more time.  If the change can be made =
quickly,
    I can live with it.

    

    Eliot

  






Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_94D63B92-91CA-4AA6-A8B1-47C0A2D058F4--


From nobody Mon Feb 26 12:44:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B5D2512D864 for ; Mon, 26 Feb 2018 12:44:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyxkub9rt5wm for ; Mon, 26 Feb 2018 12:44:12 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 60A33127601 for ; Mon, 26 Feb 2018 12:44:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=546; q=dns/txt; s=iport; t=1519677852; x=1520887452; h=subject:to:references:from:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=F0rtjFiP2qpYIrjrC0ovxRaoyxdZpS3v5McnRXpd4c8=; b=hvuyORi3f1f4pFgQyHziOPHjIUiW7YEr7RSLCFDH90VUOHXchilFz3uG EcqSkt4dHdTZ2o6FdNJKcKDMnDoTcfQN5IMQKoUvZwYjVy84yVsaPfSnd cT2J9MZcAVogNPsh7U/QfL9Cq2icc8YtZE48EoftsRkULWcDP52VdkVLL I=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ByAQD0cJRa/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYUlg3yLFo5agUiYGwqFMwKDHBUBAgEBAQEBAQJrKIUkBiMPAQV?= =?us-ascii?q?RCxoCJgICVxMIAQGFDKw5gieEdIN8ghQBAQEHAgElgQ+ICoIPgwSFbYJBgmUBB?= =?us-ascii?q?KFhCZQggXKJOYc1jlGHJIEvNCKBUTMaCBsVGYJlhFo/jQ0BAQE?=
X-IronPort-AV: E=Sophos;i="5.47,397,1515456000";  d="scan'208";a="2303700"
Received: from aer-iport-nat.cisco.com (HELO aer-core-4.cisco.com) ([173.38.203.22]) by aer-iport-1.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 20:44:10 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id w1QKiAHK026932 for ; Mon, 26 Feb 2018 20:44:10 GMT
To: netmod@ietf.org
References: <20180223071204.wio22cwopgajy7hb@elstar.local>
From: Benoit Claise 
Message-ID: <8fe72d11-c992-cf73-3fd0-72c86e718fe8@cisco.com>
Date: Mon, 26 Feb 2018 21:44:10 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <20180223071204.wio22cwopgajy7hb@elstar.local>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] reference statement examples in draft-ietf-netmod-rfc6087bis-18
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 20:44:13 -0000

Jürgen,

It makes sense.
This comment should be considered as an IETF LC comment.

Regards, B.
> Hi,
>
> I think it was common practice to write
>
>    reference "RFC 6991: Common YANG Data Types";
>
> instead of just
>
>    reference "RFC 6991";
>
> that is to include the RFC title (this can be especially useful with
> longer lists of references and less commonly known RFC numbers). It
> seems that draft-ietf-netmod-rfc6087bis-18 kind of suggests to only
> use the RFC number (section 3.2 and section 4.7).
>
> /js
>


From nobody Mon Feb 26 13:31:58 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 97FBF126DFB; Mon, 26 Feb 2018 13:31:57 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Zf9MKt_ZbMvo; Mon, 26 Feb 2018 13:31:55 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 573051200B9; Mon, 26 Feb 2018 13:31:55 -0800 (PST)
Received: from pluto.hedeland.org (81-228-155-109-no289.tbcn.telia.com [81.228.155.109]) by mail.tail-f.com (Postfix) with ESMTPSA id 4F4F01AE0488; Mon, 26 Feb 2018 22:31:54 +0100 (CET)
To: Mahesh Jethanandani 
Cc: "netmod@ietf.org" , "draft-ietf-netmod-acl-model@ietf.org" 
References: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com> <87y3jf51ed.fsf@nic.cz>  
From: Per Hedeland 
Message-ID: 
Date: Mon, 26 Feb 2018 22:31:54 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/mixed; boundary="------------8D4ED7C34B3F408BF2D51216"
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] derived-from() vs derived-from-or-self() in acl model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 21:31:58 -0000

This is a multi-part message in MIME format.
--------------8D4ED7C34B3F408BF2D51216
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

On 2018-02-26 20:20, Mahesh Jethanandani wrote:
> 
> 
>> On Feb 26, 2018, at 9:01 AM, Per Hedeland > wrote:
>>
>> [Adding Cc todraft-ietf-netmod-acl-model@ietf.org ]
>>
>> On 2018-02-26 14:24, Ladislav Lhotka wrote:
>>> Per Hedeland > writes:
>>>
>>>> Hi,
>>>>
>>>> A customer of ours using one of the draft versions of the
>>>> ietf-access-control-list module reported that it was not possible to
>>>> configure an ethernet ace with type acl:eth-acl-type, due to the
>>>> derived-from() in
>>>>
>>>>               container eth {
>>>>                 when "derived-from(../../../../type, " +
>>>>                      "'acl:eth-acl-type')";
>>>>                 if-feature match-on-eth;
>>>>                 uses pf:acl-eth-header-fields;
>>>>                 description
>>>>                   "Rule set that matches ethernet headers.";
>>>>               }
>>>>
>>>> evaluating to "false". I pointed out that this is correct behavior of
>>>> our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
>>>> it would need to be derived-from-or-self() in order to evaluate to
>>>> "true". I also ventured a guess (not having followed the development of
>>>> the acl model in detail) that the intent was that vendors should define
>>>> their own identities, that actually *were* derived from acl:eth-acl-type
>>>> (and ditto for all the other *-acl-type identities, of course).
>>>>
>>>> However I'm not at all sure that the guess is correct, and if so why
>>>> this should be *enforced* by excluding the base identity. And having a
>>>> look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
>>>> seems to be doing exactly what our customer tried, alhough with
>>>> ipv4-acl-type:
>>>>
>>>> 
>>>>   
>>>>     
>>>>       sample-ipv4-acl
>>>>       ipv4-acl-type
>>>>       
>>>>         
>>>>           rule1
>>>>           
>>>>             
>>>>               
>>>>                 tcp
>>>>
>>>> As far as I can see, this snippet is invalid for the model, since the
>>>> 'ipv4' container has
>>>>
>>>>               container ipv4 {
>>>>                 when "derived-from(../../../../type, " +
>>>>                      "'acl:ipv4-acl-type')";
>>>>
>>>> - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
>>>> there shouldn't be any  element either, but that's another thing.)
>>>>
>>>> So, is it the case that the derived-from()s should actually be
>>>> derived-from-or-self()s, or is the example wrong?
>>>
>>> This has to do with the irreflexivity property of identity derivation,
>>> which is, in my view, an unnecessary complication. It would be simpler
>>> but sufficient to define derivation as a reflexive relation, and have
>>> only one "derived-from()" XPath function.
>>
>> Be that as it may, it is obviously not what RFC 7950 says.
> 
> I would agree that that is not how I am reading RFC 7950. For now my choice is to change all the derived-from() to derived-from-or-self().

I think that is a useful change. FWIW, when I actually tried the example
as the payload of an  towards our NETCONF server, I found
some other problems, which I believe are still relevant with the pull
request applied:

1) (Aldready mentioned) the  element corresponding to the choice in
the model should not be present (RFC 7950 section 7.9.5).

2) "tcp" is not a valid value for the 'protocol' leaf - from
ietf-packet-fields@2018-02-02.yang:

     leaf protocol {
       type uint8;
       description
         "Internet Protocol number. Refers to the protocol of the
          payload. In IPv6, this field is known as 'next-header.";
       reference "RFC 719, RFC 2460.";
     }

I.e. it should be "6". And the reference for this leaf, as well as for
'length' and 'ttl', should presumably be RFC 791, not RFC 719.

3) 11.11.11.1/24 (for 'destination-ipv4-network') and 10.10.10.1/24 (for
'source-ipv4-network') are not valid (canonical) values for
inet:ipv4-prefix - from ietf-inet-types.yang:

       The canonical format of an IPv4 prefix has all bits of
       the IPv4 address set to zero that are not part of the
       IPv4 prefix.";

And of course it doesn't make much sense to have bits outside the prefix
length set for a match specification. It seems the pull request changes
these prefixes to RFC 1918 / RFC 5737 space, but those prefixes have
the same issue.

I'm attaching the output from a  towards our NETCONF server
with these issues fixed (and the derived-from() ->
derived-from-or-self() change made).

--Per

>>
>>> Identities that are considered "abstract" should not be instantiated, and
>>> then derived-from() and derived-from-or-self() give the same result.
>>
>> So I guess your take is that the *-acl-type identities derived from
>> acl:acl-base in the ietf-access-control-list module should be considered
>> "abstract", and thus the example should not use ipv4-acl-type for the
>> 'type' leaf, but instead some other identity derived from
>> acl:ipv4-acl-type. Do the authors agree?
>>
>> --Per
>>
>>> Lada
>>>
>>>>
>>>> --Per Hedeland
>>>>
>>>> _______________________________________________
>>>> netmod mailing list
>>>> netmod@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/netmod
> 
> Mahesh Jethanandani
> mjethanandani@gmail.com 
> 


--------------8D4ED7C34B3F408BF2D51216
Content-Type: text/xml;
 name="example.xml"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
 filename="example.xml"



  
    
      sample-ipv4-acl
      ipv4-acl-type
      
        
          rule1
          
            
              6
              11.11.11.0/24
              10.10.10.0/24
            
          
          
            drop
          
        
      
    
  


--------------8D4ED7C34B3F408BF2D51216--


From nobody Mon Feb 26 13:56:36 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9E945126DFB; Mon, 26 Feb 2018 13:56:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level: 
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9,  DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aFzgdTPgN1Km; Mon, 26 Feb 2018 13:56:33 -0800 (PST)
Received: from mail-pg0-x22f.google.com (mail-pg0-x22f.google.com [IPv6:2607:f8b0:400e:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6AC8126C2F; Mon, 26 Feb 2018 13:56:32 -0800 (PST)
Received: by mail-pg0-x22f.google.com with SMTP id e11so6703088pgq.12; Mon, 26 Feb 2018 13:56:32 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P5/5E5q5enJY9qi90EW55bAZMcB+ev8f+8aqE/wPd90=; b=IsGVMqIHA6irDx4Ij4a+2hGXMgMmqKyGnVu6+4yV80qGw3ccGCYziCcCYc5vN622bc Se22pHbt01qpnWE2kyzPrlabcyEl4mJ7Msp0NDRE+L4mfF860mV37Y0KBqXqMKjh3z+L wO7+v5sKZ21ZmzwjBJM3xT32oApTEVHsZ+0dj74g0nUoCpl/FDi7OAE9jN+36Jlwb7bl YdgBR2jb3KZG8pAZzBIzRrUGg6vJrsdTb6AMqOOgj+/12tcqMpK3J0ZWg/F64e5OSBSW XjQ+iS2n02fYGdIZerSw5LyVfxYH6VWJ30r5EN31yxy033qlDz3qR/viOdH85bkaZTA+ 0UbQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=P5/5E5q5enJY9qi90EW55bAZMcB+ev8f+8aqE/wPd90=; b=lyjhfuTWEo64lNtbrZRDWP7VH+LeaG+ZwwpztSUEdoXKK2lGbGEP4oEa7iNMNwXXme olJdNhzfKE3Y01FlxAmD7g+LoojwTjeAH1XKI/O3u5Twn9yG1CyEXjqd1nMixzRcBpf5 snNeK5jc6MRd6ASlLnBL5fB0n17b2oJzEBIETYijZD6aGSQMrWhYf5+Opr4Fq6tnZ/Ah XUqLAHY7oJt1KQkJ/zHs8LoG8xaX2VuDHTmd0WXk0sFpoPMTfuJTHCBf8jm+6SFlYd4P m2QJqpqa8vnmkaLHcPMznNGr+gbHSz6fjBKHwWn3xxhzm+jzS7yQZtpO86bexeeqsx74 x+5Q==
X-Gm-Message-State: APf1xPC7gELi+Zl1chunhAeoJoMihD2jPUpkd1UsVucYPQsQ0HmbjZFV k90d707hoRUiA+/FseUPtWlg1L76
X-Google-Smtp-Source: AH8x2276giFYYX8ldU9bONy/0eIE/Uhm6VNzOfBHRyZd/Jce7Barc/SP06X5ut565utJJhLS3r3WXQ==
X-Received: by 10.99.120.197 with SMTP id t188mr9532270pgc.358.1519682192271;  Mon, 26 Feb 2018 13:56:32 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:59d9:6f72:9685:4ce6? ([2601:647:4700:1280:59d9:6f72:9685:4ce6]) by smtp.gmail.com with ESMTPSA id 205sm19556252pfy.117.2018.02.26.13.56.31 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 13:56:31 -0800 (PST)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
From: Mahesh Jethanandani 
In-Reply-To: 
Date: Mon, 26 Feb 2018 14:02:19 -0800
Cc: "netmod@ietf.org" , "draft-ietf-netmod-acl-model@ietf.org" 
Content-Transfer-Encoding: quoted-printable
Message-Id: <512EE203-D8C7-40FA-BA05-48D240666716@gmail.com>
References: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com> <87y3jf51ed.fsf@nic.cz>   
To: Per Hedeland 
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] derived-from() vs derived-from-or-self() in acl model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 21:56:35 -0000

> On Feb 26, 2018, at 1:31 PM, Per Hedeland  wrote:
>=20
> On 2018-02-26 20:20, Mahesh Jethanandani wrote:
>>> On Feb 26, 2018, at 9:01 AM, Per Hedeland > wrote:
>>>=20
>>> [Adding Cc todraft-ietf-netmod-acl-model@ietf.org =
]
>>>=20
>>> On 2018-02-26 14:24, Ladislav Lhotka wrote:
>>>> Per Hedeland > writes:
>>>>=20
>>>>> Hi,
>>>>>=20
>>>>> A customer of ours using one of the draft versions of the
>>>>> ietf-access-control-list module reported that it was not possible =
to
>>>>> configure an ethernet ace with type acl:eth-acl-type, due to the
>>>>> derived-from() in
>>>>>=20
>>>>>              container eth {
>>>>>                when "derived-from(../../../../type, " +
>>>>>                     "'acl:eth-acl-type')";
>>>>>                if-feature match-on-eth;
>>>>>                uses pf:acl-eth-header-fields;
>>>>>                description
>>>>>                  "Rule set that matches ethernet headers.";
>>>>>              }
>>>>>=20
>>>>> evaluating to "false". I pointed out that this is correct behavior =
of
>>>>> our SW, since acl:eth-acl-type is not derived from =
acl:eth-acl-type, and
>>>>> it would need to be derived-from-or-self() in order to evaluate to
>>>>> "true". I also ventured a guess (not having followed the =
development of
>>>>> the acl model in detail) that the intent was that vendors should =
define
>>>>> their own identities, that actually *were* derived from =
acl:eth-acl-type
>>>>> (and ditto for all the other *-acl-type identities, of course).
>>>>>=20
>>>>> However I'm not at all sure that the guess is correct, and if so =
why
>>>>> this should be *enforced* by excluding the base identity. And =
having a
>>>>> look at the example in section 4.3 of =
draft-ietf-netmod-acl-model-16, it
>>>>> seems to be doing exactly what our customer tried, alhough with
>>>>> ipv4-acl-type:
>>>>>=20
>>>>> 
>>>>>  
>>>>>    
>>>>>      sample-ipv4-acl
>>>>>      ipv4-acl-type
>>>>>      
>>>>>        
>>>>>          rule1
>>>>>          
>>>>>            
>>>>>              
>>>>>                tcp
>>>>>=20
>>>>> As far as I can see, this snippet is invalid for the model, since =
the
>>>>> 'ipv4' container has
>>>>>=20
>>>>>              container ipv4 {
>>>>>                when "derived-from(../../../../type, " +
>>>>>                     "'acl:ipv4-acl-type')";
>>>>>=20
>>>>> - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of =
course
>>>>> there shouldn't be any  element either, but that's another =
thing.)
>>>>>=20
>>>>> So, is it the case that the derived-from()s should actually be
>>>>> derived-from-or-self()s, or is the example wrong?
>>>>=20
>>>> This has to do with the irreflexivity property of identity =
derivation,
>>>> which is, in my view, an unnecessary complication. It would be =
simpler
>>>> but sufficient to define derivation as a reflexive relation, and =
have
>>>> only one "derived-from()" XPath function.
>>>=20
>>> Be that as it may, it is obviously not what RFC 7950 says.
>> I would agree that that is not how I am reading RFC 7950. For now my =
choice is to change all the derived-from() to derived-from-or-self().
>=20
> I think that is a useful change. FWIW, when I actually tried the =
example
> as the payload of an  towards our NETCONF server, I found
> some other problems, which I believe are still relevant with the pull
> request applied:
>=20
> 1) (Aldready mentioned) the  element corresponding to the choice =
in
> the model should not be present (RFC 7950 section 7.9.5).

Removed . Although I have say the tree diagram confused me. It =
identifies l3 as a node with a +=E2=80=94rw next to it, while for ipv4 =
it says +=E2=80=94.

>=20
> 2) "tcp" is not a valid value for the 'protocol' leaf - from
> ietf-packet-fields@2018-02-02.yang:
>=20
>    leaf protocol {
>      type uint8;
>      description
>        "Internet Protocol number. Refers to the protocol of the
>         payload. In IPv6, this field is known as 'next-header.";
>      reference "RFC 719, RFC 2460.";
>    }
>=20
> I.e. it should be "6". And the reference for this leaf, as well as for
> 'length' and 'ttl', should presumably be RFC 791, not RFC 719.

Changed it to 6, and 719 to 791.

>=20
> 3) 11.11.11.1/24 (for 'destination-ipv4-network') and 10.10.10.1/24 =
(for
> 'source-ipv4-network') are not valid (canonical) values for
> inet:ipv4-prefix - from ietf-inet-types.yang:
>=20
>      The canonical format of an IPv4 prefix has all bits of
>      the IPv4 address set to zero that are not part of the
>      IPv4 prefix.";
>=20
> And of course it doesn't make much sense to have bits outside the =
prefix
> length set for a match specification. It seems the pull request =
changes
> these prefixes to RFC 1918 / RFC 5737 space, but those prefixes have
> the same issue.

Made the host part of the network address 0.

>=20
> I'm attaching the output from a  towards our NETCONF =
server
> with these issues fixed (and the derived-from() ->
> derived-from-or-self() change made).

Thanks.

>=20
> --Per
>=20
>>>=20
>>>> Identities that are considered "abstract" should not be =
instantiated, and
>>>> then derived-from() and derived-from-or-self() give the same =
result.
>>>=20
>>> So I guess your take is that the *-acl-type identities derived from
>>> acl:acl-base in the ietf-access-control-list module should be =
considered
>>> "abstract", and thus the example should not use ipv4-acl-type for =
the
>>> 'type' leaf, but instead some other identity derived from
>>> acl:ipv4-acl-type. Do the authors agree?
>>>=20
>>> --Per
>>>=20
>>>> Lada
>>>>=20
>>>>>=20
>>>>> --Per Hedeland
>>>>>=20
>>>>> _______________________________________________
>>>>> netmod mailing list
>>>>> netmod@ietf.org 
>>>>> https://www.ietf.org/mailman/listinfo/netmod
>> Mahesh Jethanandani
>> mjethanandani@gmail.com 
>=20
> 

Mahesh Jethanandani
mjethanandani@gmail.com


From nobody Mon Feb 26 14:14:20 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BCB22126DFB; Mon, 26 Feb 2018 14:14:18 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jWb6vmvl-yDg; Mon, 26 Feb 2018 14:14:17 -0800 (PST)
Received: from bgl-iport-4.cisco.com (bgl-iport-4.cisco.com [72.163.197.28]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0011200B9; Mon, 26 Feb 2018 14:14:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=2149; q=dns/txt; s=iport; t=1519683257; x=1520892857; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to:content-transfer-encoding; bh=/6CAHB2/7ZiwgqHF37gfo75bAAhML1Ih0i13Zz9cdKI=; b=AyTqmYwRwNLGxxp3eM8ApRTk7+d5iN1dcomwasmVu0ZrcyBKWtTmgvk4 H0NVpKxuR6/e1LgsjK2zGF0b9GteTgCWrPkmy2LNGFDdBzTd9CPhO68+R wBLv5HvP9/A63E5HysRFcPoVJ56C8miFL/qa3FeLZqp/lPezkcnLAB77D M=;
X-IronPort-AV: E=Sophos;i="5.47,398,1515456000"; d="scan'208";a="61532923"
Received: from vla196-nat.cisco.com (HELO bgl-core-1.cisco.com) ([72.163.197.24]) by bgl-iport-4.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 26 Feb 2018 22:14:14 +0000
Received: from [10.66.246.15] (syd-vpn-client-246-15.cisco.com [10.66.246.15]) by bgl-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id w1QMECbg001241;  Mon, 26 Feb 2018 22:14:13 GMT
To: Eliot Lear , Mahesh Jethanandani , Kent Watsen 
Cc: "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" , Warren Kumari 
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net> <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com> <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net> <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com> <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com>
From: Joe Clarke 
Organization: Cisco
Message-ID: <5a9866b8-6809-003c-2663-b27ecd373d51@cisco.com>
Date: Mon, 26 Feb 2018 17:14:11 -0500
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com>
Content-Type: text/plain; charset=utf-8
Content-Language: en-US
Content-Transfer-Encoding: 8bit
Archived-At: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 22:14:18 -0000

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 2/26/18 03:15, Eliot Lear wrote:
> 
> 
> On 26.02.18 06:55, Mahesh Jethanandani wrote:
>>> 
>>>> 
>>>> 
>>>> PS: And this is not a shepherd directive, but I found the
>>>> whole "source-port-range-or-operator" syntax clumsy.  I'm
>>>> surprised it didn't look something like:
>>>> 
>>>> OLD   
>>>>  16384 
>>>> 65535  
>>>>  
>>>> 
>>>>   
>>>>  eq 21 
>>>>   
>>>> 
>>>> 
>>>> NEW
>>>> 
>>>>   16384 
>>>> 65535  
>>>> 
>>>>   eq 
>>>> 21  
>>>> 
>>> 
>>> Did you try making the change in the model to see if it work?
>>> It will complain that  is already used within the
>>> container and that it cannot be repeated (for
>>> destination-port).
>>> 
>>>  No, I did not, nor do I intend to get that deep into it.
>>> But I recall that Kristian made the same comment before, and
>>> was making pull requests before, so maybe he can suggest
>>> something?
>> 
>> Kristian’s suggestion requires changing the module. It is not an 
>> editorial change. And that change will have an impact on the MUD 
>> draft, which has been sent for publication.
>> 
> 
> As it happens, we found a bug in our augment statements, and so we
> will need to rev one more time.  If the change can be made quickly,
> I can live with it.

- From an opsawg chair perspective, I am fine with this.  Warren may
want to weigh in from the AD perspective.

Joe
-----BEGIN PGP SIGNATURE-----

iF0EARECAB0WIQTMiWQHc8wChijkr7lvaI+K/hTPhwUCWpSGsQAKCRBvaI+K/hTP
h/NaAKCEhW2WJnfscTPSTlvbDyzsyWfPiACghHZgtMO0sCl49m3NWnLnt126Z1c=
=EEbu
-----END PGP SIGNATURE-----


From nobody Mon Feb 26 14:43:25 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6898012D889 for ; Mon, 26 Feb 2018 14:43:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Level: 
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uygVE9akrA8t for ; Mon, 26 Feb 2018 14:43:21 -0800 (PST)
Received: from aer-iport-1.cisco.com (aer-iport-1.cisco.com [173.38.203.51]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 708D512D82F for ; Mon, 26 Feb 2018 14:43:21 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=265; q=dns/txt; s=iport; t=1519685001; x=1520894601; h=subject:references:from:to:message-id:date:mime-version: in-reply-to:content-transfer-encoding; bh=tM3VrnFNXZgnk3UtRv9qQWozWgYpn1U6tvreg8dxTA0=; b=EtzsCi0/IdO6KrSYLIm1D0AJX7WGDknF68IuG0vv4HkYHOy6esfElJTd um5aYFAOfQlRLdD964ldrXC7IFhgU/N7hm1GqDdTV/G6mtfvia5dexwDZ l65WUaAge+d9FJtQa3tUy7gmvAo2als/+htwTZ2ziqLK8r11Ukiy5XdyC s=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0COAwAwjZRa/xbLJq1eGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYQ1cCiDVIsWjloLgT2NKYhwggIKI4UQAoMdFAECAQEBAQEBAms?= =?us-ascii?q?oQgEBAwcEhFIGIxVRJQImAgJXBg0IAQGFDBCsNIInhHSDfYIUAQEBAQEBBAEBA?= =?us-ascii?q?QEkgQ+ICoIPDIYmA4E4g0WCZQWhYQmHOYxngXIBE2KFBIM/hWqBS45RhySBLzU?= =?us-ascii?q?hgVEzGggbFYJ9CYRSPzcBgUiEMIQXLIIaAQEB?=
X-IronPort-AV: E=Sophos;i="5.47,398,1515456000";  d="scan'208";a="2304892"
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; 26 Feb 2018 22:43:19 +0000
Received: from [10.55.221.36] (ams-bclaise-nitro3.cisco.com [10.55.221.36]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1QMhJJw007192 for ; Mon, 26 Feb 2018 22:43:19 GMT
References: 
From: Benoit Claise 
To: NETMOD Working Group 
X-Forwarded-Message-Id: 
Message-ID: <178d5d81-0568-3a16-edb9-5277db07772c@cisco.com>
Date: Mon, 26 Feb 2018 23:43:19 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Archived-At: 
Subject: [netmod] pyang updated to 1.7.4 and yandump-pro to 17.10.5 and yanglint to 0.14.70
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 22:43:23 -0000

Dear all,

The subject says it all. Please check your module validation. A few 
issues have been solved.
For now, check at http://www.claise.be/IETFYANGPageCompilation.html
Allow an big hour for the results to propagate to yangcatalog.org.

Regards, Benoit


From nobody Mon Feb 26 14:44:31 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D009212D87B; Mon, 26 Feb 2018 14:44:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.911
X-Spam-Level: 
X-Spam-Status: No, score=-1.911 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hk0f1HzmMW4f; Mon, 26 Feb 2018 14:44:28 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3E8B812D82F; Mon, 26 Feb 2018 14:44:28 -0800 (PST)
Received: from pluto.hedeland.org (81-228-155-109-no289.tbcn.telia.com [81.228.155.109]) by mail.tail-f.com (Postfix) with ESMTPSA id 66B871AE0488; Mon, 26 Feb 2018 23:44:27 +0100 (CET)
To: Mahesh Jethanandani 
Cc: "netmod@ietf.org" , "draft-ietf-netmod-acl-model@ietf.org" 
References: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com> <87y3jf51ed.fsf@nic.cz>    <512EE203-D8C7-40FA-BA05-48D240666716@gmail.com>
From: Per Hedeland 
Message-ID: 
Date: Mon, 26 Feb 2018 23:44:27 +0100
User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <512EE203-D8C7-40FA-BA05-48D240666716@gmail.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Language: en-US
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] derived-from() vs derived-from-or-self() in acl model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 22:44:31 -0000

On 2018-02-26 23:02, Mahesh Jethanandani wrote:
> 
> 
>> On Feb 26, 2018, at 1:31 PM, Per Hedeland  wrote:
>>
>> On 2018-02-26 20:20, Mahesh Jethanandani wrote:
>>>> On Feb 26, 2018, at 9:01 AM, Per Hedeland > wrote:
>>>>
>>>> [Adding Cc todraft-ietf-netmod-acl-model@ietf.org ]
>>>>
>>>> On 2018-02-26 14:24, Ladislav Lhotka wrote:
>>>>> Per Hedeland > writes:
>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> A customer of ours using one of the draft versions of the
>>>>>> ietf-access-control-list module reported that it was not possible to
>>>>>> configure an ethernet ace with type acl:eth-acl-type, due to the
>>>>>> derived-from() in
>>>>>>
>>>>>>               container eth {
>>>>>>                 when "derived-from(../../../../type, " +
>>>>>>                      "'acl:eth-acl-type')";
>>>>>>                 if-feature match-on-eth;
>>>>>>                 uses pf:acl-eth-header-fields;
>>>>>>                 description
>>>>>>                   "Rule set that matches ethernet headers.";
>>>>>>               }
>>>>>>
>>>>>> evaluating to "false". I pointed out that this is correct behavior of
>>>>>> our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
>>>>>> it would need to be derived-from-or-self() in order to evaluate to
>>>>>> "true". I also ventured a guess (not having followed the development of
>>>>>> the acl model in detail) that the intent was that vendors should define
>>>>>> their own identities, that actually *were* derived from acl:eth-acl-type
>>>>>> (and ditto for all the other *-acl-type identities, of course).
>>>>>>
>>>>>> However I'm not at all sure that the guess is correct, and if so why
>>>>>> this should be *enforced* by excluding the base identity. And having a
>>>>>> look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
>>>>>> seems to be doing exactly what our customer tried, alhough with
>>>>>> ipv4-acl-type:
>>>>>>
>>>>>> 
>>>>>>   
>>>>>>     
>>>>>>       sample-ipv4-acl
>>>>>>       ipv4-acl-type
>>>>>>       
>>>>>>         
>>>>>>           rule1
>>>>>>           
>>>>>>             
>>>>>>               
>>>>>>                 tcp
>>>>>>
>>>>>> As far as I can see, this snippet is invalid for the model, since the
>>>>>> 'ipv4' container has
>>>>>>
>>>>>>               container ipv4 {
>>>>>>                 when "derived-from(../../../../type, " +
>>>>>>                      "'acl:ipv4-acl-type')";
>>>>>>
>>>>>> - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
>>>>>> there shouldn't be any  element either, but that's another thing.)
>>>>>>
>>>>>> So, is it the case that the derived-from()s should actually be
>>>>>> derived-from-or-self()s, or is the example wrong?
>>>>>
>>>>> This has to do with the irreflexivity property of identity derivation,
>>>>> which is, in my view, an unnecessary complication. It would be simpler
>>>>> but sufficient to define derivation as a reflexive relation, and have
>>>>> only one "derived-from()" XPath function.
>>>>
>>>> Be that as it may, it is obviously not what RFC 7950 says.
>>> I would agree that that is not how I am reading RFC 7950. For now my choice is to change all the derived-from() to derived-from-or-self().
>>
>> I think that is a useful change. FWIW, when I actually tried the example
>> as the payload of an  towards our NETCONF server, I found
>> some other problems, which I believe are still relevant with the pull
>> request applied:
>>
>> 1) (Aldready mentioned) the  element corresponding to the choice in
>> the model should not be present (RFC 7950 section 7.9.5).
> 
> Removed . Although I have say the tree diagram confused me. It identifies l3 as a node with a +rw next to it, while for ipv4 it says +.

Hm... - the tree diagram has

         |        |  +--rw (l3)?
         |        |  |  +--:(ipv4)
         |        |  |  |  +--rw ipv4 {match-on-ipv4}?

Where "(l3)?" is the choice, ":(ipv4)" is the case (not present in the
YANG module since it makes use of the "shorthand" per RFC 7950 section
7.9.2), and "ipv4" is the container (with its if-feature). The
latest/last tree diagram draft (-06) doesn't say anything in particular
about  for choice/case, so it would seem that it should be "rw"
for both choice and case in configuration data. I.e. the case should be
shown as

         |        |  |  +--rw :(ipv4)

Latest pyang from github shows a 'case' as the first variant above
though, i.e. without both  and whitespace before the name. I
guess Martin will fix...

--Per

>> 2) "tcp" is not a valid value for the 'protocol' leaf - from
>> ietf-packet-fields@2018-02-02.yang:
>>
>>     leaf protocol {
>>       type uint8;
>>       description
>>         "Internet Protocol number. Refers to the protocol of the
>>          payload. In IPv6, this field is known as 'next-header.";
>>       reference "RFC 719, RFC 2460.";
>>     }
>>
>> I.e. it should be "6". And the reference for this leaf, as well as for
>> 'length' and 'ttl', should presumably be RFC 791, not RFC 719.
> 
> Changed it to 6, and 719 to 791.
> 
>>
>> 3) 11.11.11.1/24 (for 'destination-ipv4-network') and 10.10.10.1/24 (for
>> 'source-ipv4-network') are not valid (canonical) values for
>> inet:ipv4-prefix - from ietf-inet-types.yang:
>>
>>       The canonical format of an IPv4 prefix has all bits of
>>       the IPv4 address set to zero that are not part of the
>>       IPv4 prefix.";
>>
>> And of course it doesn't make much sense to have bits outside the prefix
>> length set for a match specification. It seems the pull request changes
>> these prefixes to RFC 1918 / RFC 5737 space, but those prefixes have
>> the same issue.
> 
> Made the host part of the network address 0.
> 
>>
>> I'm attaching the output from a  towards our NETCONF server
>> with these issues fixed (and the derived-from() ->
>> derived-from-or-self() change made).
> 
> Thanks.
> 
>>
>> --Per
>>
>>>>
>>>>> Identities that are considered "abstract" should not be instantiated, and
>>>>> then derived-from() and derived-from-or-self() give the same result.
>>>>
>>>> So I guess your take is that the *-acl-type identities derived from
>>>> acl:acl-base in the ietf-access-control-list module should be considered
>>>> "abstract", and thus the example should not use ipv4-acl-type for the
>>>> 'type' leaf, but instead some other identity derived from
>>>> acl:ipv4-acl-type. Do the authors agree?
>>>>
>>>> --Per
>>>>
>>>>> Lada
>>>>>
>>>>>>
>>>>>> --Per Hedeland
>>>>>>
>>>>>> _______________________________________________
>>>>>> netmod mailing list
>>>>>> netmod@ietf.org 
>>>>>> https://www.ietf.org/mailman/listinfo/netmod
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com 
>>
>> 
> 
> Mahesh Jethanandani
> mjethanandani@gmail.com
> 


From nobody Mon Feb 26 15:34:57 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D825212D951 for ; Mon, 26 Feb 2018 15:34:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RdKVCs5wxgmn for ; Mon, 26 Feb 2018 15:34:54 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 5016212D950 for ; Mon, 26 Feb 2018 15:34:54 -0800 (PST)
Received: from pip.chopps.org (mobile-166-170-21-160.mycingular.net [166.170.21.160]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id E5BF462A6F; Mon, 26 Feb 2018 23:34:52 +0000 (UTC)
References: 
User-agent: mu4e 0.9.19; emacs 25.3.1
From: Christian Hopps 
To: joel jaeggli 
Cc: NETMOD Working Group 
Message-ID: <87d10rba3b.fsf@chopps.org>
In-reply-to: 
Date: Mon, 26 Feb 2018 18:34:52 -0500
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] feedback draft-rtgyangdt-netmod-module-tags -> draft-ietf-netmod-module-tags
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 23:34:56 -0000

joel jaeggli  writes:

> introduction / abstract should capture the problem module tags are
> attempting to solve succinctly
>
> Robert Wilton's criticism of the approach is well taken; the use of tags
> as regular configuration (his approach) vs the treatment of tags as
> exceptions (how we understand them as proposed). and seems like a ket
> architectural consideration in advancing this draft.

Hi Joel,

Yes, this seemed to have a good consensus (including myself :) and have the changes ready to go, just wanted to push the same version as proposed for adoption first.

Thanks,
Chris.

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


From nobody Mon Feb 26 15:44:28 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB61212D94E; Mon, 26 Feb 2018 15:44:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level: 
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FoO-Xm4JjfeX; Mon, 26 Feb 2018 15:44:19 -0800 (PST)
Received: from mail-pl0-x22c.google.com (mail-pl0-x22c.google.com [IPv6:2607:f8b0:400e:c01::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CFA18124235; Mon, 26 Feb 2018 15:44:18 -0800 (PST)
Received: by mail-pl0-x22c.google.com with SMTP id s13so10244495plq.6; Mon, 26 Feb 2018 15:44:18 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=pO+2jiq4J132/HzXs6XTJ45kZQJqfPHMm/6JnYvn1cM=; b=CMYCwtOjsap5+64WAgrnDXi3RIRJ0T3/TJlgIw1/6bDhaP+uhjC6sGiKtyD8ZNkQda OpSs062pfxJTQ+itGA/55LalYs2pwjLFdvt4Pt5K8KpzoZgEdc8jdopKB+0ykrLKePaR DZs3S1g9EWGaUWGAKp1lgJf5bsN+4cgP/gcG78FCk9G8BaLSFRdnJpaMrTi+iG1zozHG 294x92RE2VXaqYGe537Jb+5kPBeB9zgQhy+exT8NZNqmIf/a927Myes+JXTaKp+ra8Mk pRXIoRiS8CRaavY3V9Z5WEvwJLPK+yzLr/CPVZdCFZ8U+OY9V7LCrWxYmhMcgprW0Cqy g5PA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=pO+2jiq4J132/HzXs6XTJ45kZQJqfPHMm/6JnYvn1cM=; b=ntGyWu9DmHsLBK2o+5SkfyD6ohV2Y9RIcVHP8FVdZeRANdUA/HfwKVpTmOojXwm50x 3d/MSpHfHT4uNjxM15Tyr2w3HnQqxPDnS7dXu/7HxjPuy+/7iLu12OggmnLcL8fnvwIb Sl9N/wO/bumDVPpVuFoUnaRAHvwM0BOlbeK40MonfFO8zeEEaZlcf6+gezBMhXq+rU5E jEg19SpWcAsXRt+lFgsellxZvS157/D4y/yYkdPVBif1Ws4UynRjjmYQvUFGNxGtBoEw ycNTjVjzEGKEwdOb+EMOwFBYDBlY2jqTOQBnY3I5jShfP7XZv9qmjeJo43decXlAKl0w WwVw==
X-Gm-Message-State: APf1xPAeoEsgWGLdylRU0htl3Tl2F+3Rv6tys86NHycKzcINMbWNTvSh 0ZnZtr/AxJKVETZBbkjhHCVEaz6beK0=
X-Google-Smtp-Source: AH8x2278o3syJayqS4oNS5zi5t3tij2oc0WYAwUUsZ7tTN6686k24TFSySBRRx1idEPFw38GMClXSw==
X-Received: by 2002:a17:902:694c:: with SMTP id k12-v6mr12046576plt.133.1519688658186;  Mon, 26 Feb 2018 15:44:18 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:59d9:6f72:9685:4ce6? ([2601:647:4700:1280:59d9:6f72:9685:4ce6]) by smtp.gmail.com with ESMTPSA id l66sm6020940pfc.183.2018.02.26.15.44.16 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 26 Feb 2018 15:44:17 -0800 (PST)
From: Mahesh Jethanandani 
Message-Id: 
Content-Type: multipart/alternative; boundary="Apple-Mail=_12AA167D-6630-4103-853F-66C94EB422B8"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Mon, 26 Feb 2018 15:50:05 -0800
In-Reply-To: <98935845-4f6d-230a-9aba-7eff7ed0cef4@cisco.com>
Cc: Kent Watsen , NETMOD WG , Robert Wilton 
To: NETCONF WG 
References:  <4a6b7077-a721-6d09-b594-44f9760e58a1@cisco.com> <14390982-A1C2-40E5-AEA1-B03B02E8ACEC@juniper.net> <3d3d9e35-b9f5-aefb-a291-a25549ed9ad5@cisco.com> <87y3jtjob5.fsf@nic.cz> <11a7c859-6d8c-2f67-9918-b3aa5cc77dfa@cisco.com> <87po55ne3j.fsf@nic.cz> <98935845-4f6d-230a-9aba-7eff7ed0cef4@cisco.com>
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] [Netconf] LC on YANG Library (bis)
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Mon, 26 Feb 2018 23:44:22 -0000

--Apple-Mail=_12AA167D-6630-4103-853F-66C94EB422B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

This officially closes the LC on YANG Library bis draft. I know that =
separately there has been a YANG Doctors review of this draft.

Authors, please post an updated draft addressing the comments received =
during LC and other reviews on the document. I will then do a =
shepherd=E2=80=99s writeup and send it for publication.

Thanks.

Mahesh //as shepherd

> On Feb 16, 2018, at 8:04 AM, Robert Wilton  wrote:
>=20
>=20
>=20
> On 16/02/2018 15:33, Ladislav Lhotka wrote:
>> Robert Wilton  writes:
>>=20
>>> Hi Lada,
>>>=20
>>>=20
>>> On 16/02/2018 09:06, Ladislav Lhotka wrote:
>>>> Robert Wilton  writes:
>>>>=20
>>>>> I should add, as a contributor, I have read this document and =
think that
>>>>> is ready for advancement.
>>>>>=20
>>>>> I have three minor comments:
>>>>>=20
>>>>> 1) module "feature" in YANG library is a leaf-list, but currently =
it is
>>>>> a list in YANG libary bis. I suspect that this is due to one of =
the
>>>>> incarnations when it contained additional information.  I think =
that we
>>>>> should revert it back to being a leaf list for consistency.
>>>>>=20
>>>>> 2) Lada recommended that module "deviation" be made a leaf-list. I =
also
>>>>> support changing this for consistency with "feature" above, but =
don't
>>>>> feel too strongly on this one.
>>>> I agree to have both as leaf-lists.
>>>>=20
>>>>> 3) I think the "modules" list is also allowed to included modules =
that
>>>>> don't actually contain any nodes that require implementation.  =
Hence, it
>>>>> might be useful of the "modules" description statement explicitly =
stated
>>>>> this.  I.e. perhaps something like:
>>>>>=20
>>>>> "This list may contain modules that do not contain any schema =
nodes that
>>>>> require implementation.  For example, it could contain a module =
that
>>>>> only defines types and not any data nodes, RPCs, actions, =
notifications,
>>>>> or deviations."
>>>> Hmm, such modules belong to the other list "import-only-modules", =
don't
>>>> they?
>>> So my reasoning is that either is valid.
>>>=20
>>> I.e. a module being listed under "modules" means that it implements =
all
>>> data nodes, RPCs, actions, notifications, deviations, etc.  If a =
module
>>> doesn't contain any data nodes, RPCs, actions, notifications,
>>> deviations, etc then it is trivially implemented :-)
>> OK, so if a module contains only groupings and typedefs, it can =
appear
>> either in "modules" or in "import-only-modules", and the effect is =
the
>> same, right?
> Yes.
>=20
>>=20
>> This sounds reasonable.
>>=20
>>> As an aside, RFC 7950 states in 5.6.5:
>>>=20
>>>   A server implements a module if it implements the module's data
>>>     nodes, RPCs, actions, notifications, and deviations.
>>>=20
>>>=20
>>> I wonder whether identities shouldn't also be on this list, since
>>> section 9.10.2 states:
>> Yes, and extensions as well.
>>=20
>> Lada
> Thanks,
> Rob
>=20
>>=20
>>> On a particular server, the valid values are further restricted
>>> to the set of identities defined in the modules implemented by the =
server.
>>>=20
>>>=20
>>> Thanks,
>>> Rob
>>>=20
>>>=20
>>>> Lada
>>>>=20
>>>>> Thanks,
>>>>> Rob
>>>>>=20
>>>>>=20
>>>>> On 02/02/2018 13:51, Kent Watsen wrote:
>>>>>> As co-author, I am not aware of any IPR related to this document.
>>>>>>=20
>>>>>> As a contributor, I have read this document and think that it is =
ready
>>>>>> for advancement.
>>>>>>=20
>>>>>> Kent
>>>>>>=20
>>>>>> On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
>>>>>>  on =
behalf
>>>>>> of rwilton@cisco.com > wrote:
>>>>>>=20
>>>>>> I am not aware of any IPR related to this document.
>>>>>>=20
>>>>>> Thanks,
>>>>>> Rob
>>>>>>=20
>>>>>> On 01/02/2018 18:59, Mahesh Jethanandani wrote:
>>>>>>=20
>>>>>>      WG,
>>>>>>=20
>>>>>>      The authors of rfc7895bis have indicated that they believe =
the
>>>>>>      document is ready for LC[1].
>>>>>>=20
>>>>>>      This starts a two week LC on the draft
>>>>>>      =
.
>>>>>>      The LC will end on February 15.
>>>>>>=20
>>>>>>      Please send your comments on this thread. Reviews of the =
document,
>>>>>>      and statement of support are particularly helpful to the =
authors.
>>>>>>      If you have concerns about the document, please state those =
too.
>>>>>>=20
>>>>>>      Authors please indicate if you are aware of any IPR on the =
document.
>>>>>>=20
>>>>>>      Thanks.
>>>>>>=20
>>>>>>      [1]
>>>>>>      =
https://www.ietf.org/mail-archive/web/netconf/current/msg13980.html
>>>>>>      =

>>>>>>=20
>>>>>>      Mahesh & Kent
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>>>      _______________________________________________
>>>>>>=20
>>>>>>      Netconf mailing list
>>>>>>=20
>>>>>>      Netconf@ietf.org 
>>>>>>=20
>>>>>>      https://www.ietf.org/mailman/listinfo/netconf
>>>>>>      =

>>>>>>=20
>>>>>>=20
>>>>>>=20
>>>>> _______________________________________________
>>>>> Netconf mailing list
>>>>> Netconf@ietf.org
>>>>> https://www.ietf.org/mailman/listinfo/netconf
>>> _______________________________________________
>>> Netconf mailing list
>>> Netconf@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netconf




--Apple-Mail=_12AA167D-6630-4103-853F-66C94EB422B8
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

This =
officially closes the LC on YANG Library bis draft. I know that =
separately there has been a YANG Doctors review of this draft.

Authors, please post an =
updated draft addressing the comments received during LC and other =
reviews on the document. I will then do a shepherd=E2=80=99s writeup and =
send it for publication.

Thanks.

Mahesh //as shepherd

On Feb =
16, 2018, at 8:04 AM, Robert Wilton <rwilton@cisco.com> =
wrote:


On 16/02/2018 15:33, Ladislav Lhotka =
wrote:
Robert Wilton <rwilton@cisco.com> writes:

Hi Lada,

On 16/02/2018 09:06, Ladislav Lhotka =
wrote:
Robert Wilton =
<rwilton@cisco.com> writes:

I should add, as a =
contributor, I have read this document and think that
is =
ready for advancement.

I have three minor =
comments:

1) module "feature" in YANG =
library is a leaf-list, but currently it is
a list in YANG =
libary bis. I suspect that this is due to one of the
incarnations when it contained additional information.  =
I think that we
should revert it back to being a leaf list =
for consistency.

2) Lada recommended that =
module "deviation" be made a leaf-list. I also
support =
changing this for consistency with "feature" above, but don't
feel too strongly on this one.
I =
agree to have both as leaf-lists.

3) I think the "modules" list is also allowed =
to included modules that
don't actually contain any nodes =
that require implementation.  Hence, it
might be =
useful of the "modules" description statement explicitly stated
this.  I.e. perhaps something like:

"This list may contain modules that do not contain any schema =
nodes that
require implementation.  For example, it =
could contain a module that
only defines types and not any =
data nodes, RPCs, actions, notifications,
or =
deviations."
Hmm, such modules belong to the =
other list "import-only-modules", don't
they?
So my reasoning is that either is valid.

I.e. a module being listed under "modules" =
means that it implements all
data nodes, RPCs, actions, =
notifications, deviations, etc.  If a module
doesn't =
contain any data nodes, RPCs, actions, notifications,
deviations, etc then it is trivially implemented :-)
OK, so if a module contains only groupings and =
typedefs, it can appear
either in "modules" or in =
"import-only-modules", and the effect is the
same, =
right?
Yes.


This sounds =
reasonable.

As an aside, RFC 7950 states in 5.6.5:

  A server implements a module if it implements the =
module's data
    nodes, RPCs, =
actions, notifications, and deviations.


I wonder whether identities shouldn't also be on this list, =
since
section 9.10.2 states:
Yes,=
 and extensions as well.

Lada
Thanks,
Rob

On a particular server, the valid values are =
further restricted
to the set of identities defined in the =
modules implemented by the server.


Thanks,
Rob


Lada

Thanks,
Rob


On 02/02/2018 =
13:51, Kent Watsen wrote:
As co-author, I am not aware of any IPR related to this =
document.

As a contributor, I have read =
this document and think that it is ready
for =
advancement.

Kent

On 2/2/18, 4:30 AM, "Netconf on behalf of Robert Wilton"
<netconf-bounces@ietf.org <mailto:netconf-bounces@ietf.org> on behalf
of rwilton@cisco.com <mailto:rwilton@cisco.com>> wrote:

I am not aware of any IPR related to this document.

Thanks,
Rob

On 01/02/2018 18:59, Mahesh Jethanandani wrote:

     WG,

     The authors of =
rfc7895bis have indicated that they believe the
     document is ready for LC[1].

     This starts a =
two week LC on the draft
     <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__tools.ie=
tf.org_html_draft-2Dietf-2Dnetconf-2Drfc7895bis-2D04&d=3DDwMD-g&c=3D=
HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yh=
qn2gsBYaGTvjISlaJdcZo&m=3Dfi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&=
amp;s=3DMqbVljnYqIk9w78kcfp7oUqGR-qVoNV90njyTwLAdpc&e=3D>.
     The LC will end on February =
15.

     Please =
send your comments on this thread. Reviews of the document,
     and statement of support are =
particularly helpful to the authors.
     If you have concerns about the =
document, please state those too.

     Authors please indicate if you =
are aware of any IPR on the document.

     Thanks.

     [1]
     https://www.ietf.org/mail-archive/web/netconf/current/msg13980.=
html
     <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mail-2Darchive_web_netconf_current_msg13980.html&d=3DDwMD-g&c=
=3DHAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH=
7Yhqn2gsBYaGTvjISlaJdcZo&m=3Dfi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCr=
fE&s=3DXhRSSTWifO-SkPi2CWK5Z5aUni2F1qRQ8Moj7T7gI-Y&e=3D>
     Mahesh & =
Kent




     _________________________________=
______________

     Netconf mailing list

     Netconf@ietf.org <mailto:Netconf@ietf.org>

     https://www.ietf.org/mailman/listinfo/netconf
     <https://urldefense.proofpoint.com/v2/url?u=3Dhttps-3A__www.ietf=
.org_mailman_listinfo_netconf&d=3DDwMD-g&c=3DHAkYuh63rsuhr6Scbfh0U=
jBXeMK-ndb3voDTXcWzoCI&r=3D9zkP0xnJUvZGJ9EPoOH7Yhqn2gsBYaGTvjISlaJdcZo=
&m=3Dfi_opjj4kio7eufRXSQSi8dSjJNlkVDo8a1F0zsCrfE&s=3DmcDF-v5I4epgs=
uWLHvr32pZ5mRonROKN8zpKcZWBC0o&e=3D>



_______________________________________________Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf
_____________________________________=
__________
Netconf mailing list
Netconf@ietf.org
https://www.ietf.org/mailman/listinfo/netconf






=

--Apple-Mail=_12AA167D-6630-4103-853F-66C94EB422B8--


From nobody Mon Feb 26 22:44:30 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2249A120454; Mon, 26 Feb 2018 22:44:29 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q1BF87GXZDDH; Mon, 26 Feb 2018 22:44:26 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id 7E1B41200B9; Mon, 26 Feb 2018 22:44:25 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 46AF41820412; Tue, 27 Feb 2018 07:41:11 +0100 (CET)
Received: from localhost (37-48-39-170.tmcz.cz [37.48.39.170]) by trail.lhotka.name (Postfix) with ESMTPSA id 64B2A18203DE; Tue, 27 Feb 2018 07:41:08 +0100 (CET)
From: Ladislav Lhotka 
To: Per Hedeland , "netmod\@ietf.org" 
Cc: "draft-ietf-netmod-acl-model\@ietf.org" 
In-Reply-To: 
References: <35213d61-08b4-ce5b-f7b2-251d2d5c2e70@tail-f.com> <87y3jf51ed.fsf@nic.cz> 
Mail-Followup-To: Per Hedeland , "netmod\@ietf.org" , "draft-ietf-netmod-acl-model\@ietf.org" 
Date: Tue, 27 Feb 2018 07:44:18 +0100
Message-ID: <87371nq6d9.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] derived-from() vs derived-from-or-self() in acl model
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 06:44:29 -0000

Per Hedeland  writes:

> [Adding Cc to draft-ietf-netmod-acl-model@ietf.org]
>
> On 2018-02-26 14:24, Ladislav Lhotka wrote:
>> Per Hedeland  writes:
>> 
>>> Hi,
>>>
>>> A customer of ours using one of the draft versions of the
>>> ietf-access-control-list module reported that it was not possible to
>>> configure an ethernet ace with type acl:eth-acl-type, due to the
>>> derived-from() in
>>>
>>>                container eth {
>>>                  when "derived-from(../../../../type, " +
>>>                       "'acl:eth-acl-type')";
>>>                  if-feature match-on-eth;
>>>                  uses pf:acl-eth-header-fields;
>>>                  description
>>>                    "Rule set that matches ethernet headers.";
>>>                }
>>>
>>> evaluating to "false". I pointed out that this is correct behavior of
>>> our SW, since acl:eth-acl-type is not derived from acl:eth-acl-type, and
>>> it would need to be derived-from-or-self() in order to evaluate to
>>> "true". I also ventured a guess (not having followed the development of
>>> the acl model in detail) that the intent was that vendors should define
>>> their own identities, that actually *were* derived from acl:eth-acl-type
>>> (and ditto for all the other *-acl-type identities, of course).
>>>
>>> However I'm not at all sure that the guess is correct, and if so why
>>> this should be *enforced* by excluding the base identity. And having a
>>> look at the example in section 4.3 of draft-ietf-netmod-acl-model-16, it
>>> seems to be doing exactly what our customer tried, alhough with
>>> ipv4-acl-type:
>>>
>>> 
>>>    
>>>      
>>>        sample-ipv4-acl
>>>        ipv4-acl-type
>>>        
>>>          
>>>            rule1
>>>            
>>>              
>>>                
>>>                  tcp
>>>
>>> As far as I can see, this snippet is invalid for the model, since the
>>> 'ipv4' container has
>>>
>>>                container ipv4 {
>>>                  when "derived-from(../../../../type, " +
>>>                       "'acl:ipv4-acl-type')";
>>>
>>> - and ipv4-acl-type is *not* derived from ipv4-acl-type. (Of course
>>> there shouldn't be any  element either, but that's another thing.)
>>>
>>> So, is it the case that the derived-from()s should actually be
>>> derived-from-or-self()s, or is the example wrong?
>> 
>> This has to do with the irreflexivity property of identity derivation,
>> which is, in my view, an unnecessary complication. It would be simpler
>> but sufficient to define derivation as a reflexive relation, and have
>> only one "derived-from()" XPath function.
>
> Be that as it may, it is obviously not what RFC 7950 says.

Of course not, but something is wrong if we need to have this discussion.

>
>> Identities that are considered "abstract" should not be instantiated, and
>> then derived-from() and derived-from-or-self() give the same result.
>
> So I guess your take is that the *-acl-type identities derived from
> acl:acl-base in the ietf-access-control-list module should be considered
> "abstract", and thus the example should not use ipv4-acl-type for the
> 'type' leaf, but instead some other identity derived from
> acl:ipv4-acl-type. Do the authors agree?

I don't think it is abstract, so derived-from() should be replaced
derived-from-or-self(). My point is that this can be done *everywhere*,
so the former function is pretty much useless. But then,
derived-from-or-self is ridiculously long, and the existence of two
functions is confusing.

Lada

>
> --Per
>
>> Lada
>> 
>>>
>>> --Per Hedeland
>>>
>>> _______________________________________________
>>> netmod mailing list
>>> netmod@ietf.org
>>> https://www.ietf.org/mailman/listinfo/netmod
>> 
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Mon Feb 26 23:02:37 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 201C8124BAC for ; Mon, 26 Feb 2018 23:02:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level: 
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 3TcG7uKj8Avv for ; Mon, 26 Feb 2018 23:02:34 -0800 (PST)
Received: from trail.lhotka.name (trail.lhotka.name [77.48.224.143]) by ietfa.amsl.com (Postfix) with ESMTP id CDDB5124B18 for ; Mon, 26 Feb 2018 23:02:33 -0800 (PST)
Received: by trail.lhotka.name (Postfix, from userid 109) id 7D42B1820412; Tue, 27 Feb 2018 07:59:20 +0100 (CET)
Received: from localhost (37-48-39-170.tmcz.cz [37.48.39.170]) by trail.lhotka.name (Postfix) with ESMTPSA id 6857518203DE; Tue, 27 Feb 2018 07:59:18 +0100 (CET)
From: Ladislav Lhotka 
To: Christian Hopps , Martin Bjorklund 
Cc: netmod@ietf.org
In-Reply-To: <87efl7bn4c.fsf@chopps.org>
References: <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87lgfg9ded.fsf@chopps.org> <20180226.160921.622063322182936097.mbj@tail-f.com> <87efl7bn4c.fsf@chopps.org>
Mail-Followup-To: Christian Hopps , Martin Bjorklund , netmod@ietf.org
Date: Tue, 27 Feb 2018 08:02:30 +0100
Message-ID: <87zi3uq5ix.fsf@nic.cz>
MIME-Version: 1.0
Content-Type: text/plain
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 07:02:36 -0000

Christian Hopps  writes:

> Martin Bjorklund  writes:
>
>> Hi,
>>
>> Christian Hopps  wrote:
>>>
>>> Hi Rob,
>>>
>>> You do realize that no-one trying to actually deploy and run networks
>>> cares about live-discovery of different schema per datastore for the
>>> same mount point right? Like 99.999% of the clients know where things
>>> are supposed to reside and expect them to be there.
>>
>> But then why advertise anything at all?   We can do a *much* simpler
>> solution by just having the mountpoint extension, and nothing else.
>> Clients will know what to find anyway.
>
> That was the idea Lou and I brought up over 2 *years* ago, yes. :)

We can and should still do that for the inline case, even after
publishing -08.

>
> But good points were made for something more general and powerful, and
> we all agreed with those, so..

This is not true, I have never agreed to mixing up inline and use-schema
cases. Both are useful but they should be separate.

The initial virtual interim decided to use Martin's combined proposal
and most of my subsequent objections were rejected on the basis of that
decision. That's why I hate discussing complicated things in virtual
interims - it it a safe and fast way to reach wrong decisions.

Lada

>
>> My experience, which may differ from yours, is that correct knowledge
>> about the devices' datamodels and revisions is crucial for correct
>> implementation of automation of network services.  The application
>> programmer can program the intent for some set of data models, and
>> then the orchestrator can automatically decide what to do for a given
>> device depending on which data models it advertises.
>
> and that's why we have a module list present in the work now ready to publish. It's enough for now. Perfect is killing good enough here.
>
> Thanks,
> Chris.
>
>>
>>
>>
>> /martin
>>
>>
>>
>>
>> At most (although
>>> still not common) they may want to know what modules are supported
>>> under a mount point. What your talking about is a severe edge case
>>> that apparently has achieved extreme importance in a very small group
>>> of people's views.
>>>
>>> Thanks,
>>> Chris.
>>>
>>> Robert Wilton  writes:
>>>
>>> > Hi Chris,
>>> >
>>> > I've got no desire or intent to try and slow down the NI and LNE
>>> > drafts, or any
>>> > that depend on them. I actually agree that this is critically
>>> > important that
>>> > IETF gets modules standardized/finished so that everyone can use them.
>>> >
>>> > However, ...
>>> >
>>> > YLbis has quite a different structure to YL. The main part of this
>>> > change was
>>> > to support NMDA, the other part of this change was to better support
>>> > things like
>>> > SM, or YANG packages.
>>> >
>>> > I don't think that there is a clean, backwards compatible, way to go
>>> > from the
>>> > YANG module in SM -08 to one that is going to work well with YLbis and
>>> > other
>>> > YLbis extensions/augmentations that seem to be coming down the
>>> > line. Given what
>>> > we know now, I believe that the correct medium/long term structure for
>>> > the SM
>>> > YANG module, taking YLbis into account, is the one proposed in pre09,
>>> > because it
>>> > directly augments the YLbis structure, and hence any future
>>> > augmentations to
>>> > YLbis should automatically extend to SM mounted schema as well.
>>> >
>>> > I think that the likely future technical issues with the -08 module
>>> > will be:
>>> > - supporting NMDA in a clean consistent way
>>> > - adding in support for SemVer
>>> > - additional capability reporting as an augmentation to YANG library
>>> >
>>> > So, if -08 proceeds as is, then it seems to me like one of three
>>> > things will
>>> > need to happen:
>>> > 1) Their will need to be a non backwards compatible update to the SM
>>> > model that
>>> > is the same/similar to pre09.
>>> > 2) YLbis and SM diverge, stuff that augments YLbis doesn't work for
>>> > explicitly
>>> > mounted schema.
>>> > 3) We accrue technical debt, implementations need to support two YL
>>> > module
>>> > structures, the one in SM and the one in YLbis, and future extensions
>>> > need to
>>> > augment both the SM structure and YLbis structure.
>>> >
>>> > I don't like the idea of (2) or (3), but I don't know if others will
>>> > find (1)
>>> > acceptable.
>>> >
>>> > But I do agree that we are just going round in circles on this:
>>> > - Using the pre09 structure is not acceptable to some folks
>>> > - Publishing a draft with both -08 and pre09 structure is liked by even
>>> > - less
>>> > folks.
>>> >
>>> > Perhaps publishing -08 is the only option. My hope is that the WG will
>>> > support
>>> > somebody subsequently doing solution (1), otherwise it seems like a
>>> > missed
>>> > opportunity to get this right.
>>> >
>>> > Thanks,
>>> > Rob
>>> >
>>> >
>>> > On 24/02/2018 13:54, Christian Hopps wrote:
>>> >> My position,
>>> >>
>>> >> It may be the case that there's even a better cleaner solution;
>>> >> however, it's
>>> >> simply too late for major modifications to this work that don't
>>> >> actually
>>> >> address functional failures. The draft as proposed works for the
>>> >> people who
>>> >> need to get work done.
>>> >>
>>> >> We have multiple pending RFCs - MISREF on this document. These RFCs
>>> >> would have
>>> >> to be pulled from the RFC EDITOR queue, and reworked to be compliant
>>> >> again,
>>> >> and this very well could lead to discovering issues with your new
>>> >> proposal.
>>> >> Any new issues discovered in either the pending RFCs *or* in the new
>>> >> solution
>>> >> would then need to be worked out and fixed. Please recall that this
>>> >> actually
>>> >> occurred on the first round (i.e., doing the examples led to
>>> >> discovering
>>> >> problems with the drafts), so it's not unreasonable at all to assume
>>> >> this
>>> >> would happen again.
>>> >>
>>> >> Look this just isn't a simple change your proposing. It involves a
>>> >> large
>>> >> upheaval, killing the pending RFC status on multiple documents that
>>> >> the
>>> >> industry is waiting on. Please see this.
>>> >>
>>> >> Thanks,
>>> >> Chris.
>>> >>
>>> >>
>>> >> Martin Bjorklund  writes:
>>> >>
>>> >>> Hi,
>>> >>>
>>> >>> Robert Wilton  wrote:
>>> >>>> Hi Lou,
>>> >>>>
>>> >>>> I think that this solution is inferior to the model presented in
>>> >>>> pre-09.
>>> >>>
>>> >>> I agree. Servers that are NMDA-compliant, or implements YANG Library
>>> >>> bis will have to present schemas in two different structures,
>>> >>> depending on where the schema is used, and clients will have to code
>>> >>> for both. With the solution in pre-09, there is just one structure.
>>> >>> A single structure also has other benefits (apart from being simpler),
>>> >>> e.g., if we augment it with the meta data that has been discussed
>>> >>> recently, we can augment a single structure.
>>> >>
>>> >>> /martin
>>> >>>
>>> >>>
>>> >>>
>>> >>>> I would prefer that we publish pre09 instead, potentially including
>>> >>>> the -08 model in the appendix if that helps progress the document in a
>>> >>>> more expedient fashion.
>>> >>>>
>>> >>>> Thanks,
>>> >>>> Rob
>>> >>>>
>>> >>>>
>>> >>>> On 22/02/2018 16:18, Lou Berger wrote:
>>> >>>> > Hi,
>>> >>>> >
>>> >>>> > (I have a bunch of different roles WRT this work. This mail is being
>>> >>>> > sent as an individual - as chair, I fully support the previous chair
>>> >>>> > statements on this draft.)
>>> >>>> >
>>> >>>> > Chris and I have come up with a proposal on how to provide full NMDA
>>> >>>> > as part the existing schema-mount module. Our motivation was to
>>> >>>> > enable full NMDA support with *minimal* change to the model and
>>> >>>> > disruption to the LC'ed work. The key NMDA limitation, with -08, that
>>> >>>> > we are aiming to address is the ability to support different mounted
>>> >>>> > schema in different datastores for non-inline mount points. (See more
>>> >>>> > detailed description below if interested full nuances of limitations
>>> >>>> > of -08)
>>> >>>> >
>>> >>>> > What we came up with was to simply add a (leaf)list to identify in
>>> >>>> > which datastores a
>>> >>>> > schema-mount schema is valid/present. This is somewhat similar to
>>> >>>> > YL-bis schema/module-set. Specifically we're proposing (see below for
>>> >>>> > full tree below):
>>> >>>> >
>>> >>>> > +--ro schema* [name]
>>> >>>> > +--ro name string
>>> >>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>> >>>> >
>>> >>>> > This approach has the advantages of supporting different mounted
>>> >>>> > schema in different DSes, working with both NMDA and non-NMDA
>>> >>>> > implementations, supporting all of the extensively discussed features
>>> >>>> > of schema mount (including recursive mounts), and having minor/scoped
>>> >>>> > impact on all dependent work. The main downside is that it isn't the
>>> >>>> > most optimal/compact solution possible if we were to base this work on
>>> >>>> > YL-bis/pre09 draft. Of course -08 isn't necessarily optimal from all
>>> >>>> > perspectives, but it is what was agreed to as sufficient by those who
>>> >>>> > contribute to the WG discussion.
>>> >>>> >
>>> >>>> > In short, we see this as a solution to addresses the raised last call
>>> >>>> > issue with the minimal impact on -08 and dependent work -- which is
>>> >>>> > what is appropriate given where we are in the process.
>>> >>>> >
>>> >>>> > So our/my question really is:
>>> >>>> >
>>> >>>> > Is this a solution that you/all can live with?
>>> >>>> >
>>> >>>> > Note: optimization, design preference and perfect alignment with use
>>> >>>> > or YL-bis are not part of our question as we both don't think that is
>>> >>>> > the right question given where we are in the WG process.
>>> >>>> >
>>> >>>> > Lou (with ideas developed with Chris, and chair hat off)
>>> >>>> >
>>> >>>> > ======
>>> >>>> > Details -- for those who want
>>> >>>> > ======
>>> >>>> > As background, my understanding/view is that the -08 version of the
>>> >>>> > both NMDA and non-NMDA supporting implementations, but there are
>>> >>>> > limitations in its NMDA applicability. Used with Yang Library,
>>> >>>> > [rfc7895], only non-NMDA implementations can be supported. When used
>>> >>>> > with the revised Yang Library defined in
>>> >>>> > [I.D.ietf-netconf-rfc7895bis-], NMDA implementations can be
>>> >>>> > supported with certain limitations. Specifically, this document
>>> >>>> > requires use of the now deprecated module-list grouping, and the same
>>> >>>> > schema represented in schema list of the Schema Mount module MUST be
>>> >>>> > used in all datastores. Inline type mount points, which don't use the
>>> >>>> > schema list, can support different schema in different data stores
>>> >>>> > not by instantiating the [I.D.ietf-netconf-rfc7895bis-] version of
>>> >>>> > YANG library under the inline mount point.
>>> >>>> >
>>> >>>> > module: ietf-yang-schema-mount
>>> >>>> > +--ro schema-mounts
>>> >>>> > +--ro namespace* [prefix]
>>> >>>> > | +--ro prefix yang:yang-identifier
>>> >>>> > | +--ro uri? inet:uri
>>> >>>> > +--ro mount-point* [module name]
>>> >>>> > | +--ro module yang:yang-identifier
>>> >>>> > | +--ro name yang:yang-identifier
>>> >>>> > | +--ro config? boolean
>>> >>>> > | +--ro (schema-ref)?
>>> >>>> > | +--:(inline)
>>> >>>> > | | +--ro inline? empty
>>> >>>> > | +--:(use-schema)
>>> >>>> > | +--ro use-schema* [name]
>>> >>>> > | +--ro name
>>> >>>> > | | -> /schema-mounts/schema/name
>>> >>>> > | +--ro parent-reference* yang:xpath1.0
>>> >>>> > +--ro schema* [name]
>>> >>>> > +--ro name string
>>> >>>> > ADD +--ro datastore* ds:datastore-ref {revised-datastores}
>>> >>>> > +--ro module* [name revision]
>>> >>>> > | +--ro name yang:yang-identifier
>>> >>>> > | +--ro revision union
>>> >>>> > | +--ro schema? inet:uri
>>> >>>> > | +--ro namespace inet:uri
>>> >>>> > | +--ro feature* yang:yang-identifier
>>> >>>> > | +--ro deviation* [name revision]
>>> >>>> > | | +--ro name yang:yang-identifier
>>> >>>> > | | +--ro revision union
>>> >>>> > | +--ro conformance-type enumeration
>>> >>>> > | +--ro submodule* [name revision]
>>> >>>> > | +--ro name yang:yang-identifier
>>> >>>> > | +--ro revision union
>>> >>>> > | +--ro schema? inet:uri
>>> >>>> > +--ro mount-point* [module name]
>>> >>>> > +--ro module yang:yang-identifier
>>> >>>> > +--ro name yang:yang-identifier
>>> >>>> > +--ro config? boolean
>>> >>>> > +--ro (schema-ref)?
>>> >>>> > +--:(inline)
>>> >>>> > | +--ro inline? empty
>>> >>>> > +--:(use-schema)
>>> >>>> > +--ro use-schema* [name]
>>> >>>> > +--ro name
>>> >>>> > | -> /schema-mounts/schema/name
>>> >>>> > +--ro parent-reference* yang:xpath1.0
>>> >>>> >
>>> >>>> > We would expect that the revised-datastores feature would be used
>>> >>>> > (perhaps required) for any implementation that supports
>>> >>>> > ietf-datastores
>>> >>>> > and yl-bis.
>>> >>>> >
>>> >>>> >
>>> >>>> >
>>> >>>> > _______________________________________________
>>> >>>> > netmod mailing list
>>> >>>> > netmod@ietf.org
>>> >>>> > https://www.ietf.org/mailman/listinfo/netmod
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> netmod mailing list
>>> >>>> netmod@ietf.org
>>> >>>> https://www.ietf.org/mailman/listinfo/netmod
>>> >>>
>>> >>> _______________________________________________
>>> >>> netmod mailing list
>>> >>> netmod@ietf.org
>>> >>> https://www.ietf.org/mailman/listinfo/netmod
>>> >>
>>> >> .
>>> >>
>>>
>
> _______________________________________________
> netmod mailing list
> netmod@ietf.org
> https://www.ietf.org/mailman/listinfo/netmod

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


From nobody Tue Feb 27 00:31:26 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B65A1201F2 for ; Tue, 27 Feb 2018 00:31:24 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.909
X-Spam-Level: 
X-Spam-Status: No, score=-1.909 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U3eSX8nzw8Ui for ; Tue, 27 Feb 2018 00:31:22 -0800 (PST)
Received: from atlas5.jacobs-university.de (atlas5.jacobs-university.de [212.201.44.20]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61D371200F1 for ; Tue, 27 Feb 2018 00:31:22 -0800 (PST)
Received: from localhost (demetrius5.irc-it.jacobs-university.de [10.70.0.222]) by atlas5.jacobs-university.de (Postfix) with ESMTP id AF145673; Tue, 27 Feb 2018 09:31:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from atlas5.jacobs-university.de ([10.70.0.217]) by localhost (demetrius5.jacobs-university.de [10.70.0.222]) (amavisd-new, port 10032) with ESMTP id UmFN2bP_wwwT; Tue, 27 Feb 2018 09:31:20 +0100 (CET)
Received: from hermes.jacobs-university.de (hermes.jacobs-university.de [212.201.44.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "hermes.jacobs-university.de", Issuer "Jacobs University CA - G01" (verified OK)) by atlas5.jacobs-university.de (Postfix) with ESMTPS; Tue, 27 Feb 2018 09:31:20 +0100 (CET)
Received: from localhost (demetrius1.jacobs-university.de [212.201.44.46]) by hermes.jacobs-university.de (Postfix) with ESMTP id 88FC720154; Tue, 27 Feb 2018 09:31:20 +0100 (CET)
X-Virus-Scanned: amavisd-new at jacobs-university.de
Received: from hermes.jacobs-university.de ([212.201.44.23]) by localhost (demetrius1.jacobs-university.de [212.201.44.32]) (amavisd-new, port 10024) with ESMTP id 6MhDT95SbDb4; Tue, 27 Feb 2018 09:31:20 +0100 (CET)
Received: from elstar.local (unknown [10.50.231.133]) by hermes.jacobs-university.de (Postfix) with ESMTP id 172AC20153; Tue, 27 Feb 2018 09:31:20 +0100 (CET)
Received: by elstar.local (Postfix, from userid 501) id 1503F4258C5A; Tue, 27 Feb 2018 09:31:17 +0100 (CET)
Date: Tue, 27 Feb 2018 09:31:16 +0100
From: Juergen Schoenwaelder 
To: Martin Bjorklund 
Cc: chopps@chopps.org, netmod@ietf.org
Message-ID: <20180227083116.xtlnju34s7ksjntc@elstar.local>
Reply-To: Juergen Schoenwaelder 
Mail-Followup-To: Martin Bjorklund , chopps@chopps.org, netmod@ietf.org
References: <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87lgfg9ded.fsf@chopps.org> <20180226.160921.622063322182936097.mbj@tail-f.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180226.160921.622063322182936097.mbj@tail-f.com>
User-Agent: NeoMutt/20171215
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 08:31:25 -0000

On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote:
> Hi,
> 
> Christian Hopps  wrote:
> > 
> > Hi Rob,
> > 
> > You do realize that no-one trying to actually deploy and run networks
> > cares about live-discovery of different schema per datastore for the
> > same mount point right? Like 99.999% of the clients know where things
> > are supposed to reside and expect them to be there.
> 
> But then why advertise anything at all?   We can do a *much* simpler
> solution by just having the mountpoint extension, and nothing else.
> Clients will know what to find anyway.
>

So it this a possible way out of the current situation? We publish a
trimmed down document that just defines the mount point extension and
we do an update of this document that adds all the details needed to
obtain the schema information?

/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 Feb 27 00:38:54 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E6BB612702E for ; Tue, 27 Feb 2018 00:38:51 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.009
X-Spam-Level: 
X-Spam-Status: No, score=-7.009 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nic.cz
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JFdHS7xSr3aN for ; Tue, 27 Feb 2018 00:38:50 -0800 (PST)
Received: from mail.nic.cz (mail.nic.cz [IPv6:2001:1488:800:400::400]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DDDCB1200B9 for ; Tue, 27 Feb 2018 00:38:49 -0800 (PST)
Received: from birdie (unknown [IPv6:2001:1488:fffe:6:1f99:257b:62cc:c0d5]) by mail.nic.cz (Postfix) with ESMTPSA id 4B6D262686 for ; Tue, 27 Feb 2018 09:38:48 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nic.cz; s=default; t=1519720728; bh=Stkw1aE6vmZtmPr8j7uvLOOow/8FcYTiDxUMPB3MYSA=; h=From:To:Date; b=fkhdvw2Ecr1ZR64MEHTSDxqrKMf5up+IllRtb4bUmUNblTKlqONsAydjASy0kx6Wi 4DVvlR+KQAmaFB/rNSRx+vCBqusVeYt08zob5JSmtaYSwbKPsIsAXJoe+p2qwvhN+/ nF+elplU0ASK5iex6vMGQUCi0UwrjZXckLrDIXiE=
Message-ID: <1519720727.10739.1.camel@nic.cz>
From: Ladislav Lhotka 
To: netmod@ietf.org
Date: Tue, 27 Feb 2018 09:38:47 +0100
In-Reply-To: <20180227083116.xtlnju34s7ksjntc@elstar.local>
References: <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87lgfg9ded.fsf@chopps.org> <20180226.160921.622063322182936097.mbj@tail-f.com> <20180227083116.xtlnju34s7ksjntc@elstar.local>
Organization: CZ.NIC
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.26.5 
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-Virus-Scanned: clamav-milter 0.99.2 at mail
X-Virus-Status: Clean
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 08:38:52 -0000

On Tue, 2018-02-27 at 09:31 +0100, Juergen Schoenwaelder wrote:
> On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Christian Hopps  wrote:
> > > 
> > > Hi Rob,
> > > 
> > > You do realize that no-one trying to actually deploy and run networks
> > > cares about live-discovery of different schema per datastore for the
> > > same mount point right? Like 99.999% of the clients know where things
> > > are supposed to reside and expect them to be there.
> > 
> > But then why advertise anything at all?   We can do a *much* simpler
> > solution by just having the mountpoint extension, and nothing else.
> > Clients will know what to find anyway.
> > 
> 
> So it this a possible way out of the current situation? We publish a
> trimmed down document that just defines the mount point extension and
> we do an update of this document that adds all the details needed to
> obtain the schema information?

I would say so. It would be immediately usable for the inline case.

Lada

> 
> /js
> 
-- 
Ladislav Lhotka
Head, CZ.NIC Labs
PGP Key ID: 0xB8F92B08A9F76C67


From nobody Tue Feb 27 01:15:43 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 265F4127333 for ; Tue, 27 Feb 2018 01:15:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6x2aeSJtXD7Z for ; Tue, 27 Feb 2018 01:15:41 -0800 (PST)
Received: from mail.tail-f.com (mail.tail-f.com [46.21.102.45]) by ietfa.amsl.com (Postfix) with ESMTP id EA2D412702E for ; Tue, 27 Feb 2018 01:15:40 -0800 (PST)
Received: from localhost (h-80-27.A165.priv.bahnhof.se [212.85.80.27]) by mail.tail-f.com (Postfix) with ESMTPSA id B50CA1AE02C9; Tue, 27 Feb 2018 10:15:38 +0100 (CET)
Date: Tue, 27 Feb 2018 10:15:38 +0100 (CET)
Message-Id: <20180227.101538.284842947165973615.mbj@tail-f.com>
To: j.schoenwaelder@jacobs-university.de
Cc: chopps@chopps.org, netmod@ietf.org
From: Martin Bjorklund 
In-Reply-To: <20180227083116.xtlnju34s7ksjntc@elstar.local>
References: <87lgfg9ded.fsf@chopps.org> <20180226.160921.622063322182936097.mbj@tail-f.com> <20180227083116.xtlnju34s7ksjntc@elstar.local>
X-Mailer: Mew version 6.7 on Emacs 24.5 / Mule 6.0 (HANACHIRUSATO)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 09:15:42 -0000

Juergen Schoenwaelder  wrote:
> On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote:
> > Hi,
> > 
> > Christian Hopps  wrote:
> > > 
> > > Hi Rob,
> > > 
> > > You do realize that no-one trying to actually deploy and run networks
> > > cares about live-discovery of different schema per datastore for the
> > > same mount point right? Like 99.999% of the clients know where things
> > > are supposed to reside and expect them to be there.
> > 
> > But then why advertise anything at all?   We can do a *much* simpler
> > solution by just having the mountpoint extension, and nothing else.
> > Clients will know what to find anyway.
> >
> 
> So it this a possible way out of the current situation? We publish a
> trimmed down document that just defines the mount point extension and
> we do an update of this document that adds all the details needed to
> obtain the schema information?

Not optimal, but I can accept this as a way to move forward.


/martin


From nobody Tue Feb 27 01:20:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 830FA1241FC; Tue, 27 Feb 2018 01:20:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.509
X-Spam-Level: 
X-Spam-Status: No, score=-14.509 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, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yKODVX1kEpY7; Tue, 27 Feb 2018 01:20:11 -0800 (PST)
Received: from aer-iport-3.cisco.com (aer-iport-3.cisco.com [173.38.203.53]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A83D61201F2; Tue, 27 Feb 2018 01:20:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=20310; q=dns/txt; s=iport; t=1519723211; x=1520932811; h=subject:to:cc:references:from:message-id:date: mime-version:in-reply-to; bh=sJPRN1MUF2BvnyCOFsD18MkAzasQfwmB3OuOJRGXrMg=; b=EY+qqXzfDAWlLiF+AqM3+euqrCBqSKhBWByLy/lZMNcjDRe/zWV8vPvo 7Mka7NVCVv6M+Blu7jw6857zLccCftbJwiBoMgaGc9SAcCn2O3lIeodcj u44kebE0th4GejYM9V/8xJ4Y+UzF0WDHhqWF2j7QDJP3y6G+wvIYlIqw0 s=;
X-Files: signature.asc : 488
X-IronPort-AV: E=Sophos;i="5.47,400,1515456000";  d="asc'?scan'208,217";a="2264912"
Received: from aer-iport-nat.cisco.com (HELO aer-core-2.cisco.com) ([173.38.203.22]) by aer-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2018 09:20:09 +0000
Received: from [10.61.241.233] ([10.61.241.233]) by aer-core-2.cisco.com (8.14.5/8.14.5) with ESMTP id w1R9K8NR025594; Tue, 27 Feb 2018 09:20:08 GMT
To: Mahesh Jethanandani 
Cc: Kent Watsen , "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" , Warren Kumari , "Joe Clarke (jclarke)" 
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net> <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com> <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net> <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com> <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com> 
From: Eliot Lear 
Message-ID: 
Date: Tue, 27 Feb 2018 10:20:07 +0100
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: 
Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="6A3nMBxns1nFmaUWbieSjjjVtGmb07v0d"
Archived-At: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 09:20:13 -0000

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--6A3nMBxns1nFmaUWbieSjjjVtGmb07v0d
Content-Type: multipart/mixed; boundary="WkBI714FGqxOwKXKn4FEfscKopV2AkNu5";
 protected-headers="v1"
From: Eliot Lear 
To: Mahesh Jethanandani 
Cc: Kent Watsen ,
 "draft-ietf-netmod-acl-model@ietf.org"
 , "netmod@ietf.org" ,
 Warren Kumari , "Joe Clarke (jclarke)" 
Message-ID: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net>
 <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com>
 <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net>
 <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com>
 <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com>
 
In-Reply-To: 

--WkBI714FGqxOwKXKn4FEfscKopV2AkNu5
Content-Type: multipart/alternative;
 boundary="------------31311C1484150E5575E10216"
Content-Language: en-US

This is a multi-part message in MIME format.
--------------31311C1484150E5575E10216
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: base64

VGhpcyBlZGl0IGRvZXNuJ3Qgc2VlbSBjb3JyZWN0IHRvIG1lIGJlY2F1c2Ugbm93IHdlIGhh
dmUgYSBjaG9pY2Ugd2l0aCBhCnNpbmdsZSBjYXNlLCB3aXRoIHJhbmdlIGhhdmluZyBiZWVu
IHJlbW92ZWQuwqAgQ2FuIHdlIHBsZWFzZSByZXZlcnQgYW5kCnByb2NlZWQ/CgoKT24gMjYu
MDIuMTggMjA6MjQsIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6Cj4gQSBwdWxsIHJlcXVl
c3QgdG8gYWRkcmVzcyBMQywgc2hlcGhlcmQsIHRoaXMgYW5kIHRoZSBvdGhlciBjb21tZW50
cywKPiBpbmNsdWRpbmcgZGVyaXZlZC1mcm9tKCksIGNhbiBiZSByZXZpZXdlZCBoZXJlOgo+
Cj4gaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yNAo+Cj4g
VGhhbmtzLgo+Cj4+IE9uIEZlYiAyNiwgMjAxOCwgYXQgMTI6MTUgQU0sIEVsaW90IExlYXIg
PGxlYXJAY2lzY28uY29tCj4+IDxtYWlsdG86bGVhckBjaXNjby5jb20+PiB3cm90ZToKPj4K
Pj4KPj4KPj4gT24gMjYuMDIuMTggMDY6NTUsIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6
Cj4+Pj4KPj4+Pj4KPj4+Pj4KPj4+Pj4gwqBQUzogQW5kIHRoaXMgaXMgbm90IGEgc2hlcGhl
cmQgZGlyZWN0aXZlLCBidXQgSSBmb3VuZCB0aGUgd2hvbGXCoAo+Pj4+PiDCoMKgwqDCoMKg
InNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yIiBzeW50YXggY2x1bXN5LiDCoEknbSBz
dXJwcmlzZWQKPj4+Pj4gwqDCoMKgwqDCoGl0IGRpZG4ndCBsb29rIHNvbWV0aGluZyBsaWtl
Ogo+Pj4+Pgo+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqBPTEQKPj4+Pj4gwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgPHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yPgo+Pj4+
PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8cG9ydC1yYW5nZS1vci1v
cGVyYXRvcj4KPj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oDxyYW5nZT4KPj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqA8bG93ZXItcG9ydD4xNjM4NDwvbG93ZXItcG9ydD4KPj4+Pj4gwqDCoMKgwqDCoMKg
wqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8dXBwZXItcG9ydD42NTUzNTwvdXBw
ZXItcG9ydD4KPj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oDwvcmFuZ2U+Cj4+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwv
cG9ydC1yYW5nZS1vci1vcGVyYXRvcj4KPj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgPC9zb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvcj4KPj4+Pj4KPj4+Pj4gwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJh
dG9yPgo+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHBvcnQtcmFu
Z2Utb3Itb3BlcmF0b3I+Cj4+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoMKgPG9wZXJhdG9yPgo+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqA8b3BlcmF0b3I+ZXE8L29wZXJhdG9yPgo+Pj4+PiDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8cG9ydD4yMTwvcG9ydD4KPj4+Pj4gwqDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L29wZXJhdG9yPgo+Pj4+PiDC
oMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPC9wb3J0LXJhbmdlLW9yLW9wZXJh
dG9yPgo+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8L3NvdXJjZS1wb3J0
LXJhbmdlLW9yLW9wZXJhdG9yPgo+Pj4+Pgo+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqBORVcK
Pj4+Pj4KPj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHNvdXJjZS1wb3J0
Pgo+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHJhbmdlPgo+Pj4+
PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxsb3dlcj4xNjM4NDwv
bG93ZXI+Cj4+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgPHVw
cGVyPjY1NTM1PC91cHBlcj4KPj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKg
wqDCoDwvcmFuZ2U+Cj4+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDwvc291
cmNlLXBvcnQ+Cj4+Pj4+Cj4+Pj4+IMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxz
b3VyY2UtcG9ydD4KPj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoDxv
cGVyYXRvcj4KPj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqA8
b3BlcmF0b3I+ZXE8L29wZXJhdG9yPgo+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoDxwb3J0PjIxPC9wb3J0Pgo+Pj4+PiDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgwqDCoMKgPC9vcGVyYXRvcj4KPj4+Pj4gwqDCoMKgwqDCoMKgwqDCoMKgwqDC
oMKgwqDCoMKgPC9zb3VyY2UtcG9ydD4KPj4+Pj4KPj4+PiDCoAo+Pj4+IERpZCB5b3UgdHJ5
IG1ha2luZyB0aGUgY2hhbmdlIGluIHRoZSBtb2RlbCB0byBzZWUgaWYgaXQgd29yaz8gSXQK
Pj4+PiB3aWxsIGNvbXBsYWluIHRoYXQgPHJhbmdlPiBpcyBhbHJlYWR5IHVzZWQgd2l0aGlu
IHRoZSBjb250YWluZXIgYW5kCj4+Pj4gdGhhdCBpdCBjYW5ub3QgYmUgcmVwZWF0ZWQgKGZv
ciBkZXN0aW5hdGlvbi1wb3J0KS4KPj4+Pgo+Pj4+IDxLRU5UPiBObywgSSBkaWQgbm90LCBu
b3IgZG8gSSBpbnRlbmQgdG8gZ2V0IHRoYXQgZGVlcCBpbnRvIGl0LsKgCj4+Pj4gQnV0IEkg
cmVjYWxsIHRoYXQgS3Jpc3RpYW4gbWFkZSB0aGUgc2FtZSBjb21tZW50IGJlZm9yZSwgYW5k
IHdhcwo+Pj4+IG1ha2luZyBwdWxsIHJlcXVlc3RzIGJlZm9yZSwgc28gbWF5YmUgaGUgY2Fu
IHN1Z2dlc3Qgc29tZXRoaW5nPwo+Pj4KPj4+IEtyaXN0aWFu4oCZcyBzdWdnZXN0aW9uIHJl
cXVpcmVzIGNoYW5naW5nIHRoZSBtb2R1bGUuIEl0IGlzIG5vdCBhbgo+Pj4gZWRpdG9yaWFs
IGNoYW5nZS4gQW5kIHRoYXQgY2hhbmdlIHdpbGwgaGF2ZSBhbiBpbXBhY3Qgb24gdGhlIE1V
RAo+Pj4gZHJhZnQsIHdoaWNoIGhhcyBiZWVuIHNlbnQgZm9yIHB1YmxpY2F0aW9uLsKgCj4+
Pgo+Pgo+PiBBcyBpdCBoYXBwZW5zLCB3ZSBmb3VuZCBhIGJ1ZyBpbiBvdXIgYXVnbWVudCBz
dGF0ZW1lbnRzLCBhbmQgc28gd2UKPj4gd2lsbCBuZWVkIHRvIHJldiBvbmUgbW9yZSB0aW1l
LsKgIElmIHRoZSBjaGFuZ2UgY2FuIGJlIG1hZGUgcXVpY2tseSwgSQo+PiBjYW4gbGl2ZSB3
aXRoIGl0Lgo+Pgo+PiBFbGlvdAo+Cj4gTWFoZXNoIEpldGhhbmFuZGFuaQo+IG1qZXRoYW5h
bmRhbmlAZ21haWwuY29tIDxtYWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+Cj4KCg==
--------------31311C1484150E5575E10216
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable


  
    
  
  
    
This edit doesn't seem correct to me because now we have a choice
      with a single case, with range having been removed.=C2=A0 Can we pl=
ease
      revert and proceed?

    

    

    
On 26.02.18 20:24, Mahesh Jethanandani=

      wrote:

    

    

      
      A pull request to address LC, shepherd, this and the other
      comments, including derived-from(), can be reviewed here:
      


      

      
https://github.com/netmod-wg/acl-model=
/pull/24

      


      

      
Thanks.

        


          

            
On Feb 26, 2018, at 12:15 AM, Eliot Lear <=
lear@cisco.com> wrote:
            

            

              

                


                

                

                
On 26.02.18 06:55, Mahesh
                  Jethanandani wrote:

                

                

                  

                    

                      

                        

                          

                            

                              
=


                                

                              

                                

                                  

                                    


                                      

                                      =C2=A0PS: And this is not a shepher=
d
                                      directive, but I found the whole=C2=
=A0

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0"source-port-range-or-operator" syntax clum=
sy. =C2=A0I'm surprised

                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0it di=
dn't look something
                                      like:

                                      

                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0OLD

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0<source-port-range-or-operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<port-range-or-operator>

                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0<range>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<lower-port&g=
t;16384</lower-port>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<upper-port&g=
t;65535</upper-port>

                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0</range>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</port-range-or-operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0</source-port-range-or-operator>

                                      

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0<source-port-range-or-operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0<port-range-or-operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<operator>eq<=
/operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<port>21</por=
t>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</operator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0</port-range-or-operator>
=

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0</source-port-range-or-operator>

                                      

                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0NEW

                                      

                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<source-port>=


                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<ran=
ge>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<lower>16384</lower>
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<upper>65535</upper>
                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</ra=
nge>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0</source-port>

                                      

                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<source-port>=


                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<ope=
rator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<operator>eq</operator>=
;

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0<port>21</port>

                                      =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0</op=
erator>

=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=
=A0=C2=A0=C2=A0</source-port>

                                  

                                

                              

                              

                                
=C2=A0

                              

                              
=
Did
                                you try making the change in the model
                                to see if it work? It will complain that
                                <range> is already used within the
                                container and that it cannot be repeated
                                (for destination-port).

                            

                            

                              
=


                                <KENT> No, I did not, nor do I
                                intend to get that deep into it.=C2=A0 Bu=
t I
                                recall that Kristian made the same
                                comment before, and was making pull
                                requests before, so maybe he can suggest
                                something?

                            

                          

                        

                      

                    

                    


                    

                    Kristian=E2=80=99s suggestion requires changing the m=
odule.
                    It is not an editorial change. And that change will
                    have an impact on the MUD draft, which has been sent
                    for publication.=C2=A0

                  


                  

                

                

                As it happens, we found a bug in our augment statements,
                and so we will need to rev one more time.=C2=A0 If the ch=
ange
                can be made quickly, I can live with it.

                

                Eliot

              

            

          

        

        

        

          
Mahesh Jethanandani

          
mjethanandani@gmail.com=


        

        

      

    

    

  


--------------31311C1484150E5575E10216--

--WkBI714FGqxOwKXKn4FEfscKopV2AkNu5--

--6A3nMBxns1nFmaUWbieSjjjVtGmb07v0d
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmNC9kEYdsJKnsmEdh7ZrRtnSejMFAlqVIscACgkQh7ZrRtnS
ejOnKQgAsa8kjUlv08JHFjVzUflzjG4f4eqqLRU8Mfw8Qu3b0HhNKKSEBM/Ww34Z
kt715THPv/ArPvtJ+kMpdTNEOw/sNa3Tp/01C6riQiVqjuulo8uaDL3Ph5wzjcKa
EN6JfsVERXlDf6NH5PAO6Km9oZS8ZmNulMWzlH0xgc2ReLKH9y8CU55mfV5phmFn
cA5sQvvBc+5Ke9G7LRqTMHogYquI+EDtxCX0iwoljUH8BYVCCpl0ztB+TrFXCZ4s
35IQgb0I40L9X2x7EiBpUldqnjwaove43QXKTfFGf3ngzGatJp24yzkPTdhZz8lZ
nB4YDLxPV7ZZcK0fiScbibR/0KdRtg==
=0nVV
-----END PGP SIGNATURE-----

--6A3nMBxns1nFmaUWbieSjjjVtGmb07v0d--


From nobody Tue Feb 27 03:01:22 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 54E211273B1; Tue, 27 Feb 2018 03:01:21 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.529
X-Spam-Level: 
X-Spam-Status: No, score=-14.529 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7XEVDeKv5hBq; Tue, 27 Feb 2018 03:01:19 -0800 (PST)
Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 73D341200F1; Tue, 27 Feb 2018 03:01:19 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=25780; q=dns/txt; s=iport; t=1519729279; x=1520938879; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=SekqmMopKzwMyvoomiftblzohvLqDGxy0mMTvH10fnM=; b=dr/8vFmPhbHmLmDjg5aXHbc4Bobx4HjtyKOIEoU5MnZoYZuPt5ebaWgU bf2AnSrso6CTnv62g/NS/ols0Ii/YKbUytmPRoidChz87aNpcZgvyU//F fGuhUa3TMK87v2mwtL7+tSlZPpSPZWX5SniGbqTq2mZ/jEyFi1YyDJBRK 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0DOAAA/OZVa/5RdJa1dGQEBAQEBAQEBA?= =?us-ascii?q?QEBAQcBAQEBAYJaSS1mcBUTCoNKiiKNf4ICgRaHIY0JFIIBChgBCoRATwIagjB?= =?us-ascii?q?UGAECAQEBAQEBAmsohSQCBAEBIUsLEAIBCD8DAgICHwYLFBECBA4FhDFMAxUQq?= =?us-ascii?q?weCJyaHDQ2BMIIUAQEBAQEBAQEBAQEBAQEBAQEBAQEBGAWFIYIng2aDBIJqRAE?= =?us-ascii?q?BgVkXCBCCdjCCMgWTOYZlMAkChk6GaIM5gWaENIhaiXo5hCuCRQIRGQGBLQEeO?= =?us-ascii?q?IFRcBU6KgGCGD6CBRyBBAEJbXeMJ4EXAQEB?=
X-IronPort-AV: E=Sophos;i="5.47,400,1515456000";  d="scan'208,217";a="359446755"
Received: from rcdn-core-12.cisco.com ([173.37.93.148]) by rcdn-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 27 Feb 2018 11:01:18 +0000
Received: from XCH-RTP-009.cisco.com (xch-rtp-009.cisco.com [64.101.220.149]) by rcdn-core-12.cisco.com (8.14.5/8.14.5) with ESMTP id w1RB1HB4029158 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 27 Feb 2018 11:01:18 GMT
Received: from xch-rtp-009.cisco.com (64.101.220.149) by XCH-RTP-009.cisco.com (64.101.220.149) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Tue, 27 Feb 2018 06:01:17 -0500
Received: from xch-rtp-009.cisco.com ([64.101.220.149]) by XCH-RTP-009.cisco.com ([64.101.220.149]) with mapi id 15.00.1320.000; Tue, 27 Feb 2018 06:01:17 -0500
From: "Einar Nilsen-Nygaard (einarnn)" 
To: Eliot Lear 
CC: Mahesh Jethanandani , Warren Kumari , "draft-ietf-netmod-acl-model@ietf.org" , "netmod@ietf.org" 
Thread-Topic: [netmod] ACL draft issues found during shepherd writeup
Thread-Index: AQHTpRpSR0BIQpp1FUa5qmqsmhR9+aOpuIqAgAkWYYCAA8edgIAAJvaAgAC67gCAAOmBgIAAHEMA
Date: Tue, 27 Feb 2018 11:01:17 +0000
Message-ID: 
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net> <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com> <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net> <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com> <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com>  
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-mailer: Apple Mail (2.3445.5.20)
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.61.197.101]
Content-Type: multipart/alternative; boundary="_000_DC341012FDF845D3BCA5F4B7E1BCC2EEciscocom_"
MIME-Version: 1.0
Archived-At: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 11:01:21 -0000

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

V2hhdCBLcmlzdGlhbiBhbmQgSSBkaXNjdXNzZWQsIHdoYXQgU29uYWwgYW5kIEkgaGFkIGRpc2N1
c3NlZCwgYW5kIHdoYXQgSSB0aG91Z2h0IHdlIGhhZCBhY2NlcHRlZCBhcyBhIHByb3Bvc2VkIGNo
YW5nZSB3YXMgc29tZXRoaW5nIGxpa2U6DQoNCiAgICBjaG9pY2Ugc291cmNlLXBvcnQtcmFuZ2Ut
b3Itb3BlcmF0b3Igew0KICAgICAgY2FzZSByYW5nZSB7DQogICAgICAgIGxlYWYgc291cmNlLXBv
cnQtbG93ZXIgew0KICAgICAgICAgIHR5cGUgaW5ldDpwb3J0LW51bWJlcjsNCiAgICAgICAgICBt
dXN0ICIuIDw9IC4uL3NvdXJjZS1wb3J0LXVwcGVyIiB7DQogICAgICAgICAgICBlcnJvci1tZXNz
YWdlDQogICAgICAgICAgICAgICJUaGUgc291cmNlLXBvcnQtbG93ZXIgbXVzdCBiZSBsZXNzIHRo
YW4gb3IgZXF1YWwgdG8NCiAgICAgICAgICAgICAgIHNvdXJjZS1wb3J0LXVwcGVyIjsNCiAgICAg
ICAgICB9DQogICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICAgICAgZGVzY3JpcHRpb24N
CiAgICAgICAgICAgICJMb3dlciBib3VuZGFyeSBmb3IgcG9ydC4iOw0KICAgICAgICB9DQogICAg
ICAgIGxlYWYgc291cmNlLXBvcnQtdXBwZXIgew0KICAgICAgICAgIHR5cGUgaW5ldDpwb3J0LW51
bWJlcjsNCiAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsNCiAgICAgICAgICBkZXNjcmlwdGlvbg0K
ICAgICAgICAgICAgIkxvd2VyIGJvdW5kYXJ5IGZvciBwb3J0LiI7DQogICAgICAgIH0NCiAgICAg
IH0NCiAgICAgIGNhc2Ugb3BlcmF0b3Igew0KICAgICAgICBsZWFmIHNvdXJjZS1vcGVyYXRvciB7
DQogICAgICAgICAgdHlwZSBvcGVyYXRvcjsNCiAgICAgICAgICBtYW5kYXRvcnkgdHJ1ZTsNCiAg
ICAgICAgfQ0KICAgICAgICBsZWFmIHNvdXJjZS1wb3J0IHsNCiAgICAgICAgICB0eXBlIGluZXQ6
cG9ydC1udW1iZXI7DQogICAgICAgICAgbWFuZGF0b3J5IHRydWU7DQogICAgICAgICAgZGVzY3Jp
cHRpb24NCiAgICAgICAgICAgICJQb3J0IHZhbHVlIHRvIG1hdGNoLiI7DQogICAgICAgIH0NCiAg
ICAgIH0NCiAgICB9DQoNCuKApmFuZCB3aXRoIHRoZSBzYW1lIHBhdHRlcm4gZm9yIHRoZSBkZXN0
aW5hdGlvbi4gVGhlIHR5cGUg4oCcb3BlcmF0b3LigJ0gd2FzIGRlZmluZWQgYXM6DQoNCiAgdHlw
ZWRlZiBvcGVyYXRvciB7DQogICAgdHlwZSBlbnVtZXJhdGlvbiB7DQogICAgICBlbnVtIGx0ZSB7
DQogICAgICAgIGRlc2NyaXB0aW9uDQogICAgICAgICAgIkxlc3MgdGhhbiBvciBlcXVhbCB0by4i
Ow0KICAgICAgfQ0KICAgICAgZW51bSBndGUgew0KICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAg
ICAgICJHcmVhdGVyIHRoYW4gb3IgZXF1YWwgdG8uIjsNCiAgICAgIH0NCiAgICAgIGVudW0gZXEg
ew0KICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICJFcXVhbCB0by4iOw0KICAgICAgfQ0K
ICAgICAgZW51bSBuZXEgew0KICAgICAgICBkZXNjcmlwdGlvbg0KICAgICAgICAgICJOb3QgZXF1
YWwgdG8uIjsNCiAgICAgIH0NCiAgICB9DQoNCkNoZWVycywNCg0KRWluYXINCg0KDQpPbiAyNyBG
ZWIgMjAxOCwgYXQgMDk6MjAsIEVsaW90IExlYXIgPGxlYXJAY2lzY28uY29tPG1haWx0bzpsZWFy
QGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNClRoaXMgZWRpdCBkb2Vzbid0IHNlZW0gY29ycmVjdCB0
byBtZSBiZWNhdXNlIG5vdyB3ZSBoYXZlIGEgY2hvaWNlIHdpdGggYSBzaW5nbGUgY2FzZSwgd2l0
aCByYW5nZSBoYXZpbmcgYmVlbiByZW1vdmVkLiAgQ2FuIHdlIHBsZWFzZSByZXZlcnQgYW5kIHBy
b2NlZWQ/DQoNCk9uIDI2LjAyLjE4IDIwOjI0LCBNYWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOg0K
QSBwdWxsIHJlcXVlc3QgdG8gYWRkcmVzcyBMQywgc2hlcGhlcmQsIHRoaXMgYW5kIHRoZSBvdGhl
ciBjb21tZW50cywgaW5jbHVkaW5nIGRlcml2ZWQtZnJvbSgpLCBjYW4gYmUgcmV2aWV3ZWQgaGVy
ZToNCg0KaHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yNA0KDQpU
aGFua3MuDQoNCk9uIEZlYiAyNiwgMjAxOCwgYXQgMTI6MTUgQU0sIEVsaW90IExlYXIgPGxlYXJA
Y2lzY28uY29tPG1haWx0bzpsZWFyQGNpc2NvLmNvbT4+IHdyb3RlOg0KDQoNCg0KT24gMjYuMDIu
MTggMDY6NTUsIE1haGVzaCBKZXRoYW5hbmRhbmkgd3JvdGU6DQoNCg0KDQogUFM6IEFuZCB0aGlz
IGlzIG5vdCBhIHNoZXBoZXJkIGRpcmVjdGl2ZSwgYnV0IEkgZm91bmQgdGhlIHdob2xlDQogICAg
ICJzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvciIgc3ludGF4IGNsdW1zeS4gIEknbSBzdXJw
cmlzZWQNCiAgICAgaXQgZGlkbid0IGxvb2sgc29tZXRoaW5nIGxpa2U6DQoNCiAgICAgICAgIE9M
RA0KICAgICAgICAgICAgICAgPHNvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yPg0KICAgICAg
ICAgICAgICAgICAgPHBvcnQtcmFuZ2Utb3Itb3BlcmF0b3I+DQogICAgICAgICAgICAgICAgICAg
IDxyYW5nZT4NCiAgICAgICAgICAgICAgICAgICAgICA8bG93ZXItcG9ydD4xNjM4NDwvbG93ZXIt
cG9ydD4NCiAgICAgICAgICAgICAgICAgICAgICA8dXBwZXItcG9ydD42NTUzNTwvdXBwZXItcG9y
dD4NCiAgICAgICAgICAgICAgICAgICAgPC9yYW5nZT4NCiAgICAgICAgICAgICAgICAgIDwvcG9y
dC1yYW5nZS1vci1vcGVyYXRvcj4NCiAgICAgICAgICAgICAgIDwvc291cmNlLXBvcnQtcmFuZ2Ut
b3Itb3BlcmF0b3I+DQoNCiAgICAgICAgICAgICAgIDxzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVy
YXRvcj4NCiAgICAgICAgICAgICAgICAgPHBvcnQtcmFuZ2Utb3Itb3BlcmF0b3I+DQogICAgICAg
ICAgICAgICAgICAgPG9wZXJhdG9yPg0KICAgICAgICAgICAgICAgICAgICAgPG9wZXJhdG9yPmVx
PC9vcGVyYXRvcj4NCiAgICAgICAgICAgICAgICAgICAgIDxwb3J0PjIxPC9wb3J0Pg0KICAgICAg
ICAgICAgICAgICAgIDwvb3BlcmF0b3I+DQogICAgICAgICAgICAgICAgIDwvcG9ydC1yYW5nZS1v
ci1vcGVyYXRvcj4NCiAgICAgICAgICAgICAgIDwvc291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0
b3I+DQoNCiAgICAgICAgIE5FVw0KDQogICAgICAgICAgICAgICA8c291cmNlLXBvcnQ+DQogICAg
ICAgICAgICAgICAgIDxyYW5nZT4NCiAgICAgICAgICAgICAgICAgICA8bG93ZXI+MTYzODQ8L2xv
d2VyPg0KICAgICAgICAgICAgICAgICAgIDx1cHBlcj42NTUzNTwvdXBwZXI+DQogICAgICAgICAg
ICAgICAgIDwvcmFuZ2U+DQogICAgICAgICAgICAgICA8L3NvdXJjZS1wb3J0Pg0KDQogICAgICAg
ICAgICAgICA8c291cmNlLXBvcnQ+DQogICAgICAgICAgICAgICAgIDxvcGVyYXRvcj4NCiAgICAg
ICAgICAgICAgICAgICA8b3BlcmF0b3I+ZXE8L29wZXJhdG9yPg0KICAgICAgICAgICAgICAgICAg
IDxwb3J0PjIxPC9wb3J0Pg0KICAgICAgICAgICAgICAgICA8L29wZXJhdG9yPg0KICAgICAgICAg
ICAgICAgPC9zb3VyY2UtcG9ydD4NCg0KRGlkIHlvdSB0cnkgbWFraW5nIHRoZSBjaGFuZ2UgaW4g
dGhlIG1vZGVsIHRvIHNlZSBpZiBpdCB3b3JrPyBJdCB3aWxsIGNvbXBsYWluIHRoYXQgPHJhbmdl
PiBpcyBhbHJlYWR5IHVzZWQgd2l0aGluIHRoZSBjb250YWluZXIgYW5kIHRoYXQgaXQgY2Fubm90
IGJlIHJlcGVhdGVkIChmb3IgZGVzdGluYXRpb24tcG9ydCkuDQoNCjxLRU5UPiBObywgSSBkaWQg
bm90LCBub3IgZG8gSSBpbnRlbmQgdG8gZ2V0IHRoYXQgZGVlcCBpbnRvIGl0LiAgQnV0IEkgcmVj
YWxsIHRoYXQgS3Jpc3RpYW4gbWFkZSB0aGUgc2FtZSBjb21tZW50IGJlZm9yZSwgYW5kIHdhcyBt
YWtpbmcgcHVsbCByZXF1ZXN0cyBiZWZvcmUsIHNvIG1heWJlIGhlIGNhbiBzdWdnZXN0IHNvbWV0
aGluZz8NCg0KS3Jpc3RpYW7igJlzIHN1Z2dlc3Rpb24gcmVxdWlyZXMgY2hhbmdpbmcgdGhlIG1v
ZHVsZS4gSXQgaXMgbm90IGFuIGVkaXRvcmlhbCBjaGFuZ2UuIEFuZCB0aGF0IGNoYW5nZSB3aWxs
IGhhdmUgYW4gaW1wYWN0IG9uIHRoZSBNVUQgZHJhZnQsIHdoaWNoIGhhcyBiZWVuIHNlbnQgZm9y
IHB1YmxpY2F0aW9uLg0KDQoNCkFzIGl0IGhhcHBlbnMsIHdlIGZvdW5kIGEgYnVnIGluIG91ciBh
dWdtZW50IHN0YXRlbWVudHMsIGFuZCBzbyB3ZSB3aWxsIG5lZWQgdG8gcmV2IG9uZSBtb3JlIHRp
bWUuICBJZiB0aGUgY2hhbmdlIGNhbiBiZSBtYWRlIHF1aWNrbHksIEkgY2FuIGxpdmUgd2l0aCBp
dC4NCg0KRWxpb3QNCg0KTWFoZXNoIEpldGhhbmFuZGFuaQ0KbWpldGhhbmFuZGFuaUBnbWFpbC5j
b208bWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tPg0KDQoNCl9fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpuZXRtb2QgbWFpbGluZyBsaXN0DQpuZXRt
b2RAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZEBpZXRmLm9yZz4NCmh0dHBzOi8vd3d3LmlldGYub3Jn
L21haWxtYW4vbGlzdGluZm8vbmV0bW9kDQoNCg==

--_000_DC341012FDF845D3BCA5F4B7E1BCC2EEciscocom_
Content-Type: text/html; charset="utf-8"
Content-ID: <5405F76DD87996419F9AFE539F78ED7E@emea.cisco.com>
Content-Transfer-Encoding: base64

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy
YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgbGluZS1icmVhazogYWZ0
ZXItd2hpdGUtc3BhY2U7IiBjbGFzcz0iIj4NCldoYXQgS3Jpc3RpYW4gYW5kIEkgZGlzY3Vzc2Vk
LCB3aGF0IFNvbmFsIGFuZCBJIGhhZCBkaXNjdXNzZWQsIGFuZCB3aGF0IEkgdGhvdWdodCB3ZSBo
YWQgYWNjZXB0ZWQgYXMgYSBwcm9wb3NlZCBjaGFuZ2Ugd2FzIHNvbWV0aGluZyBsaWtlOg0KPGRp
diBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4m
bmJzcDsgJm5ic3A7Jm5ic3A7Y2hvaWNlJm5ic3A7c291cmNlLXBvcnQtcmFuZ2Utb3Itb3BlcmF0
b3IgezxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7Y2FzZSZuYnNwO3Jh
bmdlJm5ic3A7ezxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNw
O2xlYWYmbmJzcDtzb3VyY2UtcG9ydC1sb3dlciB7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO3R5cGUmbmJzcDtpbmV0OnBvcnQtbnVtYmVyOzxi
ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDttdXN0
Jm5ic3A7JnF1b3Q7LiAmbHQ7PSAuLi9zb3VyY2UtcG9ydC11cHBlciZxdW90OyZuYnNwO3s8YnIg
Y2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNw
O2Vycm9yLW1lc3NhZ2U8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmcXVvdDtUaGUgc291cmNlLXBvcnQtbG93ZXIgbXVz
dCBiZSBsZXNzIHRoYW4gb3IgZXF1YWwgdG88YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7c291cmNlLXBvcnQtdXBwZXIm
cXVvdDs7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyB9
PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO21h
bmRhdG9yeSZuYnNwO3RydWU7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9uPGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmcXVvdDtMb3dlciBib3VuZGFyeSBmb3Ig
cG9ydC4mcXVvdDs7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH08
YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtsZWFmJm5ic3A7
c291cmNlLXBvcnQtdXBwZXIgezxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsmbmJzcDt0eXBlJm5ic3A7aW5ldDpwb3J0LW51bWJlcjs8YnIgY2xhc3M9IiI+
DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7bWFuZGF0b3J5Jm5ic3A7
dHJ1ZTs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5i
c3A7ZGVzY3JpcHRpb248YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsg
Jm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90O0xvd2VyIGJvdW5kYXJ5IGZvciBwb3J0LiZxdW90Ozs8
YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxiciBjbGFzcz0iIj4N
CiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNw
OyZuYnNwO2Nhc2UmbmJzcDtvcGVyYXRvciB7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAm
bmJzcDsgJm5ic3A7Jm5ic3A7bGVhZiZuYnNwO3NvdXJjZS1vcGVyYXRvciB7PGJyIGNsYXNzPSIi
Pg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO3R5cGUmbmJzcDtvcGVy
YXRvcjs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5i
c3A7bWFuZGF0b3J5Jm5ic3A7dHJ1ZTs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsgfTxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNw
O2xlYWYmbmJzcDtzb3VyY2UtcG9ydCB7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJz
cDsgJm5ic3A7ICZuYnNwOyZuYnNwO3R5cGUmbmJzcDtpbmV0OnBvcnQtbnVtYmVyOzxiciBjbGFz
cz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDttYW5kYXRvcnkm
bmJzcDt0cnVlOzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJz
cDsmbmJzcDtkZXNjcmlwdGlvbjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZu
YnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7JnF1b3Q7UG9ydCB2YWx1ZSB0byBtYXRjaC4mcXVvdDs7
PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7IH08YnIgY2xhc3M9IiI+
DQombmJzcDsgJm5ic3A7ICZuYnNwOyB9PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyB9PC9m
b250PjxiciBjbGFzcz0iIj4NCjxkaXY+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2PuKApmFu
ZCB3aXRoIHRoZSBzYW1lIHBhdHRlcm4gZm9yIHRoZSBkZXN0aW5hdGlvbi4gVGhlIHR5cGUg4oCc
b3BlcmF0b3LigJ0gd2FzIGRlZmluZWQgYXM6PC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjwv
ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDb3VyaWVyIiBjbGFzcz0iIj4mbmJzcDsmbmJzcDt0eXBl
ZGVmJm5ic3A7b3BlcmF0b3IgezxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsmbmJzcDt0eXBl
Jm5ic3A7ZW51bWVyYXRpb24mbmJzcDt7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJz
cDsmbmJzcDtlbnVtJm5ic3A7bHRlIHs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNw
OyAmbmJzcDsmbmJzcDtkZXNjcmlwdGlvbjxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5i
c3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmcXVvdDtMZXNzIHRoYW4gb3IgZXF1YWwgdG8uJnF1b3Q7
OzxiciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7IH08YnIgY2xhc3M9IiI+DQombmJz
cDsgJm5ic3A7ICZuYnNwOyZuYnNwO2VudW0mbmJzcDtndGUgezxiciBjbGFzcz0iIj4NCiZuYnNw
OyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwO2Rlc2NyaXB0aW9uPGJyIGNsYXNzPSIiPg0KJm5i
c3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyZuYnNwOyZxdW90O0dyZWF0ZXIgdGhhbiBv
ciBlcXVhbCB0by4mcXVvdDs7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxi
ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ZW51bSZuYnNwO2VxIHs8YnIg
Y2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDtkZXNjcmlwdGlvbjxi
ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsmbmJzcDsmcXVv
dDtFcXVhbCB0by4mcXVvdDs7PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgfTxi
ciBjbGFzcz0iIj4NCiZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ZW51bSZuYnNwO25lcSB7PGJy
IGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7ZGVzY3JpcHRpb248
YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNwOyAmbmJzcDsgJm5ic3A7Jm5ic3A7JnF1
b3Q7Tm90IGVxdWFsIHRvLiZxdW90Ozs8YnIgY2xhc3M9IiI+DQombmJzcDsgJm5ic3A7ICZuYnNw
OyB9PGJyIGNsYXNzPSIiPg0KJm5ic3A7ICZuYnNwOyB9PC9mb250PjwvZGl2Pg0KPGRpdj48YnIg
Y2xhc3M9IiI+DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2PkNoZWVycyw8L2Rpdj4NCjxkaXY+PGJyIGNs
YXNzPSIiPg0KPC9kaXY+DQo8ZGl2PkVpbmFyPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFz
cz0iIj4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2PjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3RlIHR5
cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiAyNyBGZWIgMjAxOCwgYXQgMDk6
MjAsIEVsaW90IExlYXIgJmx0OzxhIGhyZWY9Im1haWx0bzpsZWFyQGNpc2NvLmNvbSIgY2xhc3M9
IiI+bGVhckBjaXNjby5jb208L2E+Jmd0OyB3cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUt
aW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiB0ZXh0PSIjMDAwMDAw
IiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0iIj4NCjxwIGNsYXNzPSIiPlRoaXMgZWRpdCBkb2Vz
bid0IHNlZW0gY29ycmVjdCB0byBtZSBiZWNhdXNlIG5vdyB3ZSBoYXZlIGEgY2hvaWNlIHdpdGgg
YSBzaW5nbGUgY2FzZSwgd2l0aCByYW5nZSBoYXZpbmcgYmVlbiByZW1vdmVkLiZuYnNwOyBDYW4g
d2UgcGxlYXNlIHJldmVydCBhbmQgcHJvY2VlZD88YnIgY2xhc3M9IiI+DQo8L3A+DQo8YnIgY2xh
c3M9IiI+DQo8ZGl2IGNsYXNzPSJtb3otY2l0ZS1wcmVmaXgiPk9uIDI2LjAyLjE4IDIwOjI0LCBN
YWhlc2ggSmV0aGFuYW5kYW5pIHdyb3RlOjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPGJsb2NrcXVv
dGUgdHlwZT0iY2l0ZSIgY2l0ZT0ibWlkOkRENkE4RTkwLTUzREUtNDIyRi1BQjkxLUEzNTQ3Mjk4
QTEzNUBnbWFpbC5jb20iIGNsYXNzPSIiPg0KQSBwdWxsIHJlcXVlc3QgdG8gYWRkcmVzcyBMQywg
c2hlcGhlcmQsIHRoaXMgYW5kIHRoZSBvdGhlciBjb21tZW50cywgaW5jbHVkaW5nIGRlcml2ZWQt
ZnJvbSgpLCBjYW4gYmUgcmV2aWV3ZWQgaGVyZToNCjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIi
Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPjxhIGhyZWY9Imh0dHBzOi8vZ2l0aHViLmNvbS9uZXRt
b2Qtd2cvYWNsLW1vZGVsL3B1bGwvMjQiIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+
aHR0cHM6Ly9naXRodWIuY29tL25ldG1vZC13Zy9hY2wtbW9kZWwvcHVsbC8yNDwvYT48L2Rpdj4N
CjxkaXYgY2xhc3M9IiI+PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPlRoYW5r
cy48YnIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjxibG9ja3F1b3Rl
IHR5cGU9ImNpdGUiIGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj5PbiBGZWIgMjYsIDIwMTgsIGF0
IDEyOjE1IEFNLCBFbGlvdCBMZWFyICZsdDs8YSBocmVmPSJtYWlsdG86bGVhckBjaXNjby5jb20i
IGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bGVhckBjaXNjby5jb208L2E+Jmd0OyB3
cm90ZTo8L2Rpdj4NCjxiciBjbGFzcz0iQXBwbGUtaW50ZXJjaGFuZ2UtbmV3bGluZSI+DQo8ZGl2
IGNsYXNzPSIiPg0KPGRpdiB0ZXh0PSIjMDAwMDAwIiBiZ2NvbG9yPSIjRkZGRkZGIiBjbGFzcz0i
Ij4NCjxwIGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwvcD4NCjxiciBjbGFzcz0iIj4NCjxkaXYg
Y2xhc3M9Im1vei1jaXRlLXByZWZpeCI+T24gMjYuMDIuMTggMDY6NTUsIE1haGVzaCBKZXRoYW5h
bmRhbmkgd3JvdGU6PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRl
IiBjaXRlPSJtaWQ6MDJENDU0MUUtRkY4My00MUFELUEwMjYtQTFBQjg1N0UwQTYyQGdtYWlsLmNv
bSIgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGJsb2NrcXVvdGUgdHlwZT0iY2l0ZSIgY2xh
c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIiBzdHlsZT0i
cGFnZToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgV29yZFNlY3Rpb24xOyBmb250LWZhbWls
eTogSGVsdmV0aWNhOw0KICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6IDEycHg7
IGZvbnQtc3R5bGU6IG5vcm1hbDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDsgZm9udC13ZWlnaHQ6DQogICAgICAgICAgICAgICAgICAgICAgICAg
IG5vcm1hbDsgbGV0dGVyLXNwYWNpbmc6IG5vcm1hbDsgdGV4dC1hbGlnbjoNCiAgICAgICAgICAg
ICAgICAgICAgICAgICAgc3RhcnQ7IHRleHQtaW5kZW50OiAwcHg7IHRleHQtdHJhbnNmb3JtOiBu
b25lOw0KICAgICAgICAgICAgICAgICAgICAgICAgICB3aGl0ZS1zcGFjZTogbm9ybWFsOyB3b3Jk
LXNwYWNpbmc6IDBweDsNCiAgICAgICAgICAgICAgICAgICAgICAgICAgLXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICBiYWNrZ3JvdW5kLWNv
bG9yOiByZ2IoMjU1LCAyNTUsIDI1NSk7Ij4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IGNsYXNzPSIi
Pg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4gMGluIDAuMDAwMXB0Ow0KICAgICAgICAgICAgICAg
ICAgICAgICAgICAgICAgICBmb250LXNpemU6IDEycHQ7IGZvbnQtZmFtaWx5Og0KICAgICAgICAg
ICAgICAgICAgICAgICAgICAgICAgICAmcXVvdDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7IiBjbGFz
cz0iIj4NCjxiciBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+PC9vOnA+PC9kaXY+DQo8YmxvY2tx
dW90ZSBzdHlsZT0ibWFyZ2luLXRvcDogNXB0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICBtYXJnaW4tYm90dG9tOiA1cHQ7IiBjbGFzcz0iIiB0eXBlPSJjaXRlIj4NCjxkaXYgY2xh
c3M9IiI+DQo8ZGl2IGNsYXNzPSIiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdp
bjoNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgMGluIDBpbiAxMnB0OyBm
b250LXNpemU6IDEycHQ7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGZv
bnQtZmFtaWx5OiAmcXVvdDtUaW1lcyBOZXcNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAg
ICAgICAgICAgUm9tYW4mcXVvdDs7Ij4NCjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZu
YnNwO1BTOiBBbmQgdGhpcyBpcyBub3QgYSBzaGVwaGVyZCBkaXJlY3RpdmUsIGJ1dCBJIGZvdW5k
IHRoZSB3aG9sZTxzcGFuIGNsYXNzPSJBcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bh
bj48YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmcXVvdDtzb3Vy
Y2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvciZxdW90OyBzeW50YXggY2x1bXN5LiAmbmJzcDtJJ20g
c3VycHJpc2VkPGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7aXQg
ZGlkbid0IGxvb2sgc29tZXRoaW5nIGxpa2U6PGJyIGNsYXNzPSIiPg0KPGJyIGNsYXNzPSIiPg0K
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7T0xE
PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O3NvdXJj
ZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yJmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtwb3J0LXJhbmdlLW9yLW9w
ZXJhdG9yJmd0OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtyYW5nZSZndDs8YnIgY2xhc3M9IiI+
DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7bG93ZXItcG9ydCZndDsxNjM4NCZsdDsvbG93ZXItcG9y
dCZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7dXBwZXItcG9ydCZndDs2
NTUzNSZsdDsvdXBwZXItcG9ydCZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L3JhbmdlJmd0
OzxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZsdDsvcG9ydC1yYW5nZS1vci1vcGVyYXRvciZndDs8YnIgY2xhc3M9IiI+DQom
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L3NvdXJjZS1wb3J0LXJhbmdlLW9y
LW9wZXJhdG9yJmd0OzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtzb3VyY2UtcG9ydC1yYW5nZS1vci1vcGVyYXRvciZndDs8
YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbHQ7cG9ydC1yYW5nZS1vci1vcGVyYXRvciZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7b3BlcmF0
b3ImZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O29wZXJhdG9yJmd0O2VxJmx0Oy9v
cGVyYXRvciZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7cG9ydCZndDsyMSZsdDsv
cG9ydCZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L29wZXJhdG9yJmd0OzxiciBjbGFzcz0iIj4NCiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvcG9ydC1yYW5n
ZS1vci1vcGVyYXRvciZndDs8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbHQ7L3NvdXJjZS1wb3J0LXJhbmdlLW9yLW9wZXJhdG9yJmd0OzxiciBjbGFzcz0i
Ij4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwO05FVzxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDtzb3VyY2UtcG9ydCZndDs8YnIgY2xhc3M9IiI+
DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7cmFuZ2Um
Z3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O2xvd2VyJmd0OzE2Mzg0Jmx0Oy9sb3dlciZndDs8YnIgY2xh
c3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbHQ7dXBwZXImZ3Q7NjU1MzUmbHQ7L3VwcGVyJmd0OzxiciBjbGFzcz0iIj4NCiZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZsdDsvcmFuZ2UmZ3Q7
PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy9zb3Vy
Y2UtcG9ydCZndDs8YnIgY2xhc3M9IiI+DQo8YnIgY2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm
bmJzcDsmbmJzcDsmbmJzcDsmbHQ7c291cmNlLXBvcnQmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0O29wZXJhdG9yJmd0Ozxi
ciBjbGFzcz0iIj4NCiZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu
YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw
OyZuYnNwOyZuYnNwOyZsdDtvcGVyYXRvciZndDtlcSZsdDsvb3BlcmF0b3ImZ3Q7PGJyIGNsYXNz
PSIiPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jmx0O3BvcnQmZ3Q7MjEmbHQ7L3BvcnQmZ3Q7PGJyIGNsYXNzPSIiPg0KJm5ic3A7Jm5i
c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7
Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jmx0Oy9vcGVyYXRvciZndDs8YnIg
Y2xhc3M9IiI+DQombmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz
cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbHQ7L3NvdXJjZS1w
b3J0Jmd0OzxvOnAgY2xhc3M9IiI+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2tx
dW90ZT4NCjxkaXYgY2xhc3M9IiI+DQo8ZGl2IHN0eWxlPSJtYXJnaW46IDBpbiAwaW4gMC4wMDAx
cHQ7DQogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1zaXplOiAxMnB0OyBm
b250LWZhbWlseToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmcXVvdDtUaW1l
cyBOZXcgUm9tYW4mcXVvdDs7IiBjbGFzcz0iIj4NCjxvOnAgY2xhc3M9IiI+Jm5ic3A7PC9vOnA+
PC9kaXY+DQo8L2Rpdj4NCjxkaXYgc3R5bGU9Im1hcmdpbjogMGluIDBpbiAwLjAwMDFwdDsNCiAg
ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZm9udC1zaXplOiAxMnB0OyBmb250LWZhbWls
eToNCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJnF1b3Q7VGltZXMgTmV3IFJvbWFu
JnF1b3Q7OyIgY2xhc3M9IiI+DQpEaWQgeW91IHRyeSBtYWtpbmcgdGhlIGNoYW5nZSBpbiB0aGUg
bW9kZWwgdG8gc2VlIGlmIGl0IHdvcms/IEl0IHdpbGwgY29tcGxhaW4gdGhhdCAmbHQ7cmFuZ2Um
Z3Q7IGlzIGFscmVhZHkgdXNlZCB3aXRoaW4gdGhlIGNvbnRhaW5lciBhbmQgdGhhdCBpdCBjYW5u
b3QgYmUgcmVwZWF0ZWQgKGZvciBkZXN0aW5hdGlvbi1wb3J0KS48bzpwIGNsYXNzPSIiPjwvbzpw
PjwvZGl2Pg0KPC9kaXY+DQo8ZGl2IGNsYXNzPSIiPg0KPGRpdiBzdHlsZT0ibWFyZ2luOiAwaW4g
MGluIDAuMDAwMXB0Ow0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmb250LXNpemU6
IDEycHQ7IGZvbnQtZmFtaWx5Og0KICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmcXVv
dDtUaW1lcyBOZXcgUm9tYW4mcXVvdDs7IiBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCiZsdDtL
RU5UJmd0OyBObywgSSBkaWQgbm90LCBub3IgZG8gSSBpbnRlbmQgdG8gZ2V0IHRoYXQgZGVlcCBp
bnRvIGl0LiZuYnNwOyBCdXQgSSByZWNhbGwgdGhhdCBLcmlzdGlhbiBtYWRlIHRoZSBzYW1lIGNv
bW1lbnQgYmVmb3JlLCBhbmQgd2FzIG1ha2luZyBwdWxsIHJlcXVlc3RzIGJlZm9yZSwgc28gbWF5
YmUgaGUgY2FuIHN1Z2dlc3Qgc29tZXRoaW5nPzwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2
Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8ZGl2IGNsYXNzPSIiPjxiciBjbGFzcz0iIj4NCjwv
ZGl2Pg0KS3Jpc3RpYW7igJlzIHN1Z2dlc3Rpb24gcmVxdWlyZXMgY2hhbmdpbmcgdGhlIG1vZHVs
ZS4gSXQgaXMgbm90IGFuIGVkaXRvcmlhbCBjaGFuZ2UuIEFuZCB0aGF0IGNoYW5nZSB3aWxsIGhh
dmUgYW4gaW1wYWN0IG9uIHRoZSBNVUQgZHJhZnQsIHdoaWNoIGhhcyBiZWVuIHNlbnQgZm9yIHB1
YmxpY2F0aW9uLiZuYnNwOzwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YnIgY2xhc3M9IiI+DQo8L2Rp
dj4NCjwvYmxvY2txdW90ZT4NCjxiciBjbGFzcz0iIj4NCkFzIGl0IGhhcHBlbnMsIHdlIGZvdW5k
IGEgYnVnIGluIG91ciBhdWdtZW50IHN0YXRlbWVudHMsIGFuZCBzbyB3ZSB3aWxsIG5lZWQgdG8g
cmV2IG9uZSBtb3JlIHRpbWUuJm5ic3A7IElmIHRoZSBjaGFuZ2UgY2FuIGJlIG1hZGUgcXVpY2ts
eSwgSSBjYW4gbGl2ZSB3aXRoIGl0LjxiciBjbGFzcz0iIj4NCjxiciBjbGFzcz0iIj4NCkVsaW90
PGJyIGNsYXNzPSIiPg0KPC9kaXY+DQo8L2Rpdj4NCjwvYmxvY2txdW90ZT4NCjwvZGl2Pg0KPGJy
IGNsYXNzPSIiPg0KPGRpdiBjbGFzcz0iIj4NCjxkaXYgY2xhc3M9IiI+TWFoZXNoIEpldGhhbmFu
ZGFuaTwvZGl2Pg0KPGRpdiBjbGFzcz0iIj48YSBocmVmPSJtYWlsdG86bWpldGhhbmFuZGFuaUBn
bWFpbC5jb20iIGNsYXNzPSIiIG1vei1kby1ub3Qtc2VuZD0idHJ1ZSI+bWpldGhhbmFuZGFuaUBn
bWFpbC5jb208L2E+PC9kaXY+DQo8L2Rpdj4NCjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9ibG9j
a3F1b3RlPg0KPGJyIGNsYXNzPSIiPg0KPC9kaXY+DQpfX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fXzxiciBjbGFzcz0iIj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8
YnIgY2xhc3M9IiI+DQo8YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIiBjbGFzcz0iIj5u
ZXRtb2RAaWV0Zi5vcmc8L2E+PGJyIGNsYXNzPSIiPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cuaWV0
Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9uZXRtb2QiIGNsYXNzPSIiPmh0dHBzOi8vd3d3LmlldGYu
b3JnL21haWxtYW4vbGlzdGluZm8vbmV0bW9kPC9hPjxiciBjbGFzcz0iIj4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPC9kaXY+DQo8YnIgY2xhc3M9IiI+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRt
bD4NCg==

--_000_DC341012FDF845D3BCA5F4B7E1BCC2EEciscocom_--


From nobody Tue Feb 27 06:03:15 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6FE712D87B for ; Tue, 27 Feb 2018 06:03:13 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level: 
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MHrAJXIcche9 for ; Tue, 27 Feb 2018 06:03:12 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 50CB112D876 for ; Tue, 27 Feb 2018 06:03:12 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1RDx5fi014146; Tue, 27 Feb 2018 06:03:11 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=kIZZckLUDh0kQn24Qbic+MyaQCBygXEDWna9RKvdKrM=; b=SIOgB0E6zpmTLWSeHeKSJkDCfwXqMG9tqRikKV86QOYzLyMfGboHXLYr64cHHw2cRMeP RbRKVcJotgdHmxfTQSBZJohl07pgckGMaxzq4RGjnoHcsbidU4r4TO7pLr/AKUMwJr5f qesxPjFYuvqkuarPQ4l5//YwaL+mAIGdFr965cjmtCWBEiAjRmxsVNJOap6NrpmgYOVL IcGOfpRUjqtfjcxBzF/zBr/XnwjExIY1jpU+nU7JbmSUM7PH0FAV6+rJggn7Toq6jXg1 kFgKXGr6Q33Jmr2EBvNluJNVbMVVCNGjweHRrBurcN/3/Bo2Eo/AZq3CAf9DOPn84CZz Gw== 
Received: from nam02-cy1-obe.outbound.protection.outlook.com (mail-cys01nam02lp0054.outbound.protection.outlook.com [207.46.163.54]) by mx0a-00273201.pphosted.com with ESMTP id 2gd829827u-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Tue, 27 Feb 2018 06:03:09 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB2953.namprd05.prod.outlook.com (10.168.176.141) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.548.6; Tue, 27 Feb 2018 14:03:07 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b%3]) with mapi id 15.20.0548.013; Tue, 27 Feb 2018 14:03:07 +0000
From: Kent Watsen 
To: Juergen Schoenwaelder 
CC: Martin Bjorklund , "netmod@ietf.org" 
Thread-Topic: [netmod] Proposal for minimalist full NMDA support in schema mount
Thread-Index: AQHTq/ojL3reZVxzTECb6kWhgoY5faOwqXoAgAESIACAAdqFAIAB4X+AgAEg5QCAADcXgIABIxwAgABcuFc=
Date: Tue, 27 Feb 2018 14:03:07 +0000
Message-ID: <02FF992B-BFFD-4E7E-A2F5-250105AFDDD0@juniper.net>
References: <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87lgfg9ded.fsf@chopps.org> <20180226.160921.622063322182936097.mbj@tail-f.com>, <20180227083116.xtlnju34s7ksjntc@elstar.local>
In-Reply-To: <20180227083116.xtlnju34s7ksjntc@elstar.local>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [96.231.191.4]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB2953; 7:Z1teg9N4kCiRAo/WQNGmmn7gwebrKe2I/IzmDMBAXW5nyasBl/VGb/pRZDkhYwO7oT5ZUenyhBlZuNEffSYdoKF09IoCzE0w9e40GjLYAl4qRKWu5hFJRWJy8DQmSpY/qY2r0LzREg01vonlH2h3TErIY5fmRpbmlJeWtf4JaAOdPaxfuBCgLjW9B0gZcvxu61/iVZ0K0zzS3ZNDb+IBp02FaLXAgEZWphBaLBGLjRZubivaT/w+qtECRYsCtLkX
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: ca140ac6-b9be-49a7-2d9c-08d57dead436
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB2953; 
x-ms-traffictypediagnostic: DM5PR05MB2953:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:;
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(3002001)(3231220)(944501161)(93006095)(93001095)(10201501046)(6055026)(6041288)(20161123564045)(20161123562045)(20161123558120)(20161123560045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:DM5PR05MB2953; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB2953; 
x-forefront-prvs: 05961EBAFC
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(376002)(346002)(39380400002)(366004)(396003)(39860400002)(189003)(199004)(26005)(81166006)(81156014)(6916009)(3280700002)(6246003)(186003)(4326008)(82746002)(36756003)(561944003)(478600001)(33656002)(93886005)(7736002)(54906003)(54896002)(6512007)(8676002)(3660700001)(8936002)(25786009)(14454004)(83716003)(53936002)(5250100002)(5660300001)(229853002)(102836004)(2950100002)(3846002)(6116002)(6506007)(59450400001)(2906002)(97736004)(316002)(86362001)(68736007)(106356001)(76176011)(6486002)(66066001)(2900100001)(6436002)(99286004)(105586002); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB2953; H:DM5PR05MB3484.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)
x-microsoft-antispam-message-info: 7QBjdRqbRgZLgv/iNPmKhr3hHzEzIV3OdvntTQ1eHoM8w3dZCrDp24FVNdmq8ThbdpfhFhH86QItPN9ji+i7rpeiwzuo4ZwV73Y8d95EBX0pCRMeDKj2aIiXpyg102sg/PgCgkYMj338LfPZWlIHHlgYUs9f9bA4v1OOjHe+NuE=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_02FF992BBFFD4E7EA2F5250105AFDDD0junipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: ca140ac6-b9be-49a7-2d9c-08d57dead436
X-MS-Exchange-CrossTenant-originalarrivaltime: 27 Feb 2018 14:03:07.6781 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB2953
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-27_05:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=884 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802270176
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 14:03:14 -0000

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

DQoNClNvIGl0IHRoaXMgYSBwb3NzaWJsZSB3YXkgb3V0IG9mIHRoZSBjdXJyZW50IHNpdHVhdGlv
bj8gV2UgcHVibGlzaCBhDQp0cmltbWVkIGRvd24gZG9jdW1lbnQgdGhhdCBqdXN0IGRlZmluZXMg
dGhlIG1vdW50IHBvaW50IGV4dGVuc2lvbiBhbmQNCndlIGRvIGFuIHVwZGF0ZSBvZiB0aGlzIGRv
Y3VtZW50IHRoYXQgYWRkcyBhbGwgdGhlIGRldGFpbHMgbmVlZGVkIHRvDQpvYnRhaW4gdGhlIHNj
aGVtYSBpbmZvcm1hdGlvbj8NCg0KL2pzDQoNCisxDQoNClRoaXMgd2FzIHNvbWV0aGluZyBJIHN1
Z2dlc3RlZCBhIHdoaWxlIGJhY2suICBUaG91Z2ggSSBkaWRu4oCZdCBkZXRhaWwgdGhpcyBzcGVj
aWZpYyBwcm9wb3NhbCwgcmF0aGVyIHNvbWV0aGluZyBhbG9uZyB0aGUgbGluZXMgb2YgcmVtb3Zp
bmcgdW5uZWNlc3NhcnkgcGFydHMsIGluIG9yZGVyIHRvIHJlZHVjZSB0aGUgZGVidCBjYXJyaWVk
IGZvcndhcmQgYXMgbXVjaCBhcyBwb3NzaWJsZS4NCg0KS2VudCAgIC8vIGNvbnRyaWJ1dG9yDQo=

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

PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i
dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IGRpcj0iYXV0byI+DQo8
YnI+DQo8YnI+DQo8YmxvY2txdW90ZSB0eXBlPSJjaXRlIj4NCjxkaXY+PHNwYW4+U28gaXQgdGhp
cyBhIHBvc3NpYmxlIHdheSBvdXQgb2YgdGhlIGN1cnJlbnQgc2l0dWF0aW9uPyBXZSBwdWJsaXNo
IGE8L3NwYW4+PGJyPg0KPHNwYW4+dHJpbW1lZCBkb3duIGRvY3VtZW50IHRoYXQganVzdCBkZWZp
bmVzIHRoZSBtb3VudCBwb2ludCBleHRlbnNpb24gYW5kPC9zcGFuPjxicj4NCjxzcGFuPndlIGRv
IGFuIHVwZGF0ZSBvZiB0aGlzIGRvY3VtZW50IHRoYXQgYWRkcyBhbGwgdGhlIGRldGFpbHMgbmVl
ZGVkIHRvPC9zcGFuPjxicj4NCjxzcGFuPm9idGFpbiB0aGUgc2NoZW1hIGluZm9ybWF0aW9uPzwv
c3Bhbj48YnI+DQo8c3Bhbj48L3NwYW4+PGJyPg0KPHNwYW4+L2pzPC9zcGFuPjxicj4NCjwvZGl2
Pg0KPC9ibG9ja3F1b3RlPg0KPGJyPg0KPGRpdj4mIzQzOzE8L2Rpdj4NCjxkaXY+PGJyPg0KPC9k
aXY+DQo8ZGl2PlRoaXMgd2FzIHNvbWV0aGluZyBJIHN1Z2dlc3RlZCBhIHdoaWxlIGJhY2suICZu
YnNwO1Rob3VnaCBJIGRpZG7igJl0IGRldGFpbCB0aGlzIHNwZWNpZmljIHByb3Bvc2FsLCByYXRo
ZXIgc29tZXRoaW5nIGFsb25nIHRoZSBsaW5lcyBvZiByZW1vdmluZyB1bm5lY2Vzc2FyeSBwYXJ0
cywgaW4gb3JkZXIgdG8gcmVkdWNlIHRoZSBkZWJ0IGNhcnJpZWQgZm9yd2FyZCBhcyBtdWNoIGFz
IHBvc3NpYmxlLjwvZGl2Pg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+S2VudCAmbmJzcDsgLy8g
Y29udHJpYnV0b3ImbmJzcDs8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg==

--_000_02FF992BBFFD4E7EA2F5250105AFDDD0junipernet_--


From nobody Tue Feb 27 09:14:35 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1F241124F57; Tue, 27 Feb 2018 09:14:31 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level: 
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vSmG2nSGB6wm; Tue, 27 Feb 2018 09:14:28 -0800 (PST)
Received: from mail-pl0-x232.google.com (mail-pl0-x232.google.com [IPv6:2607:f8b0:400e:c01::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8A437126B72; Tue, 27 Feb 2018 09:14:28 -0800 (PST)
Received: by mail-pl0-x232.google.com with SMTP id y8-v6so1293072pll.13; Tue, 27 Feb 2018 09:14:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;  h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=14qLO3dih/i1NiN4iPOCeoWUPao+qqGSb0wCzVtbS4c=; b=ZjAnNSMFvHOiSYpORcvq+BMapmmPFAr4wBaawCekv6BqJOEz2sb0+mNB/VTXNnRAQf jciSd+IOWXGk86gryRPSgWX43bY1AbbwigqjIeLn7l1HNZOr0Ivt2rjLYpe5YDDb6vPi /EN5SW6VKnq7494NrQDaPnEQT2dTwbL4umg1PawPJ2btYrpkDEfyI9fnyJoEqr6tV4t1 4Vdg7CRgmHONMYw4b3zSmd7Pl53z/jLtvUm9tF3afySln3xl5dEZiSPo9N7/peZznH0u b2KQqC88BMoge5jxNgUS9d33UhDHq5UqQNj2sJxB6jYkugn/V7K5fMJUMleHBTaF+AAx Pxvg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=14qLO3dih/i1NiN4iPOCeoWUPao+qqGSb0wCzVtbS4c=; b=n/nEdjoR978Na2KmdHMtGx22tXTn+4iv/EWYi7G0hoKoUeO95j/1aPD6AENvIbP+3y R6blVw6RHySs31NqSsEqDfP1WGkpMmiJW4xXk014P5D6VSoyRie56LuLa08XTCYgq4UC +v6OY9x2lBnspnF1Hm8RoamniT2jRzTkR2msGTcfBufeedfgWxULcm+4/3uonWY/fTCx jjiqVdJsuRlfmo5WZR6rOFvnc/mn2y5QM1sYl4sac+Ai20qW5MBPft9lFosvs45kRAAI 5St04drMk0CQ6kbodGxm7JPyZyASv6+XUws+dJZ616g3EcU515d8CcaqdBAMCMPowqQe Sqdg==
X-Gm-Message-State: APf1xPCs42LERQCdOm59jhhmNVXioDL4mzndcnZZSKWonhx06dWimeBa +fABY1o9idWk8qYDvlkBUMsIUG3c
X-Google-Smtp-Source: AH8x227wpfZWVbGU1HeergPBuDCEOkWeNwLc0lRYp/U3LK+7FGV5UFAYgaQjwLJBbS8yyMJbql7USg==
X-Received: by 2002:a17:902:5a5:: with SMTP id f34-v6mr15182937plf.134.1519751667992;  Tue, 27 Feb 2018 09:14:27 -0800 (PST)
Received: from ?IPv6:2601:647:4700:1280:e12d:29bc:1dca:d2aa? ([2601:647:4700:1280:e12d:29bc:1dca:d2aa]) by smtp.gmail.com with ESMTPSA id p10sm22925389pfe.187.2018.02.27.09.14.26 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 27 Feb 2018 09:14:27 -0800 (PST)
From: Mahesh Jethanandani 
Message-Id: <8004EA4C-24D2-4969-B8EB-E678C54D254A@gmail.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_065A2B8B-5561-41ED-A347-6692B1CA5001"
Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\))
Date: Tue, 27 Feb 2018 09:20:18 -0800
In-Reply-To: 
Cc: Eliot Lear , Warren Kumari , "draft-ietf-netmod-acl-model@ietf.org" ,  "netmod@ietf.org" 
To: "Einar Nilsen-Nygaard (einarnn)" 
References: <14BA9086-69D4-4BAF-A7C7-0EB1F3F400BB@juniper.net> <2864E0CF-D038-4FDA-B69C-FD43F486BF17@gmail.com> <8D3773A8-ECA6-406A-B28D-6DD44F951F10@juniper.net> <02D4541E-FF83-41AD-A026-A1AB857E0A62@gmail.com> <1a4a3f5d-5211-8b13-308e-3b124c836135@cisco.com>   
X-Mailer: Apple Mail (2.3445.5.20)
Archived-At: 
Subject: Re: [netmod] ACL draft issues found during shepherd writeup
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 17:14:31 -0000

--Apple-Mail=_065A2B8B-5561-41ED-A347-6692B1CA5001
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

Guys,

Before we start proposing whole set of changes, please verify that the =
model is not doing what it was supposed to. The only difference between =
the changes below and what is in the model is that instead of it being a =
repeat for source and destination ports, the code below exists as a =
grouping.

Cheers.

> On Feb 27, 2018, at 3:01 AM, Einar Nilsen-Nygaard (einarnn) =
 wrote:
>=20
> What Kristian and I discussed, what Sonal and I had discussed, and =
what I thought we had accepted as a proposed change was something like:
>=20
>     choice source-port-range-or-operator {
>       case range {
>         leaf source-port-lower {
>           type inet:port-number;
>           must ". <=3D ../source-port-upper" {
>             error-message
>               "The source-port-lower must be less than or equal to
>                source-port-upper";
>           }
>           mandatory true;
>           description
>             "Lower boundary for port.";
>         }
>         leaf source-port-upper {
>           type inet:port-number;
>           mandatory true;
>           description
>             "Lower boundary for port.";
>         }
>       }
>       case operator {
>         leaf source-operator {
>           type operator;
>           mandatory true;
>         }
>         leaf source-port {
>           type inet:port-number;
>           mandatory true;
>           description
>             "Port value to match.";
>         }
>       }
>     }
>=20
> =E2=80=A6and with the same pattern for the destination. The type =
=E2=80=9Coperator=E2=80=9D was defined as:
>=20
>   typedef operator {
>     type enumeration {
>       enum lte {
>         description
>           "Less than or equal to.";
>       }
>       enum gte {
>         description
>           "Greater than or equal to.";
>       }
>       enum eq {
>         description
>           "Equal to.";
>       }
>       enum neq {
>         description
>           "Not equal to.";
>       }
>     }
>=20
> Cheers,
>=20
> Einar
>=20
>=20
>> On 27 Feb 2018, at 09:20, Eliot Lear > wrote:
>>=20
>> This edit doesn't seem correct to me because now we have a choice =
with a single case, with range having been removed.  Can we please =
revert and proceed?
>>=20
>> On 26.02.18 20:24, Mahesh Jethanandani wrote:
>>> A pull request to address LC, shepherd, this and the other comments, =
including derived-from(), can be reviewed here:
>>>=20
>>> https://github.com/netmod-wg/acl-model/pull/24 =

>>>=20
>>> Thanks.
>>>=20
>>>> On Feb 26, 2018, at 12:15 AM, Eliot Lear > wrote:
>>>>=20
>>>>=20
>>>>=20
>>>> On 26.02.18 06:55, Mahesh Jethanandani wrote:
>>>>>>=20
>>>>>>>=20
>>>>>>>=20
>>>>>>>  PS: And this is not a shepherd directive, but I found the whole=20=

>>>>>>>      "source-port-range-or-operator" syntax clumsy.  I'm =
surprised
>>>>>>>      it didn't look something like:
>>>>>>>=20
>>>>>>>          OLD
>>>>>>>                
>>>>>>>                   
>>>>>>>                     
>>>>>>>                       16384
>>>>>>>                       65535
>>>>>>>                     
>>>>>>>                   
>>>>>>>                
>>>>>>>=20
>>>>>>>                
>>>>>>>                  
>>>>>>>                    
>>>>>>>                      eq
>>>>>>>                      21
>>>>>>>                    
>>>>>>>                  
>>>>>>>                
>>>>>>>=20
>>>>>>>          NEW
>>>>>>>=20
>>>>>>>                
>>>>>>>                  
>>>>>>>                    16384
>>>>>>>                    65535
>>>>>>>                  
>>>>>>>                
>>>>>>>=20
>>>>>>>                
>>>>>>>                  
>>>>>>>                    eq
>>>>>>>                    21
>>>>>>>                  
>>>>>>>                
>>>>>>>=20
>>>>>> =20
>>>>>> Did you try making the change in the model to see if it work? It =
will complain that  is already used within the container and that =
it cannot be repeated (for destination-port).
>>>>>>=20
>>>>>>  No, I did not, nor do I intend to get that deep into it.  =
But I recall that Kristian made the same comment before, and was making =
pull requests before, so maybe he can suggest something?
>>>>>=20
>>>>> Kristian=E2=80=99s suggestion requires changing the module. It is =
not an editorial change. And that change will have an impact on the MUD =
draft, which has been sent for publication.=20
>>>>>=20
>>>>=20
>>>> As it happens, we found a bug in our augment statements, and so we =
will need to rev one more time.  If the change can be made quickly, I =
can live with it.
>>>>=20
>>>> Eliot
>>>=20
>>> Mahesh Jethanandani
>>> mjethanandani@gmail.com 
>>=20
>> _______________________________________________
>> netmod mailing list
>> netmod@ietf.org 
>> https://www.ietf.org/mailman/listinfo/netmod =

>=20

Mahesh Jethanandani
mjethanandani@gmail.com


--Apple-Mail=_065A2B8B-5561-41ED-A347-6692B1CA5001
Content-Transfer-Encoding: quoted-printable
Content-Type: text/html;
	charset=utf-8

Guys,

Before we start proposing whole set of changes, please verify =
that the model is not doing what it was supposed to. The only difference =
between the changes below and what is in the model is that instead of it =
being a repeat for source and destination ports, the code below exists =
as a grouping.

Cheers.

On Feb 27, 2018, at 3:01 AM, =
Einar Nilsen-Nygaard (einarnn) <einarnn@cisco.com> wrote:







What Kristian and I discussed, what Sonal and I had discussed, and what =
I thought we had accepted as a proposed change was something like:



  =
  choice source-port-range-or-operator {

      case range {

        leaf source-port-lower {

          type inet:port-number;

          must ". <=3D =
../source-port-upper" {

            error-message

              "The =
source-port-lower must be less than or equal to

              =
 source-port-upper";

          }

          mandatory true;

          description

            "Lower boundary for =
port.";

        }

        leaf source-port-upper {

          type inet:port-number;

          mandatory true;

          description

            "Lower boundary for =
port.";

        }

      }

      case operator {

        leaf source-operator {

          type operator;
=

          mandatory true;

        }

        leaf source-port {

          type inet:port-number;

          mandatory true;

          description

            "Port value to =
match.";

        }

      }

    }







=E2=80=A6and with the same pattern for the destination. =
The type =E2=80=9Coperator=E2=80=9D was defined as:







  typedef operator {

    type enumeration {

      enum lte {

        description

          "Less than or equal to.";

      }

      enum gte {

        description

          "Greater than or equal to.";

      }

      enum eq {

        description

          "Equal to.";

      }

      enum neq {

        description

          "Not equal to.";

      }

    }









Cheers,







Einar














On 27 Feb 2018, at 09:20, Eliot Lear <lear@cisco.com> =
wrote:






This =
edit doesn't seem correct to me because now we have a choice with a =
single case, with range having been removed.  Can we please revert =
and proceed?






On 26.02.18 20:24, Mahesh Jethanandani =
wrote:





A pull request to address LC, shepherd, this and the other comments, =
including derived-from(), can be reviewed here:






https://github.com/netmod-wg/acl-model/pull/24







Thanks.







On Feb 26, 2018, at 12:15 AM, Eliot Lear <lear@cisco.com> wrote:













On 26.02.18 06:55, Mahesh Jethanandani =
wrote:

































 PS: And this is not a shepherd directive, but I found the =
whole 

     "source-port-range-or-operator" syntax =
clumsy.  I'm surprised

     it didn't look something like:



         OLD

=
            &n=
bsp;  <source-port-range-or-operator>

=
            &n=
bsp;     <port-range-or-operator>

=
            &n=
bsp;       <range>
=

=
            &n=
bsp;         <lower-port&g=
t;16384</lower-port>

=
            &n=
bsp;         <upper-port&g=
t;65535</upper-port>

=
            &n=
bsp;       </range>

=
            &n=
bsp;     </port-range-or-operator>

=
            &n=
bsp;  </source-port-range-or-operator>



=
            &n=
bsp;  <source-port-range-or-operator>

=
            &n=
bsp;    <port-range-or-operator>

=
            &n=
bsp;      <operator>

=
            &n=
bsp;        <operator>eq<=
/operator>

=
            &n=
bsp;        <port>21</por=
t>

=
            &n=
bsp;      </operator>

=
            &n=
bsp;    </port-range-or-operator>
=

=
            &n=
bsp;  </source-port-range-or-operator>



         NEW



=
            &n=
bsp;  <source-port>

=
            &n=
bsp;    <range>

=
            &n=
bsp;      <lower>16384</lower>
=
            &n=
bsp;      <upper>65535</upper>
=
            &n=
bsp;    </range>

=
            &n=
bsp;  </source-port>



=
            &n=
bsp;  <source-port>

=
            &n=
bsp;    <operator>

=
            &n=
bsp;      <operator>eq</operator>=
;

=
            &n=
bsp;      <port>21</port>

=
            &n=
bsp;    </operator>

=
            &n=
bsp;  </source-port>











 





Did you try making the change in the model to see if it work? It will =
complain that <range> is already used within the container and =
that it cannot be repeated (for destination-port).









<KENT> No, I did not, nor do I intend to get that deep into =
it.  But I recall that Kristian made the same comment before, and =
was making pull requests before, so maybe he can suggest =
something?
















Kristian=E2=80=99s suggestion requires changing the module. It is not an =
editorial change. And that change will have an impact on the MUD draft, =
which has been sent for publication. 










As it happens, we found a bug in our augment statements, and so we will =
need to rev one more time.  If the change can be made quickly, I =
can live with it.



Eliot














Mahesh Jethanandani


mjethanandani@gmail.com













_______________________________________________

netmod mailing list

netmod@ietf.org

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


















Mahesh Jethanandani
mjethanandani@gmail.com





=

--Apple-Mail=_065A2B8B-5561-41ED-A347-6692B1CA5001--


From nobody Tue Feb 27 15:12:57 2018
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 6A52E12E8E8; Tue, 27 Feb 2018 15:11:09 -0800 (PST)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 7bit
From: "\"IETF Secretariat\"" 
To: , 
Cc: bclaise@cisco.com, netmod@ietf.org
X-Test-IDTracker: no
X-IETF-IDTracker: 6.73.0
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <151977306943.5200.17635204910933164582.idtracker@ietfa.amsl.com>
Date: Tue, 27 Feb 2018 15:11:09 -0800
Archived-At: 
Subject: [netmod] netmod - Requested sessions have been scheduled for IETF 101
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Tue, 27 Feb 2018 23:11:10 -0000

Dear Lou Berger,

The session(s) that you have requested have been scheduled.
Below is the scheduled session information followed by
the original request. 

netmod Session 1 (2:00:00)
    Tuesday, Afternoon Session II 1550-1820
    Room Name: Blenheim size: 200
    ---------------------------------------------
    netmod Session 2 (1:30:00)
    Wednesday, Afternoon Session I 1330-1500
    Room Name: Blenheim size: 200
    ---------------------------------------------
    


Request Information:


---------------------------------------------------------
Working Group Name: Network Modeling
Area Name: Operations and Management Area
Session Requester: Lou Berger

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


People who must be present:
  Lou Berger
  Joel Jaeggli
  Benoit Claise
  Kent Watsen

Resources Requested:

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


From nobody Wed Feb 28 00:47:26 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A67D126B7E; Wed, 28 Feb 2018 00:47:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.31
X-Spam-Level: 
X-Spam-Status: No, score=-4.31 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=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 MMmpbr00vmdP; Wed, 28 Feb 2018 00:47:22 -0800 (PST)
Received: from office2.cesnet.cz (office2.cesnet.cz [IPv6:2001:718:1:101::144:244]) (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 BE7601243F6; Wed, 28 Feb 2018 00:47:22 -0800 (PST)
Received: from pckrejci.nat9.vcit.vutbr.net (unknown [IPv6:2001:67c:1220:80c:d0:552c:73a5:18da]) (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 A3ABC400067; Wed, 28 Feb 2018 09:47:18 +0100 (CET)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cesnet.cz; s=office2; t=1519807639; bh=joyVaDSemFL0sKvJMPE6QLsCjYgTevu5z1bs/8Tum7Y=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=cjNX2oKkQtofpl+eZ/ZNQPXP5u+LuioB3GSdGJcwuXZLdHBxNAvNU6dZguJFJRF1G r2pIslDWnGuRzx4sct5/2VuO/vPHDgGyquC5qbbDRiKasrXrHPex2CBuDL4BrbRiCh HSYUyWwM0/71n7Qrvk12ACi55k1QImFEKVuzVkdE=
To: Mikael Abrahamsson , Christian Hopps 
Cc: "netconf@ietf.org" , "netmod@ietf.org" 
References: <87o9ke9o63.fsf@chopps.org> <87vaemarb5.fsf@chopps.org> 
From: =?UTF-8?B?UmFkZWsgS3JlasSNw60=?= 
Message-ID: 
Date: Wed, 28 Feb 2018 09:47:18 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: 
Content-Type: text/plain; charset=iso-8859-2
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At: 
Subject: Re: [netmod] [Netconf] Open source filtering code?
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 08:47:25 -0000

Hi,
NETCONF filtering is actually implemented in our Netopeer2 NETCONF server=
 (where we use libyang to represent YANG data). libyang implements XPath =
on its data structures representing YANG data, so XPath filtering is real=
ly straightforward. Subtree filtering is implemented by transforming subt=
ree filter into XPath expressions. libyang has also Python bindings, so y=
ou could use it even in Python code.

Regards,
Radek


Dne 26.2.2018 v 09:38 Mikael Abrahamsson napsal(a):
> On Sat, 24 Feb 2018, Christian Hopps wrote:
>
>>
>> Still interested in any answers to this query; however, I thought I wo=
uld followup..
>
> Have you looked at libyang ?
>
> https://github.com/CESNET/libyang
>
> It's heavily used in Sysrepo/Netopeer2 for all the YANG related functio=
ns.
>



From nobody Wed Feb 28 10:28:53 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 636A6120727 for ; Wed, 28 Feb 2018 10:28:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level: 
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id O0BYGSaKt8_A for ; Wed, 28 Feb 2018 10:28:51 -0800 (PST)
Received: from smtp.chopps.org (smtp.chopps.org [54.88.81.56]) by ietfa.amsl.com (Postfix) with ESMTP id 174C11200E5 for ; Wed, 28 Feb 2018 10:28:51 -0800 (PST)
Received: from tops.chopps.org (47-50-69-38.static.klmz.mi.charter.com [47.50.69.38]) (using TLSv1.2 with cipher AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by smtp.chopps.org (Postfix) with ESMTPSA id 4CBE662A79; Wed, 28 Feb 2018 18:28:50 +0000 (UTC)
References: <87woz2a3x1.fsf@chopps.org> <596f5e0b-301e-e102-bcae-c3421b24455b@cisco.com> <87lgfg9ded.fsf@chopps.org> <20180226.160921.622063322182936097.mbj@tail-f.com> <20180227083116.xtlnju34s7ksjntc@elstar.local> <1519720727.10739.1.camel@nic.cz>
User-agent: mu4e 1.0; emacs 25.3.1
From: Christian Hopps 
To: Ladislav Lhotka 
Cc: netmod@ietf.org
In-reply-to: <1519720727.10739.1.camel@nic.cz>
Date: Wed, 28 Feb 2018 13:28:48 -0500
Message-ID: <87muztq87z.fsf@chopps.org>
MIME-Version: 1.0
Content-Type: text/plain; format=flowed
Archived-At: 
Subject: Re: [netmod] Proposal for minimalist full NMDA support in schema mount
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 18:28:52 -0000

Ladislav Lhotka  writes:

> On Tue, 2018-02-27 at 09:31 +0100, Juergen Schoenwaelder wrote:
>> On Mon, Feb 26, 2018 at 04:09:21PM +0100, Martin Bjorklund wrote:
>> > Hi,
>> >
>> > Christian Hopps  wrote:
>> > >
>> > > Hi Rob,
>> > >
>> > > You do realize that no-one trying to actually deploy and run networks
>> > > cares about live-discovery of different schema per datastore for the
>> > > same mount point right? Like 99.999% of the clients know where things
>> > > are supposed to reside and expect them to be there.
>> >
>> > But then why advertise anything at all?   We can do a *much* simpler
>> > solution by just having the mountpoint extension, and nothing else.
>> > Clients will know what to find anyway.
>> >
>>
>> So it this a possible way out of the current situation? We publish a
>> trimmed down document that just defines the mount point extension and
>> we do an update of this document that adds all the details needed to
>> obtain the schema information?
>
> I would say so. It would be immediately usable for the inline case.

This still requires that we pull the routing NI work from the RFC ED queue, change normative text (the document specifically states that use-schema MUST be present, although it does mention that that may be relaxed in the future) as well as the examples listing the schema/modules, this is going to require at least another run through WGLC. It's slightly less obnoxious than the original proposal as its simply removing stuff and losing functionality vs. changing functionality.

Thanks,
Chris.

> Lada
>
>>
>> /js
>>


From nobody Wed Feb 28 10:50:43 2018
Return-Path: 
X-Original-To: netmod@ietfa.amsl.com
Delivered-To: netmod@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BF2512426E for ; Wed, 28 Feb 2018 10:50:42 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.501
X-Spam-Level: 
X-Spam-Status: No, score=-0.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=1.989, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, T_DKIM_INVALID=0.01] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (2048-bit key) reason="fail (message has been altered)" header.d=juniper.net
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VPl_TujP2FoN for ; Wed, 28 Feb 2018 10:50:39 -0800 (PST)
Received: from mx0b-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (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 2A7361200E5 for ; Wed, 28 Feb 2018 10:50:39 -0800 (PST)
Received: from pps.filterd (m0108157.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.22/8.16.0.22) with SMTP id w1SI92hA013120; Wed, 28 Feb 2018 10:11:29 -0800
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : mime-version; s=PPS1017; bh=tlh70MuhyBBdNVSaYMalSSNAylYYxxxLeFyRTOM5HJA=; b=ZVr01iidfxJKdyzVh+HdEbIGxx0q3W2QtjzhVhqAdCcph0KyodgY42g/C9XZ81bgkQCT ETzVXC13fWX26gP8jmIXWUYb/E+F81FNLueqZMR+zfc7EiVdhLSc+iCtGoOqS6I1tSwH KtBcc9ANxysrFbdt+eCL62Kjb5X227UFYv7sn0RQjriiHFebk6HztfqXK5AYI55mSP1H aWalfgMfv7G7MN2sKhF64KbQbc/O4RxloYRgABeyh7o1jzHV18L14JN3B/piWm6Cf5y6 ldN1Z/gD9n8ByYDjT+90eXshkVsjSv3ALkM/yY2QCxw1EBMlPxgZoexwePTbhRjtmLxx Jg== 
Received: from nam01-sn1-obe.outbound.protection.outlook.com (mail-sn1nam01lp0113.outbound.protection.outlook.com [207.46.163.113]) by mx0a-00273201.pphosted.com with ESMTP id 2ge195015q-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Wed, 28 Feb 2018 10:11:28 -0800
Received: from DM5PR05MB3484.namprd05.prod.outlook.com (10.174.240.147) by DM5PR05MB3146.namprd05.prod.outlook.com (10.173.219.16) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.567.6; Wed, 28 Feb 2018 18:11:26 +0000
Received: from DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b]) by DM5PR05MB3484.namprd05.prod.outlook.com ([fe80::507:f464:b89a:c64b%3]) with mapi id 15.20.0548.014; Wed, 28 Feb 2018 18:11:25 +0000
From: Kent Watsen 
To: Mahesh Jethanandani 
CC: "Clyde Wildes (cwildes)" , "t.petch" , Yaron Sheffer , Ron Bonica , NETMOD Working Group , Benoit Claise 
Thread-Topic: [netmod] AD review of draft-ietf-netmod-syslog-model-20
Thread-Index: AQHTpZZd5Geu+8X2WUq2NsIzPrmhNqOj3UoAgAmtrxX//7BHAIACLXCAgAJ3xQCAAHZAAIAHiWIA
Date: Wed, 28 Feb 2018 18:11:25 +0000
Message-ID: 
References:  <922E608D-951A-459A-B515-B53834C805C1@juniper.net> <022001d3aa6a$c31895e0$4001a8c0@gateway.2wire.net>    
In-Reply-To: 
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
user-agent: Microsoft-MacOutlook/f.20.0.170309
x-originating-ip: [66.129.241.14]
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; DM5PR05MB3146; 7:kIPFP87p80pbVuhm0DQOmpq2YQmLaH3rYOxGz/ez01gIlLq9nWvmtm6b/iv1phSE+RQ+nnE9QX0OLK11uluAQyc6wcYFQwovdGbov2rXUrCpqZyKEp8xSsd1Zii26kT1/rJvHkYAcS3p83v0rrxKJC0gpLVRu3qj4rgJEMcpEsGu7/ZFkJO31EjGq9O/8wUW0ASBAd3eppNVB6zQfAQ+bZ7fVrq6Oq7ZFFybCOqwoBSUCn2K7bWijOeOS+5rXrcC
x-ms-exchange-antispam-srfa-diagnostics: SSOS;SSOR;
x-forefront-antispam-report: SFV:SKI; SCL:-1; SFV:NSPM; SFS:(10019020)(396003)(376002)(346002)(39380400002)(366004)(39860400002)(189003)(199004)(8936002)(8676002)(81156014)(81166006)(86362001)(575784001)(6916009)(1411001)(316002)(58126008)(229853002)(36756003)(2950100002)(7736002)(54906003)(14454004)(186003)(6486002)(966005)(83716003)(99286004)(26005)(4326008)(66066001)(3280700002)(76176011)(39060400002)(6506007)(53546011)(25786009)(3660700001)(102836004)(5660300001)(106356001)(478600001)(606006)(68736007)(53936002)(53946003)(97736004)(82746002)(105586002)(6116002)(236005)(93886005)(5250100002)(2906002)(6246003)(6436002)(33656002)(8666007)(54896002)(6306002)(6512007)(3846002)(2900100001); DIR:OUT; SFP:1102; SCL:1; SRVR:DM5PR05MB3146; H:DM5PR05MB3484.namprd05.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords;  MX:1; A:1; LANG:en; 
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: b4167a4b-b3dd-4aa1-f6ea-08d57ed6ae32
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(48565401081)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(2017052603307)(7153060)(7193020); SRVR:DM5PR05MB3146; 
x-ms-traffictypediagnostic: DM5PR05MB3146:
x-microsoft-antispam-prvs: 
x-exchange-antispam-report-test: UriScan:(28532068793085)(10436049006162)(138986009662008)(150554046322364)(85827821059158)(95692535739014)(21748063052155);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(8211001083)(6040501)(2401047)(8121501046)(5005006)(93006095)(93001095)(3231220)(944501217)(3002001)(10201501046)(6055026)(6041288)(20161123562045)(20161123558120)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(20161123560045)(6072148)(201708071742011); SRVR:DM5PR05MB3146; BCL:0; PCL:0; RULEID:; SRVR:DM5PR05MB3146; 
x-forefront-prvs: 0597911EE1
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-microsoft-antispam-message-info: nkgzyP6IWx4ha9XHq/yd+5Eh4gPCr9IVfVKeawRYITypDTbNJahTz5qEMsA0zszPM2cVAyaOb6RO/cghQOerYTo667sXd8bNajs94wVHFEN4QrUb+1EvJa+RKcUkvBAJnHWVdvVBW17xjJcI4wrF56c/qqy8lMoOQOniIDGif6A=
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_C062DDC989684B2482896B2625D3193Cjunipernet_"
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b4167a4b-b3dd-4aa1-f6ea-08d57ed6ae32
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Feb 2018 18:11:25.2118 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM5PR05MB3146
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2018-02-28_10:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1802280221
Archived-At: 
Subject: Re: [netmod] AD review of draft-ietf-netmod-syslog-model-20
X-BeenThere: netmod@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: NETMOD WG list 
List-Unsubscribe: , 
List-Archive: 
List-Post: 
List-Help: 
List-Subscribe: , 
X-List-Received-Date: Wed, 28 Feb 2018 18:50:42 -0000

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

WytiZW5vaXRdDQoNCk1haGVzaCwNCg0KVGhhdCdzIGZpbmUsIGlmIHdlIHdhbnQgdG8gcHV0IHRo
ZSBSRkMgRWRpdG9yIG5vdGUgaW50byB0aGUgSW50cm9kdWN0aW9uLCBJIHNlZSB0aGF0IHlvdSBk
aWQgdGhlIHNhbWUgaW4gdGhlIEFDTCBkcmFmdC4gIEJ1dCB0aGVyZSBzdGlsbCByZW1haW5zIHRo
ZSB1c2Ugb2YgSVAgYWRkcmVzc2VzIChub3QgaG9zdG5hbWVzKSBpbiBleGFtcGxlcyBhbmQsIGlm
IHdlJ3JlIGZpeGluZyB0aGF0LCBsZXQncyBwbGVhc2UgYWxzbyBmaXggdGhlIHR5cG8gaW4gdGhl
IHRpdGxlIG9mIFNlY3Rpb24gMS40Lg0KDQpDbHlkZSwgY2FuIHlvdSBwbGVhc2UgcG9zdCBhIHYy
MyB0aGF0IGZpeGVzIHRoZXNlIGxhc3QgdHdvIHBvaW50cz8NCg0KVGhhbmtzLA0KS2VudCAgLy8g
c2hlcGhlcmQNCg0KDQpPbiAyLzIzLzE4LCAxOjA1IFBNLCAiTWFoZXNoIEpldGhhbmFuZGFuaSIg
PG1qZXRoYW5hbmRhbmlAZ21haWwuY29tPG1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbT4+
IHdyb3RlOg0KDQpLZW50LA0KDQoNCk9uIEZlYiAyMywgMjAxOCwgYXQgODowMiBBTSwgS2VudCBX
YXRzZW4gPGt3YXRzZW5AanVuaXBlci5uZXQ8bWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQ+PiB3
cm90ZToNCg0KSGkgQ2x5ZGUsDQoNCkxvb2tpbmcgYXQgeW91ciBkaWZmLCBJIHNlZSB0aGF0IHlv
dSBhbGlnbmVkIHRoZSBVc2FnZSBFeGFtcGxlIHRleHQgYW5kIGFydHdvcmsgYnkgbWFraW5nIHRo
ZSBhcnR3b3JrIHVzZSB0aGUgSVAgYWRkcmVzcyBmcm9tIHRoZSB0ZXh0LCBidXQgeW91IHNob3Vs
ZCd2ZSBpbnN0ZWFkIHVzZWQgdGhlIGhvc3RuYW1lIGluIGJvdGggbG9jYXRpb25zLiAgUGxlYXNl
IHNlZSBzZWN0aW9uIDMuNiBoZXJlOiBodHRwczovL3d3dy5pZXRmLm9yZy9zdGFuZGFyZHMvaWRz
L2NoZWNrbGlzdDxodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0
cHMtM0FfX3d3dy5pZXRmLm9yZ19zdGFuZGFyZHNfaWRzX2NoZWNrbGlzdCZkPUR3TUZBZyZjPUhB
a1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdK
OUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09TjlMSnBDSkJhZkhkVU5kU09lNjNmZTR5
VFl4Sy13bVZ6X0RnSDFjbktqTSZzPUpyUkoySDhQYTk5NTRkTkZXekZRMHhXNGhDWUh4d25yTXRG
VEJWWnl2WkkmZT0+Lg0KDQpBbHNvLCBJIHNlZSB0aGF0IHlvdSBtb3ZlZCB0aGUgRWRpdG9yaWFs
IE5vdGUgdG8gU2VjdGlvbiAxLjQgKGFsb25nIHdpdGggYSB0eXBvIGluIHRoZSB0aXRsZSwgb29v
cHMpLiAgVGhpcyBpcyBmaW5lLCBJIGd1ZXNzLCB0aG91Z2ggSSB3YXMgdGhpbmtpbmcgaW5zdGVh
ZCBhYm91dCBzb21ldGhpbmcgbGlrZSBhIHRvcC1sZXZlbCAiUkZDIEVkaXRvciBDb25zaWRlcmF0
aW9ucyIgbmVhciB0aGUgZW5kIFtobW1tLCBhIGJ1ZGRpbmcgQkNQPyA7KV0uICBBY3R1YWxseSwg
SSB3aXNoIHlvdSBoYWQgZXhwbGFpbmVkIHRoYXQgdGhlIHRleHQgd2FzIG5vdCBpbiB0aGUgQWJz
dHJhY3QsIGJ1dCBpbiBhICI8bm90ZT4iIGVsZW1lbnQsIGFuZCBpdCB3YXMganVzdCBhIHJlbmRl
cmluZyBpc3N1ZS4gIEl0J3MgYWN0dWFsbHkgY29tbW9uIHRvIHVzZSB0aGUgPG5vdGU+IGVsZW1l
bnQgZm9yIHRoaXMgcHVycG9zZSAoc29ycnkgZm9yIG5vdCByZWNvZ25pemluZyBpdCBiZWZvcmUp
LiBQbGVhc2UgYWxzbyBlaXRoZXIgZml4IHRoZSB0eXBvIG9yLCBiZXR0ZXIsIG1vdmUgdGhlIHNl
Y3Rpb24gYmFjayB0byB0aGUgPG5vdGU+IGVsZW1lbnQuDQoNCkkgaGFkIHJlY29tbWVuZGVkIHRo
ZSBtb3ZlIG9mIHRoZSBub3RlIGZyb20gYWJzdHJhY3Qgc2VjdGlvbiB0byB0aGUgZW5kIG9mIHRo
ZSBJbnRyb2R1Y3Rpb24gc2VjdGlvbi4gQWJzdHJhY3RzIGNhbm5vdCBoYXZlIGNyb3NzLXJlZmVy
ZW5jZXMgaW4gdGhlbSwgd2hpY2ggdGhlIG5vdGUgaGFkLiBBbmQgdGhhdCB3YXMgb25lIG9mIHRo
ZSBPUFMtRElSIGNvbW1lbnRzIHRvby4NCg0KDQoNCktlbnQgLy8gc2hlcGhlcmQNCg0KDQo9PT09
PSBvcmlnaW5hbCBtZXNzYWdlID09PT09DQoNCktlbnQsIFRvbSwgWWFyb24sIGFuZCBSb24sDQoN
CkEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LWlldGYtbmV0bW9kLXN5c2xvZy1tb2RlbCBoYXMg
YmVlbiBwdWJsaXNoZWQgdGhhdCBhZGRyZXNzZXMgeW91ciBjb25jZXJucy4NCg0KVGhhbmtzLA0K
DQoNCg0KQ2x5ZGUNCg0KDQoNCk9uIDIvMjAvMTgsIDk6MDYgQU0sICJuZXRtb2Qgb24gYmVoYWxm
IG9mIEtlbnQgV2F0c2VuIiA8bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8bWFpbHRvOm5ldG1vZC1i
b3VuY2VzQGlldGYub3JnPiBvbiBiZWhhbGYgb2Yga3dhdHNlbkBqdW5pcGVyLm5ldDxtYWlsdG86
a3dhdHNlbkBqdW5pcGVyLm5ldD4+IHdyb3RlOg0KDQoNCg0KDQoNCg0KDQoNCg0KDQpLZW50DQoN
Cg0KDQoNCg0KWW91IGlsbHVzdHJhdGUgYmVhdXRpZnVsbHkgdGhlIHByb2JsZW0gSSB3b3VsZCBs
aWtlIGEgc29sdXRpb24gdG8uDQoNCg0KDQoNCg0KVGhlIGN1cnJlbnQgdGhpbmtpbmcgQUZBSUNU
IGlzIHRoYXQgdHJlZS1kaWFncmFtcw0KDQoNCnNob3VsZCBiZSBhbiBJbmZvcm1hdGl2ZSBSZWZl
cmVuY2UuDQoNCg0KDQoNCg0KVGhlcmVmb3JlLCB0aGUgUkZDIEVkaXRvciB3aWxsIG5vdCBob2xk
IHB1YmxpY2F0aW9uIHVudGlsIGFuIFJGQyBudW1iZXINCg0KDQppcyBhc3NpZ25lZC4NCg0KDQoN
Cg0KDQpUaGVyZWZvcmUsIGEgbm90ZSBhc2tpbmcgdGhlIEktRCByZWZlcmVuY2UgdG8gYmUgdXBk
YXRlZCB0byByZWZsZWN0IHRoZQ0KDQoNCmFzc2lnbmVkIFJGQyBudW1iZXIgaXMgbnVsbCAtIHRo
ZSBSRkMgY2FuIGJlIHB1Ymxpc2hlZCB3aXRoIHRoZQ0KDQoNCnJlZmVyZW5jZSBhcyBhbiBpLWQg
YW5kIG5vdCBhcyBhbiBSRkMgd2hpY2ggaXMgd2hhdCBJIGV4cGVjdCB0aGUgUkZDDQoNCg0KRWRp
dG9yIHRvIGRvLg0KDQoNCg0KDQoNClFFRA0KDQoNCg0KDQoNCiAgIEV4Y2VwdCBJIGtub3cgdGhh
dCB0aGlzIGRyYWZ0IHdpbGwgYmUgc3R1Y2sgaW4gTUlTUkVGIHN0YXRlIGFuZCB0cmVlLWRpYWdy
YW1zDQoNCiAgIHdpbGwgaW4gZmFjdCBiZSBhc3NpZ25lZCBhbiBSRkMgbnVtYmVyIGJ5IHRoZSB0
aW1lIHRoaXMgZHJhZnQgaXMgcHVibGlzaGVkLg0KDQoNCg0KICAgSy4NCg0KDQoNCg0KDQoNCk5v
dGUgdGhhdCB0aGlzIGlzIG5vdCB0aGUgY2FzZSBvZiBhIE5vcm1hdGl2ZSBpLWQgcmVmZXJlbmNl
IGJlaW5nIGJ1cmllZA0KDQoNCmluIHRoZSBZQU5HIG1vZHVsZSBhbmQgbm90IGJlaW5nLm5vdGlj
ZWQgYnkgdGhlIFJGQyBFZGl0b3I7IHRoYXQgcHJvYmxlbQ0KDQoNCkkgYW0gY29udGVudCB3aXRo
Lg0KDQoNCg0KDQoNCg0KDQoNClRvbSBQZXRjaA0KDQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQoN
Cg0KDQoNCg0KDQoNCg0KUGxlYXNlIGFsc28gYWRkcmVzcyB0aGVzZSBpc3N1ZXMgd2hlbiBwb3N0
aW5nIC0yMSB0byBhZGRyZXNzIEJlbm9pdCdzDQoNCiAgIGlzc3Vlcy4gIFBsZWFzZSBwb3N0IC0y
MSBBU0FQIGFzIEJlbm9pdCBoYXMgYWxyZWFkeSBwbGFjZWQgdGhpcyBkcmFmdCBvbg0KDQogICB0
aGUgSUVTRyB0ZWxlY2hhdCBpbiBhIGNvdXBsZSB3ZWVrcy4NCg0KDQoNCg0KDQpUaGFua3MsDQoN
Cg0KS2VudCAvLyBzaGVwaGVyZA0KDQoNCg0KDQoNCg0KDQoNCk9uIDIvMTQvMTgsIDg6MTggQU0s
ICJuZXRtb2Qgb24gYmVoYWxmIG9mIEJlbm9pdCBDbGFpc2UiDQoNCiAgIDxuZXRtb2QtYm91bmNl
c0BpZXRmLm9yZzxtYWlsdG86bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc+PG1haWx0bzpuZXRtb2Qt
Ym91bmNlc0BpZXRmLm9yZz4gb24gYmVoYWxmIG9mDQoNCiAgIGJjbGFpc2VAY2lzY28uY29tPG1h
aWx0bzpiY2xhaXNlQGNpc2NvLmNvbT48bWFpbHRvOmJjbGFpc2VAY2lzY28uY29tPj4gd3JvdGU6
DQoNCg0KDQoNCg0KRGVhciBhbGwsDQoNCg0KDQoNCg0KLSB0aGUgZHJhZnQgaXMgTk1EQSBjb21w
bGlhbnQsIHJpZ2h0PyBJdCBzaG91bGQgYmUgbWVudGlvbmVkLg0KDQoNCkV4OiBkcmFmdC1pZXRm
LW5ldG1vZC1yZmM3MjIzYmlzLTAzLCBpbiB0aGUgYWJzdHJhY3QgYW5kIGludHJvDQoNCg0KDQoN
Cg0KICBUaGUgWUFORyBtb2RlbCBpbiB0aGlzIGRvY3VtZW50IGNvbmZvcm1zIHRvIHRoZSBOZXR3
b3JrIE1hbmFnZW1lbnQNCg0KDQoNCg0KDQogIERhdGFzdG9yZSBBcmNoaXRlY3R1cmUgZGVmaW5l
ZCBpbg0KDQogICBJLUQuaWV0Zi1uZXRtb2QtcmV2aXNlZC1kYXRhc3RvcmVzLg0KDQoNCg0KDQoN
Cg0KDQoNCi0gQXMgbWVudGlvbmVkIGluIHRoZSB3cml0ZXVwLCBbSS1ELmlldGYtbmV0bW9kLXlh
bmctdHJlZS1kaWFncmFtc10NCg0KICAgc2hvdWxkIGJlIGFuIGluZm9ybWF0aXZlIHJlZmVyZW5j
ZSwgbm90IG5vcm1hdGl2ZS4NCg0KDQoNCg0KDQotIEVkaXRvcmlhbDoNCg0KDQpPTEQ6DQoNCg0K
VGhpcyBkcmFmdCBhZGRyZXNzZXMgdGhlIGNvbW1vbiBsZWFmcw0KDQoNCk5FVzoNCg0KDQpUaGlz
IGRvY3VtZW50IGFkZHJlc3NlcyB0aGUgY29tbW9uIGxlYWZzDQoNCg0KDQoNCg0KUGxlYXNlIHB1
Ymxpc2ggYSBuZXcgdmVyc2lvbiBhc2FwLg0KDQoNCkluIHRoZSBtZWFuIHRpbWUsIEknbSBzZW5k
aW5nIHRoaXMgZHJhZnQgdG8gSUVURiBMQy4NCg0KDQoNCg0KDQpSZWdhcmRzLCBCZW5vaXQNCg0K
DQoNCg0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICAtLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KICAgLS0tLS0t
LS0NCg0KDQoNCg0KDQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fDQoNCg0KbmV0bW9kIG1haWxpbmcgbGlzdA0KDQoNCm5ldG1vZEBpZXRmLm9yZzxtYWls
dG86bmV0bW9kQGlldGYub3JnPg0KDQoNCmh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNv
bS92Mi91cmw/dT1odHRwcy0zQV9fd3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9k
JmQ9RHdJQ2FRJmM9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZy
PTl6a1AweG5KVXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mbT1jSjdNVm5RVmMx
aGd4cFZGN29ZaVZuNlJibS1RZjJkRHlyZlloTC1zOWlvJnM9dTBIbjlHa08tQjBqVUdtMU1uSVE0
eDRBZ0laTlhIQklhWmhUUG10M2RDOCZlPQ0KDQoNCg0KDQoNCg0KDQoNCg0KDQogICBfX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0KDQogICBuZXRtb2QgbWFp
bGluZyBsaXN0DQoNCiAgIG5ldG1vZEBpZXRmLm9yZzxtYWlsdG86bmV0bW9kQGlldGYub3JnPg0K
DQogICBodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff
X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZkPUR3SUdhUSZjPUhBa1l1aDYz
cnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIzdm9EVFhjV3pvQ0kmcj05emtQMHhuSlV2WkdKOUVQb09I
N1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJm09dkVMc21lT1FFSE5tNGZjeUpKS0c3RXB3d3pNQkdj
LU1IdkhoU1BXUnpybyZzPWpTR3dQMTZYbE02bnRNS1VGM2JrQ0F3UmZSdFJ3QVRkbHkyQmxVdHgy
UkEmZT0NCg0KDQoNCg0KDQoNCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX18NCm5ldG1vZCBtYWlsaW5nIGxpc3QNCm5ldG1vZEBpZXRmLm9yZzxtYWlsdG86
bmV0bW9kQGlldGYub3JnPg0KaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9u
ZXRtb2Q8aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNB
X193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19uZXRtb2QmZD1Ed01GQWcmYz1IQWtZdWg2
M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJnI9OXprUDB4bkpVdlpHSjlFUG9P
SDdZaHFuMmdzQllhR1R2aklTbGFKZGNabyZtPU45TEpwQ0pCYWZIZFVOZFNPZTYzZmU0eVRZeEst
d21Wel9EZ0gxY25Lak0mcz1Vak9FdEpjRjAwYUp6WnM1aHJxYUlxV0hlYk8xMXVnRWVNY0VTcmNt
WDMwJmU9Pg0KDQpNYWhlc2ggSmV0aGFuYW5kYW5pDQptamV0aGFuYW5kYW5pQGdtYWlsLmNvbTxt
YWlsdG86bWpldGhhbmFuZGFuaUBnbWFpbC5jb20+DQoNCg0K

--_000_C062DDC989684B2482896B2625D3193Cjunipernet_
Content-Type: text/html; charset="utf-8"
Content-ID: <7718063EA1A28B43A51202CA1B57B958@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
DQpzcGFuLmFwcGxlLWNvbnZlcnRlZC1zcGFjZQ0KCXttc28tc3R5bGUtbmFtZTphcHBsZS1jb252
ZXJ0ZWQtc3BhY2U7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u
YWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6Q2FsaWJyaTsNCglmb250LXZhcmlhbnQ6bm9ybWFsICFp
bXBvcnRhbnQ7DQoJY29sb3I6d2luZG93dGV4dDsNCgl0ZXh0LXRyYW5zZm9ybTpub25lOw0KCXRl
eHQtZGVjb3JhdGlvbjpub25lIG5vbmU7DQoJdmVydGljYWwtYWxpZ246YmFzZWxpbmU7fQ0Kc3Bh
bi5tc29JbnMNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJbXNvLXN0eWxlLW5hbWU6
IiI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTsNCgljb2xvcjp0ZWFsO30NCi5Nc29DaHBE
ZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9ydC1vbmx5Ow0KCWZvbnQtc2l6ZToxMC4wcHQ7
fQ0KQHBhZ2UgV29yZFNlY3Rpb24xDQoJe3NpemU6OC41aW4gMTEuMGluOw0KCW1hcmdpbjoxLjBp
biAxLjBpbiAxLjBpbiAxLjBpbjt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6V29yZFNlY3Rp
b24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBiZ2NvbG9yPSJ3aGl0ZSIgbGFuZz0i
RU4tVVMiIGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rp
b24xIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxp
YnJpIj5bJiM0MztiZW5vaXRdPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpIj5NYWhlc2gsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpIj5UaGF0J3MgZmluZSwgaWYgd2Ugd2FudCB0byBwdXQgdGhlIFJGQyBFZGl0b3Ig
bm90ZSBpbnRvIHRoZSBJbnRyb2R1Y3Rpb24sIEkgc2VlIHRoYXQgeW91IGRpZCB0aGUgc2FtZSBp
biB0aGUgQUNMIGRyYWZ0LiZuYnNwOyBCdXQgdGhlcmUgc3RpbGwgcmVtYWlucyB0aGUgdXNlIG9m
IElQIGFkZHJlc3NlcyAobm90IGhvc3RuYW1lcykgaW4gZXhhbXBsZXMgYW5kLA0KIGlmIHdlJ3Jl
IGZpeGluZyB0aGF0LCBsZXQncyBwbGVhc2UgYWxzbyBmaXggdGhlIHR5cG8gaW4gdGhlIHRpdGxl
IG9mIFNlY3Rpb24gMS40LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTpDYWxpYnJpIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6
Q2FsaWJyaSI+Q2x5ZGUsIGNhbiB5b3UgcGxlYXNlIHBvc3QgYSB2MjMgdGhhdCBmaXhlcyB0aGVz
ZSBsYXN0IHR3byBwb2ludHM/PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LWZhbWls
eTpDYWxpYnJpIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPktlbnQmbmJzcDsgLy8gc2hl
cGhlcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OkNhbGlicmkiPjxv
OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+T24gMi8yMy8xOCwgMTowNSBQTSwgJnF1b3Q7TWFoZXNoIEpldGhhbmFuZGFuaSZxdW90
OyAmbHQ7PGEgaHJlZj0ibWFpbHRvOm1qZXRoYW5hbmRhbmlAZ21haWwuY29tIj5tamV0aGFuYW5k
YW5pQGdtYWlsLmNvbTwvYT4mZ3Q7IHdyb3RlOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rp
dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwv
ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+S2VudCw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPGRpdj4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIEZlYiAyMywgMjAxOCwgYXQgODowMiBBTSwgS2VudCBX
YXRzZW4gJmx0OzxhIGhyZWY9Im1haWx0bzprd2F0c2VuQGp1bmlwZXIubmV0Ij5rd2F0c2VuQGp1
bmlwZXIubmV0PC9hPiZndDsgd3JvdGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh
Ij5IaSBDbHlkZSw8YnI+DQo8YnI+DQpMb29raW5nIGF0IHlvdXIgZGlmZiwgSSBzZWUgdGhhdCB5
b3UgYWxpZ25lZCB0aGUgVXNhZ2UgRXhhbXBsZSB0ZXh0IGFuZCBhcnR3b3JrIGJ5IG1ha2luZyB0
aGUgYXJ0d29yayB1c2UgdGhlIElQIGFkZHJlc3MgZnJvbSB0aGUgdGV4dCwgYnV0IHlvdSBzaG91
bGQndmUgaW5zdGVhZCB1c2VkIHRoZSBob3N0bmFtZSBpbiBib3RoIGxvY2F0aW9ucy4gJm5ic3A7
UGxlYXNlIHNlZSBzZWN0aW9uIDMuNiBoZXJlOjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQt
c3BhY2UiPiZuYnNwOzwvc3Bhbj48L3NwYW4+PGEgaHJlZj0iaHR0cHM6Ly91cmxkZWZlbnNlLnBy
b29mcG9pbnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfc3RhbmRhcmRzX2lk
c19jaGVja2xpc3QmYW1wO2Q9RHdNRkFnJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVN
Sy1uZGIzdm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2
aklTbGFKZGNabyZhbXA7bT1OOUxKcENKQmFmSGRVTmRTT2U2M2ZlNHlUWXhLLXdtVnpfRGdIMWNu
S2pNJmFtcDtzPUpyUkoySDhQYTk5NTRkTkZXekZRMHhXNGhDWUh4d25yTXRGVEJWWnl2WkkmYW1w
O2U9Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+
aHR0cHM6Ly93d3cuaWV0Zi5vcmcvc3RhbmRhcmRzL2lkcy9jaGVja2xpc3Q8L3NwYW4+PC9hPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4uPGJyPg0K
PGJyPg0KQWxzbywgSSBzZWUgdGhhdCB5b3UgbW92ZWQgdGhlIEVkaXRvcmlhbCBOb3RlIHRvIFNl
Y3Rpb24gMS40IChhbG9uZyB3aXRoIGEgdHlwbyBpbiB0aGUgdGl0bGUsIG9vb3BzKS4gJm5ic3A7
VGhpcyBpcyBmaW5lLCBJIGd1ZXNzLCB0aG91Z2ggSSB3YXMgdGhpbmtpbmcgaW5zdGVhZCBhYm91
dCBzb21ldGhpbmcgbGlrZSBhIHRvcC1sZXZlbCAmcXVvdDtSRkMgRWRpdG9yIENvbnNpZGVyYXRp
b25zJnF1b3Q7IG5lYXIgdGhlIGVuZCBbaG1tbSwgYSBidWRkaW5nIEJDUD8gOyldLg0KICZuYnNw
O0FjdHVhbGx5LCBJIHdpc2ggeW91IGhhZCBleHBsYWluZWQgdGhhdCB0aGUgdGV4dCB3YXMgbm90
IGluIHRoZSBBYnN0cmFjdCwgYnV0IGluIGEgJnF1b3Q7Jmx0O25vdGUmZ3Q7JnF1b3Q7IGVsZW1l
bnQsIGFuZCBpdCB3YXMganVzdCBhIHJlbmRlcmluZyBpc3N1ZS4gJm5ic3A7SXQncyBhY3R1YWxs
eSBjb21tb24gdG8gdXNlIHRoZSAmbHQ7bm90ZSZndDsgZWxlbWVudCBmb3IgdGhpcyBwdXJwb3Nl
IChzb3JyeSBmb3Igbm90IHJlY29nbml6aW5nIGl0IGJlZm9yZSkuIFBsZWFzZSBhbHNvIGVpdGhl
cg0KIGZpeCB0aGUgdHlwbyBvciwgYmV0dGVyLCBtb3ZlIHRoZSBzZWN0aW9uIGJhY2sgdG8gdGhl
ICZsdDtub3RlJmd0OyBlbGVtZW50Ljwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9i
bG9ja3F1b3RlPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5JIGhhZCByZWNvbW1lbmRlZCB0aGUg
bW92ZSBvZiB0aGUgbm90ZSBmcm9tIGFic3RyYWN0IHNlY3Rpb24gdG8gdGhlIGVuZCBvZiB0aGUg
SW50cm9kdWN0aW9uIHNlY3Rpb24uIEFic3RyYWN0cyBjYW5ub3QgaGF2ZSBjcm9zcy1yZWZlcmVu
Y2VzIGluIHRoZW0sIHdoaWNoIHRoZSBub3RlIGhhZC4gQW5kIHRoYXQgd2FzIG9uZSBvZiB0aGUg
T1BTLURJUiBjb21tZW50cyB0b28uPGJyPg0KPGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8
YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4N
CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyPg0KS2VudCAvLyBzaGVwaGVyZDxicj4NCjxicj4N
Cjxicj4NCj09PT09IG9yaWdpbmFsIG1lc3NhZ2UgPT09PT08YnI+DQo8YnI+DQpLZW50LCBUb20s
IFlhcm9uLCBhbmQgUm9uLDxicj4NCjxicj4NCkEgbmV3IHZlcnNpb24gb2YgdGhlIGRyYWZ0LWll
dGYtbmV0bW9kLXN5c2xvZy1tb2RlbCBoYXMgYmVlbiBwdWJsaXNoZWQgdGhhdCBhZGRyZXNzZXMg
eW91ciBjb25jZXJucy48YnI+DQo8YnI+DQpUaGFua3MsPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K
Q2x5ZGU8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpPbiAyLzIwLzE4LCA5OjA2IEFNLCAmcXVvdDtu
ZXRtb2Qgb24gYmVoYWxmIG9mIEtlbnQgV2F0c2VuJnF1b3Q7ICZsdDs8L3NwYW4+PGEgaHJlZj0i
bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+bmV0bW9kLWJvdW5jZXNAaWV0Zi5vcmc8L3NwYW4+
PC9hPjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj4mbmJzcDs8L3NwYW4+PC9zcGFuPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5vbg0KIGJl
aGFsZiBvZjxzcGFuIGNsYXNzPSJhcHBsZS1jb252ZXJ0ZWQtc3BhY2UiPiZuYnNwOzwvc3Bhbj48
L3NwYW4+PGEgaHJlZj0ibWFpbHRvOmt3YXRzZW5AanVuaXBlci5uZXQiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5rd2F0c2VuQGp1bmlwZXIubmV0
PC9zcGFuPjwvYT48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl
dGljYSI+Jmd0OyB3cm90ZTo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+
DQo8YnI+DQo8YnI+DQo8YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1h
bGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBw
eCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFy
Z2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5LZW50
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxi
ciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9z
cGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxl
PSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5bGU9ImZvbnQt
dmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5Zb3UgaWxsdXN0cmF0ZSBiZWF1dGlmdWxseSB0aGUgcHJv
YmxlbSBJIHdvdWxkIGxpa2UgYSBzb2x1dGlvbiB0by48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8
L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXpl
OjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fw
czogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4
O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2Nr
cXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0K
PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZh
bWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0
LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6
MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJt
YXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRo
ZSBjdXJyZW50IHRoaW5raW5nIEFGQUlDVCBpcyB0aGF0IHRyZWUtZGlhZ3JhbXM8bzpwPjwvbzpw
Pjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJm
b250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0
cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9v
OnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRv
bTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+c2hvdWxkIGJlIGFuIEluZm9ybWF0aXZlIFJlZmVy
ZW5jZS48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj
YSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0K
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286
cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0i
Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoZXJlZm9yZSwgdGhlIFJGQyBFZGl0b3Igd2ls
bCBub3QgaG9sZCBwdWJsaWNhdGlvbiB1bnRpbCBhbiBSRkMgbnVtYmVyPG86cD48L286cD48L3Nw
YW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12
YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Ut
d2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwv
cD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4w
cHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTpIZWx2ZXRpY2EiPmlzIGFzc2lnbmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4N
CjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1j
YXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAw
cHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8Ymxv
Y2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxw
IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1p
bHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3Rl
eHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2lu
ZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9
Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9y
bWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+
VGhlcmVmb3JlLCBhIG5vdGUgYXNraW5nIHRoZSBJLUQgcmVmZXJlbmNlIHRvIGJlIHVwZGF0ZWQg
dG8gcmVmbGVjdCB0aGU8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBj
bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5
OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxp
Z246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgi
Pg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+YXNzaWdu
ZWQgUkZDIG51bWJlciBpcyBudWxsIC0gdGhlIFJGQyBjYW4gYmUgcHVibGlzaGVkIHdpdGggdGhl
PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1h
bCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxi
ciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJr
aXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bh
bj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21h
cmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPnJlZmVyZW5jZSBhcyBhbiBpLWQg
YW5kIG5vdCBhcyBhbiBSRkMgd2hpY2ggaXMgd2hhdCBJIGV4cGVjdCB0aGUgUkZDPG86cD48L286
cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0i
Zm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1z
dHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwv
bzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0
b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkVkaXRvciB0byBkby48bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZh
cmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5v
cm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3Jk
LXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2
ZXRpY2EiPlFFRDxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVs
dmV0aWNhIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQombmJzcDsmbmJzcDsmbmJzcDtF
eGNlcHQgSSBrbm93IHRoYXQgdGhpcyBkcmFmdCB3aWxsIGJlIHN0dWNrIGluIE1JU1JFRiBzdGF0
ZSBhbmQgdHJlZS1kaWFncmFtczxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO3dpbGwgaW4g
ZmFjdCBiZSBhc3NpZ25lZCBhbiBSRkMgbnVtYmVyIGJ5IHRoZSB0aW1lIHRoaXMgZHJhZnQgaXMg
cHVibGlzaGVkLjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwO0suPGJy
Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczog
bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dv
cmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Okhl
bHZldGljYSI+Tm90ZSB0aGF0IHRoaXMgaXMgbm90IHRoZSBjYXNlIG9mIGEgTm9ybWF0aXZlIGkt
ZCByZWZlcmVuY2UgYmVpbmcgYnVyaWVkPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1
b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtm
b250LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1h
bDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNw
YWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0
eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRp
Y2EiPmluIHRoZSBZQU5HIG1vZHVsZSBhbmQgbm90IGJlaW5nLm5vdGljZWQgYnkgdGhlIFJGQyBF
ZGl0b3I7IHRoYXQgcHJvYmxlbTxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4N
CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1m
YW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4
dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5n
OjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0i
bWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5J
IGFtIGNvbnRlbnQgd2l0aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8
cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFt
aWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQt
YWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow
cHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2Ei
PjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+
PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0
eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5bGU9ImZv
bnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ry
b2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286
cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9t
OjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4w
cHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5Ub20gUGV0Y2g8bzpwPjwvbzpwPjwvc3Bhbj48L3A+
DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1z
aXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0K
PGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJy
Pg0KPGJyPg0KPGJyPg0KPGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQt
YWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzow
cHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1h
cmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFs
Ij48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86
cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2Ei
PjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13
ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwv
c3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0
O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9
ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlBsZWFzZSBhbHNvIGFkZHJl
c3MgdGhlc2UgaXNzdWVzIHdoZW4gcG9zdGluZyAtMjEgdG8gYWRkcmVzcyBCZW5vaXQnczxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnI+DQom
bmJzcDsmbmJzcDsmbmJzcDtpc3N1ZXMuICZuYnNwO1BsZWFzZSBwb3N0IC0yMSBBU0FQIGFzIEJl
bm9pdCBoYXMgYWxyZWFkeSBwbGFjZWQgdGhpcyBkcmFmdCBvbjxicj4NCjxicj4NCiZuYnNwOyZu
YnNwOyZuYnNwO3RoZSBJRVNHIHRlbGVjaGF0IGluIGEgY291cGxlIHdlZWtzLjxicj4NCjxiciBz
dHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQt
dGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48
bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdp
bi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQt
c2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu
PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5bGU9ImZvbnQtdmFy
aWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhIj5UaGFua3MsPG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9j
a3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5v
cm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3Jk
LXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3Rl
IHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2
ZXRpY2EiPktlbnQgLy8gc2hlcGhlcmQ8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVv
dGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFs
O3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3Bh
Y2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5
bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj
YSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9
Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2
ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0
YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxi
cj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9w
OjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7
PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5
bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86
cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5PbiAyLzE0LzE4LCA4OjE4IEFNLCAmcXVv
dDtuZXRtb2Qgb24gYmVoYWxmIG9mIEJlbm9pdCBDbGFpc2UmcXVvdDs8bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyPg0KJm5ic3A7Jm5ic3A7
Jm5ic3A7Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0BpZXRmLm9yZyI+bmV0bW9k
LWJvdW5jZXNAaWV0Zi5vcmc8L2E+Jmx0OzxhIGhyZWY9Im1haWx0bzpuZXRtb2QtYm91bmNlc0Bp
ZXRmLm9yZyI+bWFpbHRvOm5ldG1vZC1ib3VuY2VzQGlldGYub3JnPC9hPiZndDsgb24gYmVoYWxm
IG9mPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7PGEgaHJlZj0ibWFpbHRvOmJjbGFpc2VA
Y2lzY28uY29tIj5iY2xhaXNlQGNpc2NvLmNvbTwvYT4mbHQ7PGEgaHJlZj0ibWFpbHRvOmJjbGFp
c2VAY2lzY28uY29tIj5tYWlsdG86YmNsYWlzZUBjaXNjby5jb208L2E+Jmd0OyZndDsgd3JvdGU6
PGJyPg0KPGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3Rh
cnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJy
Pg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6
NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBz
dHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8
L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHls
ZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4
dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpw
PjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1i
b3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6
ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPkRlYXIgYWxsLDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5bGU9ImZvbnQtdmFy
aWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt
c3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl
dGljYSI+LSB0aGUgZHJhZnQgaXMgTk1EQSBjb21wbGlhbnQsIHJpZ2h0PyBJdCBzaG91bGQgYmUg
bWVudGlvbmVkLjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNz
PSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVs
dmV0aWNhIj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpz
dGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8
YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRv
cDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu
IHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5FeDogZHJhZnQt
aWV0Zi1uZXRtb2QtcmZjNzIyM2Jpcy0wMywgaW4gdGhlIGFic3RyYWN0IGFuZCBpbnRybzxvOnA+
PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxz
cGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5
bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRl
eHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86
cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4t
Ym90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48
L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9u
dC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlh
bnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0
aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0K
PGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OkhlbHZldGljYSI+Jm5ic3A7Jm5ic3A7VGhlIFlBTkcgbW9kZWwgaW4gdGhpcyBkb2N1
bWVudCBjb25mb3JtcyB0byB0aGUgTmV0d29yayBNYW5hZ2VtZW50PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx
dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3Jt
YWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1z
cGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0
aWNhIj4mbmJzcDsmbmJzcDtEYXRhc3RvcmUgQXJjaGl0ZWN0dXJlIGRlZmluZWQgaW48bzpwPjwv
bzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyPg0KJm5i
c3A7Jm5ic3A7Jm5ic3A7SS1ELmlldGYtbmV0bW9kLXJldmlzZWQtZGF0YXN0b3Jlcy48YnI+DQo8
YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250
LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9i
bG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5
LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6
IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3
b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1
b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2EiPi0gQXMgbWVudGlvbmVkIGluIHRoZSB3cml0ZXVwLCBbSS1ELmlldGYtbmV0bW9k
LXlhbmctdHJlZS1kaWFncmFtc108bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+
DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQt
ZmFtaWx5OkhlbHZldGljYSI+PGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7c2hvdWxkIGJlIGFuIGlu
Zm9ybWF0aXZlIHJlZmVyZW5jZSwgbm90IG5vcm1hdGl2ZS48YnI+DQo8YnIgc3R5bGU9ImZvbnQt
dmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tl
LXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48
L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUu
MHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Js
b2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjku
MHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczog
bm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dv
cmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVv
dGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Okhl
bHZldGljYSI+LSBFZGl0b3JpYWw6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3Rl
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0
ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNp
bmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxl
PSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05v
cm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2Ei
Pk9MRDo8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNv
Tm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGlj
YSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7
LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0K
PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4w
cHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+VGhpcyBkcmFmdCBhZGRy
ZXNzZXMgdGhlIGNvbW1vbiBsZWFmczxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90
ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7
dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFj
aW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHls
ZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29O
b3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNh
Ij5ORVc6PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRp
Y2EiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0
Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4N
Cjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUu
MHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5
bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlRoaXMgZG9jdW1lbnQg
YWRkcmVzc2VzIHRoZSBjb21tb24gbGVhZnM8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt
c3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl
dGljYSI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xh
c3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpI
ZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWdu
OnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4N
Cjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4t
dG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNw
YW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPlBsZWFzZSBw
dWJsaXNoIGEgbmV3IHZlcnNpb24gYXNhcC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2Nr
cXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9y
bWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQt
c3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg
c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0i
TXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZl
dGljYSI+SW4gdGhlIG1lYW4gdGltZSwgSSdtIHNlbmRpbmcgdGhpcyBkcmFmdCB0byBJRVRGIExD
LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48
YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250
LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9r
ZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+
PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1
LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0
O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+UmVnYXJkcywgQmVub2l0PG86cD48L286cD48L3NwYW4+
PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZv
bnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJp
YW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFsaWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lk
dGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4N
CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi
Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250
LWZhbWlseTpIZWx2ZXRpY2EiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2tx
dW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7
Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3Jt
YWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1z
cGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBz
dHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJN
c29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0
aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFz
cz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5Okhl
bHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246
c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0K
PGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10
b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3Bh
biBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PG86cD4mbmJz
cDs8L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxicj4N
Cjxicj4NCjxicj4NCjxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOy0tLS0tLS0tLS0tLS0t
LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t
LTxicj4NCjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOy0tLS0tLS0tPGJyPg0KPGJyPg0KPGJyPg0K
PGJyPg0KPGJyPg0KPGJyIHN0eWxlPSJmb250LXZhcmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxp
Z246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgi
Pg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdp
bi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48
c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+X19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188bzpwPjwvbzpwPjwvc3Bh
bj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0i
Zm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyIHN0eWxlPSJmb250LXZh
cmlhbnQtY2Fwczogbm9ybWFsO3RleHQtYWxpZ246c3RhcnQ7LXdlYmtpdC10ZXh0LXN0cm9rZS13
aWR0aDogMHB4O3dvcmQtc3BhY2luZzowcHgiPg0KPGJyPg0KPC9zcGFuPjxvOnA+PC9vOnA+PC9w
Pg0KPGJsb2NrcXVvdGUgc3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBw
dCI+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjkuMHB0O2Zv
bnQtZmFtaWx5OkhlbHZldGljYSI+bmV0bW9kIG1haWxpbmcgbGlzdDxvOnA+PC9vOnA+PC9zcGFu
PjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnIgc3R5bGU9ImZvbnQtdmFy
aWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Via2l0LXRleHQtc3Ryb2tlLXdp
ZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3NwYW4+PG86cD48L286cD48L3A+
DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDttYXJnaW4tYm90dG9tOjUuMHB0
Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9u
dC1mYW1pbHk6SGVsdmV0aWNhIj48YSBocmVmPSJtYWlsdG86bmV0bW9kQGlldGYub3JnIj5uZXRt
b2RAaWV0Zi5vcmc8L2E+PG86cD48L286cD48L3NwYW4+PC9wPg0KPC9ibG9ja3F1b3RlPg0KPHAg
Y2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWls
eTpIZWx2ZXRpY2EiPjxiciBzdHlsZT0iZm9udC12YXJpYW50LWNhcHM6IG5vcm1hbDt0ZXh0LWFs
aWduOnN0YXJ0Oy13ZWJraXQtdGV4dC1zdHJva2Utd2lkdGg6IDBweDt3b3JkLXNwYWNpbmc6MHB4
Ij4NCjxicj4NCjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJn
aW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+
PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxhIGhy
ZWY9Imh0dHBzOi8vdXJsZGVmZW5zZS5wcm9vZnBvaW50LmNvbS92Mi91cmw/dT1odHRwcy0zQV9f
d3d3LmlldGYub3JnX21haWxtYW5fbGlzdGluZm9fbmV0bW9kJmFtcDtkPUR3SUNhUSZhbXA7Yz1I
QWtZdWg2M3JzdWhyNlNjYmZoMFVqQlhlTUstbmRiM3ZvRFRYY1d6b0NJJmFtcDtyPTl6a1AweG5K
VXZaR0o5RVBvT0g3WWhxbjJnc0JZYUdUdmpJU2xhSmRjWm8mYW1wO209Y0o3TVZuUVZjMWhneHBW
RjdvWWlWbjZSYm0tUWYyZER5cmZZaEwtczlpbyZhbXA7cz11MEhuOUdrTy1CMGpVR20xTW5JUTR4
NEFnSVpOWEhCSWFaaFRQbXQzZEM4JmFtcDtlPSI+aHR0cHM6Ly91cmxkZWZlbnNlLnByb29mcG9p
bnQuY29tL3YyL3VybD91PWh0dHBzLTNBX193d3cuaWV0Zi5vcmdfbWFpbG1hbl9saXN0aW5mb19u
ZXRtb2QmYW1wO2Q9RHdJQ2FRJmFtcDtjPUhBa1l1aDYzcnN1aHI2U2NiZmgwVWpCWGVNSy1uZGIz
dm9EVFhjV3pvQ0kmYW1wO3I9OXprUDB4bkpVdlpHSjlFUG9PSDdZaHFuMmdzQllhR1R2aklTbGFK
ZGNabyZhbXA7bT1jSjdNVm5RVmMxaGd4cFZGN29ZaVZuNlJibS1RZjJkRHlyZlloTC1zOWlvJmFt
cDtzPXUwSG45R2tPLUIwalVHbTFNbklRNHg0QWdJWk5YSEJJYVpoVFBtdDNkQzgmYW1wO2U9PC9h
PjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvYmxvY2txdW90ZT4NCjxwIGNsYXNzPSJNc29Ob3Jt
YWwiPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48
YnIgc3R5bGU9ImZvbnQtdmFyaWFudC1jYXBzOiBub3JtYWw7dGV4dC1hbGlnbjpzdGFydDstd2Vi
a2l0LXRleHQtc3Ryb2tlLXdpZHRoOiAwcHg7d29yZC1zcGFjaW5nOjBweCI+DQo8YnI+DQo8L3Nw
YW4+PG86cD48L286cD48L3A+DQo8YmxvY2txdW90ZSBzdHlsZT0ibWFyZ2luLXRvcDo1LjBwdDtt
YXJnaW4tYm90dG9tOjUuMHB0Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm
b250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48bzpwPiZuYnNwOzwvbzpwPjwv
c3Bhbj48L3A+DQo8L2Jsb2NrcXVvdGU+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHls
ZT0iZm9udC1zaXplOjkuMHB0O2ZvbnQtZmFtaWx5OkhlbHZldGljYSI+PGJyPg0KPGJyPg0KPGJy
Pg0KPGJyPg0KPGJyPg0KPGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7X19fX19fX19fX19f
X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX188YnI+DQo8YnI+DQombmJzcDsmbmJz
cDsmbmJzcDtuZXRtb2QgbWFpbGluZyBsaXN0PGJyPg0KPGJyPg0KJm5ic3A7Jm5ic3A7Jm5ic3A7
PGEgaHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+bmV0bW9kQGlldGYub3JnPC9hPjxicj4N
Cjxicj4NCiZuYnNwOyZuYnNwOyZuYnNwOzwvc3Bhbj48YSBocmVmPSJodHRwczovL3VybGRlZmVu
c2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFu
X2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1Ed0lHYVEmYW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBV
akJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NC
WWFHVHZqSVNsYUpkY1pvJmFtcDttPXZFTHNtZU9RRUhObTRmY3lKSktHN0Vwd3d6TUJHYy1NSHZI
aFNQV1J6cm8mYW1wO3M9alNHd1AxNlhsTTZudE1LVUYzYmtDQXdSZlJ0UndBVGRseTJCbFV0eDJS
QSZhbXA7ZT0iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0
aWNhIj5odHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0cHMtM0Ff
X3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1Ed0lHYVEmYW1wO2M9
SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05emtQMHhu
SlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPXZFTHNtZU9RRUhObTRm
Y3lKSktHN0Vwd3d6TUJHYy1NSHZIaFNQV1J6cm8mYW1wO3M9alNHd1AxNlhsTTZudE1LVUYzYmtD
QXdSZlJ0UndBVGRseTJCbFV0eDJSQSZhbXA7ZT08L3NwYW4+PC9hPjxzcGFuIHN0eWxlPSJmb250
LXNpemU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj48YnI+DQo8YnI+DQo8YnI+DQo8YnI+
DQo8YnI+DQo8YnI+DQo8YnI+DQo8YnI+DQpfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f
X19fX19fX19fX19fX19fXzxicj4NCm5ldG1vZCBtYWlsaW5nIGxpc3Q8YnI+DQo8L3NwYW4+PGEg
aHJlZj0ibWFpbHRvOm5ldG1vZEBpZXRmLm9yZyI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZTo5LjBw
dDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPm5ldG1vZEBpZXRmLm9yZzwvc3Bhbj48L2E+PHNwYW4g
c3R5bGU9ImZvbnQtc2l6ZTo5LjBwdDtmb250LWZhbWlseTpIZWx2ZXRpY2EiPjxicj4NCjwvc3Bh
bj48YSBocmVmPSJodHRwczovL3VybGRlZmVuc2UucHJvb2Zwb2ludC5jb20vdjIvdXJsP3U9aHR0
cHMtM0FfX3d3dy5pZXRmLm9yZ19tYWlsbWFuX2xpc3RpbmZvX25ldG1vZCZhbXA7ZD1Ed01GQWcm
YW1wO2M9SEFrWXVoNjNyc3VocjZTY2JmaDBVakJYZU1LLW5kYjN2b0RUWGNXem9DSSZhbXA7cj05
emtQMHhuSlV2WkdKOUVQb09IN1locW4yZ3NCWWFHVHZqSVNsYUpkY1pvJmFtcDttPU45TEpwQ0pC
YWZIZFVOZFNPZTYzZmU0eVRZeEstd21Wel9EZ0gxY25Lak0mYW1wO3M9VWpPRXRKY0YwMGFKelpz
NWhycWFJcVdIZWJPMTF1Z0VlTWNFU3JjbVgzMCZhbXA7ZT0iPjxzcGFuIHN0eWxlPSJmb250LXNp
emU6OS4wcHQ7Zm9udC1mYW1pbHk6SGVsdmV0aWNhIj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls
bWFuL2xpc3RpbmZvL25ldG1vZDwvc3Bhbj48L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwv
YmxvY2txdW90ZT4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286
cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk1haGVzaCBKZXRoYW5h
bmRhbmk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi
PjxhIGhyZWY9Im1haWx0bzptamV0aGFuYW5kYW5pQGdtYWlsLmNvbSI+bWpldGhhbmFuZGFuaUBn
bWFpbC5jb208L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z
b05vcm1hbCI+PGJyPg0KPGJyPg0KPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvYm9keT4NCjwv
aHRtbD4NCg==

--_000_C062DDC989684B2482896B2625D3193Cjunipernet_--